vdr4arch und VDR 2.4.1: Nach erstem Speichern der setup.conf funktioniert LIRC nicht mehr

Zitat von Hektor

Korrektur: Habe konsequent 2.1.4 statt 2.4.1 geschrieben, sorry.

Kannst doch den Titel auch bearbeiten

Hi,

Welche Systemversion? Klingt eher nach dem Standardproblem das der neue Kerneltreiber parallel läuft und deshalb lirc nur manchmal zufällig geht. Betrifft alle neueren Distris(kernelbedingt, da viele Fbs jetzt via Kerneltreiber direkt ohne lirc laufen).

Mfg Stefan

Hi,

Hmm, zumindest ist das in Ubuntu eins der Probleme neben systemd.

Mfg Stefan

Zitat von Hektor

Was passiert über systemd/systemctl eigentlich bei einem "systemctl stop vdr.service"?

Das ist abhängig davon, was konkret in der Unit steht, aber nehmen wir mal einen einfachen Fall wie https://github.com/VDR4Arch/vd…ob/master/vdr/vdr.service

Der von Systemd getrackte Dienst erhält das KillSignal, das standardmäßig ein SIGTERM ist und hat dann die in TimeoutStopSec festgelegte Zeit darauf zu reagieren. Wenn er sich nicht rechtzeitig beendet wird er mit einem SIGKILL gemäß des gesetzten KillMode abgeräumt.

Wenn man zusätzliche Skripte ausführen lassen wollte, würde man das in einem ExecStop machen (wie das z.B. im VDR-Paket für Fedora zum Setzen des nächsten Aufweckzeitpunktes gemacht wird).

Da es bei GitHub nun bereits zu ist (helfen kann vom VDR4Arch-Team aber ohnehin keiner ernsthaft) will ich kurz ein paar Gedanken niederschreiben in der Hoffnung dabei etwas zum Eingrenzen des Fehlers beitragen zu können.

1. Die "shotdown-wrapper" gehen nur wenn über "shutdown.sh" runtergefahren wird. Soll heißen wenn der VDR runterfährt. Ein "systemctl stop vdr" ist immer ein "hartes Stoppen". Der VDR bekommt zwar sauber sein Signal und hat Zeit genug Einstellungen zu speichern, aber zum Beispiel blockiert eine laufende Aufnahme diesen Vorgang nicht.

2. Um das Thema mit der setup.conf einzugrenzen wäre es gut wenn du einfach mal eine Kopie der Datei ziehst und dann das Problem reproduzierst. Danach "diff" zwischen Kopie und dem "kaputten Original". Dann könnte man mal schauen was da kaputt geht.

3. Das Problem existiert zu 100% nicht wenn der VDR keine Ausgabe macht. Das habe ich genau so seit Jahren laufen und da hängt nix und geht auch nix verloren. Demnach kann man zu 100% sagen: Ist mal wieder ein Ausgabe-Problem. Mein Tipp: Versuche mal manuell via SVDRP die Ausgabe zu "detachen" und beende den VDR dann über systemctl. Wenn das helfen sollte, dann müsste man zum Thema aber mal einen eigenen Thread aufmachen. Das Problem ist nämlich das der Ausgabe-Wildwuchs in letzter Zeit noch etwas unübersichtlicher geworden ist und einen einheitlichen SVDRP-Befehl, der dann universell in jeder Situation einen "Detach" macht, existiert nicht.

4. Wenn 3 hilft: Eventuell auch mal ein anders Ausgabe-Plugin nehmen. Das PKGBUILD für "softhdcuvid" baut zum Beispiel gleich 3 Ausgabe-Plugins. Davon einmal für Nvidia und einmal für AMD.

Und zuletzt noch weil es passt und auch obwohl es nicht konkret zur Lösung beiträgt: Wie beim VDR aktuell die Ausgabe gemacht wird ist Mist. Kurz nach dem "Auslaufen" der Full-Featured-Karten war der Ruf laut den VDR direkt auf die Grafikkarten ausgeben zu lassen. Am besten noch ohne X-Server. Das hat dazu geführt das sich jede Distribution jetzt mit dem Spagat rumschlagen muss sowohl den VDR sauber als System-Backenddienst zu betrachten als auch halbwegs störungsfrei mit einem X-Server zu verknüpfen. Dieser Spagat hat uns so tollen Herausforderungen wie "attachen" und "detachen" beschert.

Falls sich einer der Ausgabe-Programmierer berufen fühlt: Eine Netzwerkschnittstelle dazwischen wäre schon geil...

Hat aktuell leider nur xineliboutput und das wird ja kaum noch verwendet.

Ob detach hilft wäre noch interessant gewesen. Da hätte man ggf. noch was in das vdr-xorg-Paket scripten können.

Das aktuelle softhddevice baut auch mit aktuellem ffmpeg und softhdcuvid sowieso.

