vdr-2.4.0-05-fix-shutdown.diff scheint nicht enthalten zu sein, jedenfalls finde ich den Begriff ACTIVITYTIMEOUT nicht im diff. Wenn, dann sollte die von Klaus modifizierte Version aus während der Wiedergabe: "vdr wird in 5:00 Minuten abgeschaltet" zum Einsatz kommen.
Posts by Dr. Seltsam
-
-
Mein anderer VDR mit events/inputlircd und MCE-USB-FB macht keine Probleme...
was ist da für ein Empfänger verbaut?
Das träge Verhalten hatte ich mit atric.
-
kommt denn einzeln bei
cat /var/log/syslog|grep lirc
cat /var/log/syslog|grepserial
etwas?
Wichtig ist der senkrechte Strich- bei mir ist das AltGr und die Taste mit dem gößer/kleiner-Pfeil.
-
-
heisst Deine Datei jetzt /etc/modules-load.d/serial_ir oder /etc/modules-load.d/serial_ir.conf?
Ich bin mir nicht sicher, ob in Zeile 2 die Auskommentierung greift, wenn sie nicht am Anfang steht. da das schon in Zeile 1 steht, ist es zudem überflüssig.
Und Zeile 3 ist nochmal das gleiche.
Bei Deiner autoserial.conf hoffe ich mal, dass die nicht wirklich so aussieht, sondern hier nur falsch bzw. doppelt reinkopiert wurde.
Mir fiel noch auf, dass ich in meiner /etc/lirc/lirc_options.conf den Eintrag nodaemon = True habe, während es bei Dir False ist.
Und meine /etc/modprobe.d/serial-ir.conf sieht anders aus:Das habe ich auch nur aus dem Forum und verstehe die Syntax nicht wirklich. Das heisst ich weiss auch nicht, wie man hier die anderen Modulparameter für den Port mit einbaut. Aber eigentlich müsstest Du das für Deinen Fall direkt dahinter schreiben können:
-
Ich dachte, Du hattest /etc/modules-load.d/serial_ir.conf schon wieder gelöscht?
Ich habe den Eintrag "serial-ir" direkt in /etc/modules drin. Kommt aufs gleiche hinaus Für die Modulparameter ist ausschließlich /etc/modprobe.d/serial_ir.conf zuständig. Und das muss funktionieren.
Auf meinem Ubuntu 18.04 ist /etc/serial.conf auch nicht vorhanden, und im [modinit]-Abschnitt der /etc/lirc/lirc_options.conf habe ich auch nichts stehen. Ich meine mich zu erinnern, dass ich auch lange an dem Punkt festhing. Laut https://wiki.ubuntuusers.de/Lirc/ istd er richtige Weg jetzt bein Eintrag in /var/lib/setserial/autoserial.conf. Darin steht bei mir
Bei Dir wäre es dann ttyS1. -
auf alle Fälle solltest Du
code2 = /sbin/modprobe serial_ir ttyS1
in
code2 = /sbin/modprobe serial_ir
ändern. Mit sense die Autoerkennung zu übergehen dürfte auch nichts bringen. Wenn da nicht automatisch active-low kommt, ist der Empfänger entweder nicht richtig angeschlossen und/oder hat einen Hardware-Fehler.
-
Mein Reden
Ändere in /etc/lirc/lirc_options.conf im Abschnitt [lircd] den driver von devinput auf default.
/etc/modprobe.d/lirc.conf kannst Du löschen.
Solange Du im Log
bekommst, hast Du ein Problem. Das muss low sein.
Wenn Da eine Spannung umgeschaltet werden muss, dann durch serial-ir, denn das hat lirc-serial ersetzt.
lircd ist nur ein Daemon und schaltet keine Hardware.
-
Leider ist sehr schlecht bis gar nicht dokumentiert, wie das alles zusammenspielt und funktioniert.
Die Einstellungen in /etc/lirc/lirc_options.conf betreffen ja nicht die Modulparameter der Kernelmodule. Damit serial_ir einen bestimmten COM-Port benutzt, muss man das schon als Modulparameter vorgeben. Bei Ubuntu (und dann wahrscheinlich auch Debian) geht das mit einer
/etc/modprobe.d/serial_ir.conf mit folgendem Inhalt für den seriellen Port COM1
Im [modinit]-Abschnitt der /etc/lirc/lirc_options.conf muss dann analog
stehen.
Und ich würde mal probieren, im Abschnitt [lircd] den driver = devinput in driver = default zu ändern.
-
Nachdem Du nun schon Erfahrung gesammelt hast
... vielleicht kannst Du auch für Deutsche Welle TV (239.35.20.44:10000) einen Eintrag basteln? -
es gibt doch meist im BIOS die Option ""USB Power on by keyboard" oder so ähnlich. Meist ist es eine der F-Tasten.
-
ich hatte das damals ausprobiert, aber die FB war dadurch unglaublich zäh und langsam. vdr selbst kann ja auch nichts mit input devices anfangen. Man braucht entweder das remote-Plugin, oder muss doch wieder lirc mit devinput benutzen. So jedenfalls meine Erinnerung von den damaligen traumatischen Experimenten.
-
als ich das letzte Mal lirc unter Ubuntu 18.04 eingerichtet habe, bin ich fast verrückt geworden. Auch andere sind auf aktuellen Systemen verzweifelt, siehe (vdr4)Arch - serial_ir ersetzt lirc_serial Modul mit Kernel >= 4.10
Da die direkte Nutzung der Kernelschnittstelle über /dev/input... grottenlahm im Vergleich zu lirc war, habe ich die Nutzung der seriellen Schnittstelle für mich abgehakt. Beim nächsten mal werde ich mir ein FLIRC-Modul kaufen, dass einfach eine Tastatur emuliert.
lirc ist deprecated und wird z.B. von mpv längst nicht mehr unterstützt. Um mittels mplayer-Plugin mpv nutzen zu können, musste ich mit irxevent jedes lirc-Kommando in einen Tastaturbefehl umwandeln. Das ist mit FLIRC dann auch nicht mehr notwendig.
-
und das läuft genauso gut wie lirc, was z.B. die Geschwindigkeit beim Scrollen in Menüs angeht?
-
Ich muss noch die Anmerkungen von hier und hier berücksichtigen, dann werde ich den Patch nach ftp://ftp.tvdr.de/vdr/Developer/Patches/vdr-2.4 einspielen. Damit sollte es dann funktionieren, vorausgesetzt, an allen Eingängen liegen entsprechende Signale an. Devices zu erkennen, an denen (evtl. temporär) kein Signal anliegt, kommt danach.
Klaus
und während der Wiedergabe: "vdr wird in 5:00 Minuten abgeschaltet" bitte nicht vergessen
-
warum wird hier jede Sekunde ein GrabImage ausgeführt?
-
was ist Dein Ausgabedevice? Falls es die 6400 HD-FF-Karte sein sollte: die kann 1080p nicht mit 50Hz wiedergeben.
Ansonsten: Laufen die TS-Dateien denn mit anderen Programmen wie mpv sauber?
-
Ich glaube ihr redet aneinander vorbei und habt beide Recht.
Deprecated ist Ziffer 6 der API, und hier insbesondere die Decoder-ioctls in Ziffer 6.2 und 6.3. Dieses API wurde zunächst ausschließlich von vdr (zunächst im core, später im dvbsddevice-Plugin) genutzt. Zu der Zeit war die alte SD-FF-Karte (Treiber dvb-ttpci) der einzige Hardwaredecoder, der vom Linux-Kernel unterstützt wurde. Vor über 10 Jahren kam dann der ivtv-Treiber dazu und benutzte für den Hardwaredecoder der PVR350 ebenfalls dieses API, was wegen weiterer Besonderheiten der Karte aufgebohrt wurde. Das von mir damals mitentwickelte pvr350-Plugin war dann lange Zeit neben dem dvbsddevice-Plugin das einzige Userspace-Programm (sieht man mal von Testfunktionen in v4l2-ctl ab), das dieses API nutzte.
Von mir völlig unbemerkt (wer nutzt heute schon noch reine MPEG2-Decoder und SDTV?) und vermutlich auch von der Mehrheit der vdr-Nutzer (das dvbsddevice-Plugin ist mittlerweile nicht mehr Bestandteil der vdr-Sourcen) wurde das API in Teil 6 dann für obsolet erklärt (sicher keine einsame Einzelentscheidung von Mauro) und durch neue ioctls in Ziffer 7 ersetzt. Vorausgegangen war eine intensive Diskussion in der community , wie dieses Posting zeigt. Der ivtv-Treiber wurde entsprechend angepasst - die alten ioctls aus dvb/video.h und dvb/audio.h sind dort zwar noch enthalten, aber als deprecated gekennzeichnet. Der Treiber unterstützt also schon das neue API. Analog hätte jetzt eigentlich auch der dvb-ttpic-Treiber (und in der Folge ggf. das dvbsddevice-Plugin, sofern es noch jemand benutzt) angepasst werden müssen, aber nachdem UFO schon vor Jahren entnervt das Handtuch geworfen hatte, hat der Treiber ja keinen Maintainer mehr.
Dass das dvbhddevice-Plugin und der Treiber für die TT6400 einige ioctls des alten API (Teil 6) benutzten, war mir bislang neu. Dass Mauro schon in der Phase, wo die alten ioctls nur als deprecated markiert, aber noch vorhanden sind, das ioctl AUDIO_GET_PTS einfach rausschmeisst, nur weil es nicht in der API dokumentiert ist, war sicher schwach. Man hätte sich ja auch stattdessen fragen können, ob vielleicht nur die Dokumentation unvollständig ist. Auch hätte er merken müssen, dass zumindest ein im Kernel enthaltener Treiber (dvb-ttpci) es noch unterstützt hat. Wie auch immer, das ist ja nun wieder drin. Es löst aber das Problem nicht, dass irgendwann die deprecated ioctls rausfliegen werden. In einer idealen Welt hätten Treiber-Maintainer und Userspace-Entwickler jetzt geprüft, ob das gewünschte Ziel mit einem der neuen ioctls aus Teil 7 darstellbar ist bzw. ob man überhaupt ein ioctl dafür braucht - und wenn das nicht möglich ist, einen entsprechenden Vorschlag zur Erweiterung des neuen API gemacht.
Ein ganz wesentliches Problem bleibt aber offen: Auch das neue API orientiert sich am Bedarf von MPEG2-Dekoderkarten. Ich gehe mal davon aus, dass ein h264-Dekoder ganz andere Anforderungen stellt und andere, zusätzliche ioctl braucht. In der Situation dann nur auf das v4l2-API (Teil 7) zu verweisen und den Entwickler alleine damit zu lassen, notwendige Erweiterungen vorzuschlagen und durchzusetzen, ist etwas mager für einen linuxtv-Maintainer.
Abschließend sei allerdings die Frage erlaubt, ob es wirklich sinnvoll ist, für einen einzigen existierenden h264-Hardwaredekoder, der zudem keine große Verbreitung hat und schon lange nicht mehr als Neuware erhältlich ist, viel Zeit in die Erweiterung eines API zu investieren. Die TT6400 kann nichtmal FullHD ausgeben, und schon in wenigen Jahren wird sie genauso vergessen sein wie die SD-FF-Karte oder die PVR350. Von daher könnte es vielleicht zielführender sein, den Treiber außerhalb des Kernels zu lassen. Denn eins ist klar: Wenn er es in den Kernel schafft, dann nur mit neuen ioctls. Es müsste in der Folge also auch noch jemand gefunden werden, der das dvbhddevice-Plugin entsprechend anpasst.
-
Runterfahren tut er bei laufender Wiedergabe nicht mehr. Zum Radio-Plugin kann ich nichts sagen, da ich das nicht nutze. Das müsste Ulrich Eckhardt dann mal testen. Bin leider gerade zu blöd, ihn hier so zu markieren, dass er über den Thread benachrichtigt wird.
-
Soweit ich das überblicke, wird das ccontrol aber nicht für Live-Radio, sondern nur bei der Wiedergabe von Radio-Aufzeichnungen (während der kein RDS empfangen wird) verwandt.
