VDR startet nicht mehr

  • Hallo zusammen,


    die Ausagangslage heute morgen: Ein funktionierender VDR (yavdr 0.6.1)

    Ich habe ein paar versuche unternommen, den VDR zu modularisieren / dockerisieren. Idee war: tvheadend als Docker Image laufen lassen (hiermit: https://hub.docker.com/r/clemensvb/tvheadend-sundtek-docker/) welches dann per Sat-IP die Daten an einen oder mehrere VDR liefert (SAT-IP-Plugin) der idealerweise auch in einem Container läuft. Da der VDR ja auch die Ausgabe (VDPAU) machen soll vermute ich allerdings das das schwierig werden könnte das in nem Container laufen zu lassen. Das tvheadend image lief jedenfalls schon gut und fand auch alle kanäle (auf dem gleichen system wo auch der VDR aktuell noch nativ läuft). Um den VDR dann an tvheadend anzubinden habe ich das Sat-IP Plugin installiert, die Anbindung aber nicht hinbekommen. Um auszuschließen, dass es an inkompatibilitäten mit anderen Plugins liegt habe ich immer mehr mit vdrctl disable <plugin> deaktiviert. Aber selbst mit einem nackten VDR klappte es nicht. Da ich mich dann erstmal etwas tiefer in die Sat-IP Thematik einlesen wollte beabsichtigte ich alles wieder auf die Ausgangsposition zurückzudrehen damit meine Partnerin wieder den VDR nutzen kann. Leider ging das in die Hose :-( Ich habe alle deaktivierten Plugins wieder aktiviert und das SAT-IP Plugin wieder deaktiviert, später gar gelöscht. Nun hängt der VDR beim starten im "stop/post-start" zustand. Selbst wenn ich alle Plugins deaktiviere änderte sich das nicht. :-( Leider ist das Log auch nicht sonderlich gesprächig beim Start. Bevor ich gesehen hatte das der VDR in diesem "stop/post-start" Zustand hängt hatte ich gemutmaßt, dass evtl. was mit der Ausgabe nicht stimmt und hatter daher über das yavdr webinterface mal das display neu gescannt und gespeichert. Allerdings bekam ich beim speichern auch dort eine "Error while saving data" o.ä. Fehlermeldung. Irgendwo hängt es gewalting :-( Auch das Abhängen meiner 2 DVB-C USB-Sticks änderte nichts. Die Docker Images sind natürlich auch gestoppt, es läuft nur der native VDR.


    Die Logausgabe beim Starten - mit lediglich softhddevice als plugin - ist hier zu finden: https://pastebin.com/wrHNLreh

    Die verwendete Grafikkarte ist eine GeForce GT 610.


    Bein yavdr blicke ich ehrlich gesagt nicht durch was wo wie gestartet wird und voneinander abhängt, daher fehlt mir den Ansatz wie ich den Fehler suchen kann. Kann mir jemand aus der Patsche helfen?


    Viele Grüße,

    Stephan

  • Zusätzlich scheint es ein Problem mit dem vdr-frontend zu geben, möglichweise durch die fehlgeschlagenen Versuche das Frontend über die admin GUI zu ändern. Wenn ich das Frontend im Vordergrund starte kommt folgende Meldung:


    Traceback (most recent call last):

    File "/usr/bin/frontend", line 571, in <module>

    frontend = dbusSofthddeviceFrontend()

    File "/usr/bin/frontend", line 162, in __init__

    self.dbusfe = bus.get_object("de.tvdr.vdr", "/Plugins/softhddevice")

    File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 241, in get_object

    follow_name_owner_changes=follow_name_owner_changes)

    File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 248, in __init__

    self._named_service = conn.activate_name_owner(bus_name)

    File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 180, in activate_name_owner

    self.start_service_by_name(bus_name)

    File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 278, in start_service_by_name

    'su', (bus_name, flags)))

    File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking

    message, timeout)

    dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name de.tvdr.vdr was not provided by any .service files

  • Da der VDR ja auch die Ausgabe (VDPAU) machen soll vermute ich allerdings das das schwierig werden könnte das in nem Container laufen zu lassen.

    Ja, insbesondere in Verbindung mit softhddevice wird das schwierig, weil dann mindestens drei Löcher in den Container gebohrt werden müssen:

    • Zugriff auf die Soundkarte (mit alsa) bzw. pulseaudio
    • Zugriff auf den DBus SystemBus
    • Zugriff auf den X-Server

    Mit xineliboutput/vdr-sxfe bräuchte man nur eine Netzwerkverbindung zum Container, wenn man das PostStart Skript aus der /etc/init/vdr.override rauswirft, auf dbus2vdr verzichet und vdr-sxfe mit dem Argument -r startet, damit es selbstständig versucht eine Verbindung mit dem VDR aufzubauen anstatt abzubrechen, wenn der VDR nicht (mehr) erreichbar ist.

    Bein yavdr blicke ich ehrlich gesagt nicht durch was wo wie gestartet wird und voneinander abhängt, daher fehlt mir den Ansatz wie ich den Fehler suchen kann. Kann mir jemand aus der Patsche helfen?

    Der VDR wird über die /etc/init/vdr.conf gestartet. Davon unabhängig startet die /etc/init/xorg-launcher.conf den X-Server, danach startet die /etc/init/openbox.conf den Window-Manager Openbox und zuletzt wird über /etc/init/yavdr-frontend.conf das Frontend-Skript gestartet - damit das erst startet, wenn der VDR bereit ist, wartet on_vdr auf das "Ready" Signal, das dbus2vdr absetzt, wenn es zum ersten Mal in der Mainloop des VDR aufgerufen wird und startet dann das eigentliche Frontend-Skript, das im Fall von softhddevice als Ausgabeplugin über dbus2vdr mit dem VDR kommuniziert, um den Befehl zum Attachen von softhddevice abzusetzen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das Plugin dbus2vdr ist bei yavdr ein Muss, das darf nicht disabled werden.


    Lars

    Danke für den Hinweis! Mit dem dbus2vdr Plugin klappte es dann auch wieder. Klar ist zwar nicht warum der VDR nicht startete als ich alle Plugins auf einmal wieder reaktivierte, aber nun konnte ich peu a peu alle Plugins wieder hinzufügen und alles läuft wieder. :-) Danke für den Tip!

  • Ja, insbesondere in Verbindung mit softhddevice wird das schwierig, weil dann mindestens drei Löcher in den Container gebohrt werden müssen:

    • Zugriff auf die Soundkarte (mit alsa) bzw. pulseaudio


    Also mit Softhddevice / VDPAU brauche ich ja keinen Zugriff auf die Soundkarte, der Ton geht ja per HDMI mit über die Grafikkarte. Oder übersehe ich da etwas?

    Zugriff auf den DBus SystemBus

    Was muss ich dafür tun? Welcher Port muss dafür durchgereicht werden?


    Zugriff auf den X-Server

    Auch hier würde mich interessieren welcher Port durchgereicht werden muss. Grundsätzlich habe ich kein Problem damit, dass der Container und das native Linux kommunizieren.



    Mit xineliboutput/vdr-sxfe bräuchte man nur eine Netzwerkverbindung zum Container

    Die verschiedenen Ausgabeplugins sind für mich auch etwas undurchsichtig. Ist xineliboutput/vdr-sxfe gleichwertig zur Softhddevice Lösung mit VDPAU oder geht das mehr auf die CPU? Wo liegen die Vor- und Nachteile? Das einzige was ich fand ist, dass scheinbar xineliboutput/vdr-sxfe offenbar wiederum andere Ausgabeplugins nutzen kann. Evtl dann auch Softhddevice? Oder hab ich da was falsch verstanden?


    Grundsätzlich wäre meine Vorstellung der Containerisierung die folgende (alles auf dem gleichen Server laufend):

    1. Ein Container mit tvheadend der die DVB-C Sticks besitzt und diese per SAT->IP Streamt
    2. Ein Container mit einem Headless VDR der per SAT->IP die TV Streams vom tvheadend Container bekommt und sich um Aufnahmen, EPGsearch etc. Kümmert. Das Aufnahmenlaufwerk ist entweder per NFS gemountet oder vom Nativen Linux als Volume durchgereicht.
    3. Ein VDR Frontend das auf den Headless-VDR Container zugreift. Hier bin ich offen, ob sich das ebenfalls in einem Container befindet oder im nativen Linux installiert ist. Ich habe bislang keine Erfahrung mit getrenntem aufsetzen von Server und Frontend, hoffe aber, dass das ein reines Frontend recht leicht aufzusetzen sein sollte oder irre ich da?
    4. Wo LIRC dann läuft ist auch noch offen. Evtl. auch eigener Container oder mit in einen der o.g. Auch hierzu freue ich mich über Meinungen und Tips ;-)

    Warum ich den ganzen Zirkus machen will ist die Tatsache, dass ich damit unabhängig werde von der Linux Distri / Version des nativen Servers. Das mittlerweile doch uralte Ubuntu 14.04 ist einfach nicht mehr Zeitgemäß. Wir sind aktuell bei Ubuntu 18 und die 19er Version ist für April angekündigt. Und VDR ist nur einer der Dienste dich ich darauf laufen lasse. Webserver, VPN Server, Openhab etc. verrichten dort ebenfalls ihre Dienste und es wird zunehmen schwerer aktuelle Pakete für das alte Ubuntu zu finden. Ganz abgesehen von dem unsäglichen Upstart von dem Ubuntu nach der 14er Version ja verständlicherweise wieder abstand genommen hat ;-)


    Zudem hat man mit dem Container ne definierte Umgebung und kann parallel in einem zweiten Container z.B. eine neue VDR Version testen, weiss aber, dass man jederzeit wieder auf eine stabil laufende Installation / Konfiguration über den Container zugreifen kann. Die Gefahr sich bei Tests alles zu zerschießen ist dadurch einfach gebannt. Auch der Transfer auf eine neue VDR Hardware wird dadurch immens vereinfacht.


    Habt ihr dazu evtl. Tip? Meinungen? Anregungen? Vor allem über eine Klärung der Verständnisfragen ganz oben würde ich mich sehr freuen und danke im Voraus :-)


    Viele Grüße,

    Stephan

  • Also mit Softhddevice / VDPAU brauche ich ja keinen Zugriff auf die Soundkarte, der Ton geht ja per HDMI mit über die Grafikkarte. Oder übersehe ich da etwas?

    Da sitzt eine Soundkarte auf der Grafikkarte...

    Was muss ich dafür tun? Welcher Port muss dafür durchgereicht werden?

    Kein Port, sondern ein Unix Socket, ich habe keine Ubuntu 14.04 Installation zur Hand, unter 18.04 wäre das /run/dbus/system_bus_socket

    Auch hier würde mich interessieren welcher Port durchgereicht werden muss. Grundsätzlich habe ich kein Problem damit, dass der Container und das native Linux kommunizieren.

    Du kannst soweit ich weiß in dem Fall nicht über einen TCP-Socket gehen, weil das mit der Hardwarebeschleunigung nicht zusammen geht.

    Es ist IMHO ziemlich unsinnig einen Container zu schnüren, nur um dann wieder große Löcher rein zu machen.

    Zudem hat man mit dem Container ne definierte Umgebung und kann parallel in einem zweiten Container z.B. eine neue VDR Version testen, weiss aber, dass man jederzeit wieder auf eine stabil laufende Installation / Konfiguration über den Container zugreifen kann. Die Gefahr sich bei Tests alles zu zerschießen ist dadurch einfach gebannt. Auch der Transfer auf eine neue VDR Hardware wird dadurch immens vereinfacht.

    Das ist IMHO ziemlich übertrieben, dafür gibt es das Paketmanagement (und für Ubuntu 18.04 den Ansatz mit Ansible - yavdr-ansible), um das System in einen definierten Zustand zu bringen. Container können nett sein, wenn man gut gekapselte Dienste hat, denen eine Netzwerverbindung nach außen genügt (meinetwegen noch am ehesten bei einem headless betriebenen VDR, der über vnsiserver und streamdev den Zugriff ermöglicht), aber beim VDR mit softhddevice greift so viel Zeug ineinander, dass es die Sache eher verkompliziert als vereinfacht, wenn man das in Container steckt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)