Hab gerade keine Kristallkugel zur Hand. Vielleicht remote-Plugin nicht richtig konfiguriert?
Posts by S:oren
-
-
Hat man einen headless Server oder hat man eine FF-Karte, erscheint nirgendwo ein Anlerndialog - weder im Bild der FF-Karte noch auf irgendeiner Konsole.
Wie macht man das in so einem Fall, bzw. was mache ich falsch, wenn es einfach so gehen sollte?Bei mir mit dvbhddevice und remote-Plugin gibt es einen Anlerndialog auf dem OSD der FF, wenn keine remote.conf vorhanden ist. Es empfiehlt sich dazu ein VDR-Standard-Skin. Geht aber z.B. mit skin-nopacity mittlerweile auch.
Gruss
S:oren -
Genau das mache ich zur Zeit halt - vor allem um die Stabiltät des softhddevice Ausgabeplugins zu testen.
Dann funktioniert das ja wie vermutet.
Ich hab jetzt mal versucht, das Ganze mit FLIRC und der TT-Fernbedienung. Grundsätzlich geht das schon, aber sowohl FLIRC als auch die FB sind schon recht zickig.
Da kann ich nur vermuten, dass das an FLIRC liegt (kenn ich nicht naeher). Mit der originalen Fernbedienung plus dem Remote-Plugin habe ich keinerlei Problem.
Gruss
S:oren -
Der saa716x-Treiber fuer die S2-6400 erzeugt (neben den ganzen /dev/dvb/xxx) auch ein Input-Device fuer die IR/CEC-Fernbedienungs-Hardware auf der Karte. Die Events dieses Input-Devices kann das Remote-Plugin passend an den VDR uebergeben, man muss da das passende /dev/inputX konfigurieren (sinnvoll per udev-Link fuer stabile Nummerierung).
Im Prinzip sollte es auch funktionieren, eine S2-6400 mit Treiber als Fernbedienungs-Input-Device zu verwenden, und softhddevice als Ausgabeplugin zu nutzen. Besonders sinnvoll erscheint mir diese Kombination allerdings nicht.
Gruss
S:oren -
Mit softhddevice und LCARS klappt es, mit dvbhddevice nicht - da kommt nix über den Anschluss der DVB-Karte und auch nix im Terminal.
Also ich benutze fuer die Fernbedienung der TT S2-6400 zusaetzlich zu dvbhddevice das remote-Plugin.
Gruss
S:oren -
Ich denke, ich habe eine Moeglichkeit gefunden, alle auftretenden time_t zu checken (siehe commit message). C ist eben auch nicht meine Muttersprache. Aber wieder 'was gelernt.
So richtig verstehe ich den Sinn dieses msprintf() nicht, man haette ja durchgaengig cString nehmen koennen. Ist vermutlich ein Artefakt aus alten Zeiten.
Hoffentlich passt damit jetzt alles. Laeuft bei mir auf 32bit und 64bit.
Gruss
S:oren -
Patch scheint ziemlich vollständig zu sein, aber m.E. fehlt noch in searchtimer_thread.c::SummaryExtended()
start und stop bei msprintf()
Falls das wirklich auch angepasst werden muss, dann vermutlich auch in
const char *cPendingNotification::ToText(void)
const char *cRecDone::ToText(void)
const char *cNoAnnounce::ToText(void)Gruss
S:oren -
Hm, was ist denn msprintf() nun schon wieder!?
Der Compiler (gcc 14.2) beschwert sich jedenfalls nicht, und es crashed auch nichts. Aber ich kann es gerne , wenn gewuenscht, auch noch anpassen und testen, ob sich wenigstens nichts verschlechtert.
Gruss
S:oren -
was hältst du davon, wie vdr mit %jd und cast auf (intmax_t) zu arbeiten?
Ergibt ja Sinn, das genauso zu machen wie im vdr. Danke fuer den Hinweis. Angepasster Patch anbei.
Gruss,
S:oren -
Auf einem 64Bit-System funktioniert diese epgsearch-Version 2.4.5 bei mir wunderbar. Auf einem 32Bit-System crashed die aber, nachdem ich Debian bookworm auf trixie upgegraded habe.
Der angehaengte Patch fixed diesen Crash.
Ich wuerde mich freuen, wenn der Patch in das offizielle Repo uebernommen wuerde.
Gruss
S:oren -
-
Moechte mir jemand einen venuenftigen Patch dafuer schicken?
Anscheinend nicht. Also habe ich etwas gebaut.
Gruss,
S:oren -
Moechte mir jemand einen venuenftigen Patch dafuer schicken? Am besten aehnlich zu und mit Verweis auf den entsprechenden Upstream-Commit 14340de506c9!? Also mit dem Leerzeichen, und einer kurzen Erklaerung, was die Aenderung fuer Vorteile bringt?
Gruss,
S:oren -
Danke, aber das ist "etwas" über meinen Fähigkeiten
Ich bin ueberzeugt, ganz sicher nicht. Wer mit mit Kernel-Sourcen hantiert und da Scripte baut, kommt ganz bestimmt auch mit bisect klar. Man muss halt die ganzen ~5GB von meinem Repository herunterladen und sich einen halben Tag Zeit nehmen fuer die (vermutlich) 10 bis 20 Durchlaeufe des bisect. Dann wird sich herausstellen, was sich im Build-Flow geaendert hat (was man also als Zusatz-Patch braucht), oder warum das Makefile nicht die richtigen Include-Directories bereitstellt. Ist bestimmt nur eine Kleinigkeit.
Ich teile gerne meine Anpassungen des Treibers fuer neue Kernel, aber ich habe leider keine Zeit, meine Treiberanpassungen das fuer verschiedene Distributionen automatisiert bereitzustellen. Da haben verschiedene Leute ja richtig gute Arbeit geleistet und verschiedene Scripts/Methoden hier im vdr-portal veroeffentlicht.
Wenn es jemand nochmal versuchen will, den Treiber endlich mal in den Kernel zu bekommen, ich unterstuetze das gerne. Das waere die ultimativ richtige Loesung, fuer alle diese leidigen Anpassungen. Ist ja alles GPL.
Gruss,
S:oren -
[...]täte mich aber immer noch interessieren, ob und wenn ja ich den anfangs beschriebenen Fehler weg bekomme.
Mein Script (siehe Anhang) lief eigentlich bis zu den 6.11er Kerneln problemlos [...]Da kann ich nur zu 'git bisect' raten...
Ich habe das Ganze so gemacht, wie in https://docs.kernel.org/kbuild/modules.html beschrieben.
Dort ist beschrieben "how to build an out-of-tree kernel module". Das hier ist aber ein Patch/Repo fuer einen Treiber im Kernel-Tree.
Gruss,
S:oren -
Oder sonst irgendwas mit dem Build-Flow.
Wenn ich bei mir in dem Source-Tree 'make -C . M=drivers/media/pci/saa716x' aufrufe, bekomme ich den selben Fehler.
Wenn ich den kompletten Kernel mit Modulen baue, wie ich es normalerweise mache, dann funktioniert alles. Offenbar ist irgendwas an diesem Build-Flow nicht richtig.
Gruss,
S:oren -
Tja, hm. Was auch immer Du da als Basis fuer den Patch benutzt (/usr/src/linux-6.15.0-1), es ist anscheinend kein Mainline-Linux 6.15.0 oder 6.15.1, diese beiden Versionen habe ich bei mir problemlos am Laufen. Es gibt da auch drivers/media/dvb-frontends/stv6110x.h .
Oder ${KERNELMAINVER} stimmt nicht. Oder sonst irgendwas mit dem Build-Flow (Was soll "make -C ." ?). Meine Glaskugel gibt leider aus der Beschreibung auch nicht mehr her.
Gruss,
S:oren -
-
Was heißt das RGB hier?
Vermutlich einfach genau das, was da steht. Auf dem HDMI-Kabel kommt 24Bit-RGB an, was dann auch genau so dargestellt wird. Das Anzeigegeraet wandelt also das Bildformat nicht um, dass passiert schon in der HDMI-Quelle.
Das ist uebrigens auch genau das, was man haben will: Die Video-Plane (YUV) wird im Ausgabeprozessor (Hardware) in RGB gewandelt und dann dort mit dem RGB-OSD-Overlay zusammengemischt. So hat man keine Qualitaetsverluste, weil 24Bit-RGB das 'hoeherwertige' Bildformat ist im Verhaeltnis zu YUV mit 12Bit (4:2:0) oder 16Bit pro Pixel (4:2:2) - und YUV mit 4:4:4 entspricht (was niemand verwendet, weil der ganze Sinn von YUV ja eine relativ verlustarme Kompression ist). Ueber das HDMI-Kabel wuerde man YUV nur schicken, wenn man durch die geringere Anzahl von Bits/Pixel eine hoehere Aufloesung gerade noch so uebertragen kann und man zu Gunsten der hoeheren Aufloesung den Verlust an Farbqualitaet in Kauf nimmt.
In dieser Rechnung gehe ich von 8Bit pro Komponente aus ( R,G,B,Y,U,V), bei 10 oder 12 Bit pro Komponente sind es mehr Bits, das Verhaeltnis der Bits/Pixel bleibt aber gleich.
Gruss,
S:oren -
Naja, wichtig, was ist schon wichtig?

Ziel war halt, den Wareagleicon-Patch zu ersetzen, und der zeigt das mit an...Ich hatte diese Anzeige gefuehlt schon immer, und moechte sie auf keinen Fall missen. Also ja, fuer mich ist das wichtig.
Ist schon klar. Ein anderer Skin ist doch aber dazu da, Dinge anders darzustellen. Und ein Anzeigen im Event-Menü, ob ein Event gerade aufgenommen wird, ist zur Zeit halt nicht einfach zu realisieren...
Das waere eine wirklich sehr gute Sache, wenn man das in einem Skin unterbringen kann, wenn es schon ohne Patch sonst nicht geht.
Gruss,
S:oren