So bleibt das Problem halt erstmal so stehen. Ich selber werde mich nicht mehr mit Ausgabe-Plugins befassen. Wenn mit vdr4arch jemand anderes direkt ausgeben will, dann muss er halt die nötigen Tests machen das man rausfinden kann ob detachen helfen würde.

Aber im Prinzip stimme ich da mit dir überein. Läuft bei mir auch rein als Hintergrund-Dienst und ausschließlich mit Kodi davor.

Hektor Wenn du magst, kannst du dir auch mal yavdr-ansible ansehen, da klappt die Integration des VDR-Frontends in die Session ziemlich gut. Die Konstruktion für den X-Server und die User-Session kann man auch auf andere Distributionen mit Systemd übertragen, mir ist das mit Arch Linux nur etwas zu aufwendig, weil die Schlagfrequenz bei den Updates mit inkompatiblen Änderungen da viel höher als bei Ubuntu ist.

Das Problem bei yavdr im Allgemeinen ist das der VDR da in eine User-Session gestartet wird. Das widerspricht meiner Meinung nach dem Konzept eines System-Diensts. Auf so einen Umstand nur wegen der Unzulänglichkeiten der VDR-Ausgabe werde ich mich bei vdr4arch auf jeden Fall nicht einlassen. Im Wesentlichen halte ich den VDR für einen Systemdienst der auch so nutzbar sein soll wenn man vorhat Kodi als einziges Frontend davor zu bauen. Kodi kann (und muss) dann auf der gleichen Maschine gerne in eine User-Session gestartet werden. Das ist aber in verschiedenen "Geschmacksrichtungen" bereits umgesetzt und auch erprobt.

Gleiches Thema bei einem reinen Server der Clients im Netz bedienen soll. In all den Fällen will ich weder User-Session noch X-Server für den VDR.

Sauber wäre: VDR als System-Dienst mit systemd und ohne Session. Ausgabe dann einfach in den Autostart eines beliebigen leichtgewichtigen Window-Manager welcher auf Auto-Login konfiguriert wurde. Geht nicht weil beim VDR halt so ein Zwischenzustand besteht das ein Systemdienst "von hinten durch die Brust ins Auge" die Ausgabe machen muss.

Zitat von M-Reimer

Das Problem bei yavdr im Allgemeinen ist das der VDR da in eine User-Session gestartet wird.

Nein, der VDR läuft als Systemdienst und das Frontend wird mit ein paar Tricks von der User-Session aus gesteuert und kann dank passend gesetzter Umgebungsvariablen auf Dienste, die wie Pulseaudio in der Session laufen zugreifen.

OK. Das wäre zumindest etwas sauberer. Ändert aber nichts daran das ziemlich viel Aufstand nötig ist weil der VDR eben aus der Historie heraus den Spagat zwischen Backend-Dienst und "Anwendungsprogramm" macht. Mir wäre für vdr4arch am liebsten irgendwann mal die einfache "vdr-xorg-Lösung" zu stabilisieren. Hapert halt daran das wohl bei den meisten die bei vdr4arch aktiv beitragen aktuell keiner mehr die Ausgabe vom VDR machen lässt.

Ich selber kann damit leben, hätte aber der Vollständigkeit halber doch gerne eine stabile "VDR-Ausgabe" in vdr4arch. Wenn der VDR von Klaus irgendwann so umfangreich mit Netzwerkfunktionen ausgestattet ist, dass ein VDR-Client vollwertig (inklusive Video-Streaming) mit dem Backend gekoppelt werden kann, dann wäre meine bevorzugte Lösung tatsächlich für vdr4arch den VDR doppelt zu starten. Einmal als echter Backend-Dienst und ein zweites Mal konfiguriert als Client mit Ausgabe in der User-Session. Netzwerk dazwischen. Dann kann die ganze Ausgabe machen was sie will: Das Backend wird es nicht stören.

Meine beiden vdr4arch System laufen mit Ausgabe durch den VDR mit SHD und Bedienung per Imon. Also es ist nicht so dass das keiner in Verwendung hat

Ich gehe aber davon aus dieses Problem (Hänger beim Runterfahren) kannst du nicht nachvollziehen?

Was mir dazu aufgefallen ist bei mir, dass der Shutdown Prozess funktioniert aber im Vergleich zu ansible@focal viel länger dauert, genauso wenn ich per Konsole den Prozess systemctl restart vdr auslöse dauert der Vorgang eine kleine Ewigkeit gegenüber dem erwähnten yaVDR, aber es funktioniert. Mit der setup.conf habe ich manchmal das Verhalten dass der letzte Kanal nicht gespeichert wird sondern der genommen wir beim Start wo in der setup.conf gespeichert war.

Also irgendwas kann da schon sein, hab aber nicht weiter gesucht deswegen.