[solved] VDR - Wait for devices (alt: Plugin-Reihenfolge)

  • Guten Abend,


    ich kann mich dunkel daran erinnern, dass Fragen zu einem gewissen Plugin nicht erwünscht waren. Ich probier's trotzdem mal. Falls unerwünscht, dann bitte den Thread einfach löschen (und mir evtl. 'ne PN schreiben).


    Ich nutze vdr als Backend in Kodi. Die Verbindung zwischen vdr und Kodi stelle ich mit dem VNSI-Server her. Dabei nutze ich auch PayTV-Sender.


    Starte ich jetzt den HTPC, dann funktionieren nur die FreeTV-Sender. Sämtliche verschlüsselte Kanäle werden beim Aufruf als nicht verfügbar angezeigt. D.h. nicht die Entschlüsselung schlägt fehl, sondern die Kanäle sind einfach blockiert und nicht verfügbar. Starte ich vdr neu, funktioniert's (systemctl restart vdr). Ab dem 2. VDR-Start funktionieren alle Sender auch, wenn der HTPC für ein paar Stunden ausgeschaltet wird. Nur wenn ich am nächsten Tag (keine Ahnung, wieviel Stunden Pause notwendig sind) den HTPC wieder hochfahr, dann hab ich wieder das o.g. Problem.


    Jetzt könnte man dahinter die Ladereihenfolge der Plugins vermuten. Regeln konnte man das mit der order.conf. Aber so, wie ich aus Tante Google rausquetschen konnte, war die order.conf yavdr-spezifisch (ich nutze ein reines Gentoo) und ist mittlerweile obsolet. Den Quelltext von VDR hab ich ebenfalls mal durchgegrept, ohne jedoch den Suchbegriff "order.conf" überhaupt zu finden. Von daher gehe ich aus, dass es die order.conf im Vanilla-VDR nicht gibt.


    Daher die Frage:
    Wie kann ich den VNSI-Server dazu bewegen, dass er erst startet, wenn das sc-Plugin geladen und initialisiert ist?


    Version VDR: 2.3.2 (das Problem bestand aber auch schon mit VDR-2.2.x)
    VNSI: Git-Version
    Kodi: 17.0_rc3-r2

    Dieser Beitrag wurde bereits 3 Mal editiert, zuletzt von musv () aus folgendem Grund: Problem gelöst

  • Das böse plugin muss als Erstes geladen werden. Wie Du das machst, hängt von Deinem Startscript (bei mir runvdr) ab.


    vdr-User-# 755 to_h264 chk_r

  • Aber so, wie ich aus Tante Google rausquetschen konnte, war die order.conf yavdr-spezifisch (ich nutze ein reines Gentoo) und ist mittlerweile obsolet.

    Das war nicht nur in yaVDR <= 0.5, sondern für alle VDR-Pakete unter Debian/Ubuntu so gelöst.
    Wie startest du denn den VDR?

    Code
    1. systemctl cat vdr


    Für mich sieht das ebuild ( https://github.com/lucianm/gen…ideo/vdr/vdr-2.3.2.ebuild ) so aus, als ob da die ARGSDIR-Konfiguration für den VDR genutzt wird, damit gilt die alphanumerische Sortierung der Dateien bzw. Symlinks in /etc/vdr/conf.d/ zu Festlegung der Reihenfolge der Plugins.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wie startest du denn den VDR?


    Danke, systemctl. cat ... kannte ich noch nicht. Man lernt doch nie aus.



    Die Plugins werden aktiviert über:

    Code
    1. eselect vdr-plugin list
    2. Available VDR plugins:
    3. [1] dvb**zensiert**
    4. [2] zensiert *
    5. [3] streamdev-client
    6. [4] streamdev-server *
    7. [5] svdrpservice *
    8. [6] vdrmanager *
    9. [7] vnsiserver *
    10. [8] xineliboutput *


    Wenn ich über vdr-sxfe (xineliboutput) in die Plugin-Einstellungen reingeh, steht das XX-Plugin an der letzten Stelle. Aber die Reihenfolge ist irgendwie immer unterschiedlich.

  • Ich würde mal in /usr/share/vdr/systemd/vdr-systemd_helper.sh nachsehen, wie die Startoptionen für den VDR zusammengebaut werden und was in /var/vdr/tmp/systemd_env landet. Die Konfiguration in /etc/vdr/conf.d/ greift ja nur, wenn der VDR ohne Argumente gestartet wird.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Kann es sein, dass Du das alte und das neuere böse plugin parallel lädst? Du brauchst nur eins von denen.


    vdr-User-# 755 to_h264 chk_r

  • Ich würde mal … nachsehen, … was in /var/vdr/tmp/systemd_env landet.


    Code
    1. VDR_OPTS=" '--chartab=ISO8859-9' '--watchdog=60' '--device=0' '--device=1' '--cachedir=/var/cache/vdr' '--log=0' '--video=/home/sm/Daten/vdr/video' '--record=/usr/share/vdr/bin/vdrrecord-gate.sh' '--plugin=svdrpservice ' '--plugin=vdrmanager -p6420 -Pxbmc -k /etc/vdr/plugins/vdrmanager/vdrmanager.pem -c ' '--plugin=vnsiserver ' '--plugin=xineliboutput --local=none --remote=37890' '--plugin=streamdev-server -r /usr/share/vdr/streamdev/externremux.sh ' '--plugin=sc '"
    2. LANG=de_DE.utf8
    3. LC_COLLATE=


    Allerdings muss ich dazu sagen, dass ich vorm letzten Update die VDR-Start-Unit selbst geschrieben hatte. Die sah in etwa so aus wie die Ausgabe hier. Und obwohl --plugin=sc an erster Stelle stand, hatte ich dasselbe Problem. Ich nehme daher stark an, dass die angegebene Reihenfolge der Plugins keine Rolle für das Ladeverhalten der Plugins durch vdr spielt.


    Kann es sein, dass Du das alte und das neuere böse plugin parallel lädst? Du brauchst nur eins von denen.


    Nein, da hab ich schon drauf geachtet.


    Mit dem neueren "bösen" Plugin hab ich allerdings auch so meine Probleme. Da krieg ich permanent den Fehler:


    Das Problem wurde hier und hier schon mal adressiert. Das Problem wurde damit als gelöst gekennzeichnet, in dem der Socketmodus deaktiviert wurde. Leider tritt das Problem bei mir im Netzwerkmodus auf.

  • Hab mein Problem lösen können.


    Nicht die Ladereihenfolge der Plugins war das Problem. Vielmehr startete der VDR bevor die TV-Karte initialisiert war. Darauf gestoßen bin ich über den Umweg des Dynamite-Plugins.


    Also hab ich mich hingesetzt, den VDR, SC und Dynamite gepatcht und alles compiliert. VDR startete inklusive aller Plugins. Dummerweise kann ich weder über Kodi (VNSI) noch über xineliboutput auf den VDR zugreifen. Entsprechend hab ich das Dynamite-Plugin inkl. sämtlicher Patches wieder runtergeschmissen.


    Tante Google brachte mich nach langer Recherche (leider wird überall abgeblockt, wenn die bösen Plugins im Thread erscheinen) auf eine Systemd-Lösung. Und die funktioniert ausgesprochen gut. Ich geb mal hier 'ne Anleitung:


    1. Die Devices ermitteln
    Meine TV-Karte ist eine Cine S2.

    Code
    1. ls /dev/dvb/adapter*
    2. /dev/dvb/adapter0:
    3. demux0 dvr0 frontend0
    4. /dev/dvb/adapter1:
    5. demux0 dvr0 frontend0


    2. Udev-Regeln



    Daraus bastel ich mir die Datei:


    /etc/udev/rules.d/98-dvb.rules

    Code
    1. KERNEL=="dvb0.demux0", TAG+="systemd"
    2. KERNEL=="dvb0.dvr0", TAG+="systemd"
    3. KERNEL=="dvb0.frontend0", TAG+="systemd"
    4. KERNEL=="dvb1.demux0", TAG+="systemd"
    5. KERNEL=="dvb1.dvr0", TAG+="systemd"
    6. KERNEL=="dvb1.frontend0", TAG+="systemd"


    Das Taggen ist wichtig, damit Systemd die Devices mit systemctl auflistet und diese in den Units verwendet werden können.


    3. Systemd+VDR
    Die mitgelieferte VDR-Unit zu ändern, ist schlecht, da man bei Systemupdates die Änderungen verpasst. Also erweitern wir einfach die Unit:


    /etc/systemd/system/vdr.service.d/01_wait_for_devices.conf


    Abschließender Tralala
    Entweder man startet das System neu, oder man tippt halt folgende Befehle noch ein:

    Code
    1. udevadm control --reload
    2. udevadm trigger
    3. systemctl daemon-reload


    Fazit
    Der Aufwand und das Ergebnis von vdr-dynamite waren irgendwie ernüchternd. Zuviel Patcherei (einen musste ich manuell anpassen). Und hinterher funktionierte es trotzdem nicht.


    Die Identifikation des Problems selbst war auch ein Stochern im Heuhaufen. XVDR+SC lief damals problemlos. Mit Umstieg auf VNSI musste ich dann VDR immer bei der ersten Nutzung 2x starten. VNSI lag da irgendwie als Fehlerquelle nahe. Irgendwelche Ausflüge zum anderen bösen Plugin brachten irgendwie außer einigem Lernerfolg keine brauchbaren Erfolge.


    Jetzt funktioniert alles, wie es soll. Ich hoffe, es hilft anderen, die Suche zu verkürzen.

  • Die udev-Regel kann man deutlich kürzen:

    Code
    1. SUBSYSTEM=="dvb", TAG+="systemd"


    Und wenn man nicht darauf steht alles mehrfach hinzuschreiben, könnte man sich eine generische wait-for-dvb@.service anlegen:

    Die man dann für die beiden Adapter aktiviert:

    Code
    1. systemctl enable wait-for-dvb@{0,1}.service

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi,
    Dynamite geht wohl mit s* nicht mehr...
    Aber wenn du da Patches hast, sende sie doch an mini73...


    Das steht irgendwo...
    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easyvdr.de

  • Leider muss ich den Thread wieder öffnen. Hab mich wohl zu früh gefreut. Das Problem trat in den letzten Tagen dann doch wieder auf. Tut mir leid, wenn in einigen vorherigen Beiträgen ein bisschen Frust mit durchkam.


    Ich hab gestern abend mal vor dem Ausschalten das VNSI-Plugin deaktiviert, einfach um VNSI als Blockierquelle auszuschließen. Und heut früh beim einschalten:
    ARD: klappt
    ZDF: klappt
    Pro7 HD: Sender nicht verfügbar …


    Langsam bin ich echt am Verzweifeln. Mir gehen die Ideen aus, wo ich noch ansetzen kann. Die Holzhammermethode wäre, nach dem Abschluss des Startvorgangs des VDR noch mal einen VDR-Restart durchführen zu lassen.


    Meine bisherigen Erkenntnisse:

    • Start des Rechners (inkl. VDR) nach mehreren (mind. 10?) Stunden: PayTV geht nicht. Sender nicht verfügbar.
    • Start des Rechners nach wenigen Stunden Pause: PayTV geht (Karte noch irgendwie warm?)
    • Restart von VDR nach dem ersten Start: PayTV geht. Wobei ich noch nicht getestet hab, ob es funktioniert, wenn ich VDR restarte, ohne einen Sender aufzurufen.
    • VNSI ist nicht der Übeltäter, was ich eigentlich lange Zeit vermutet hatte.


    Randinfomationen:

    • Das Problem trat zum ersten Mal vor ca. 2 Jahren auf. Damals lief XVDR relativ instabil. Also bin ich auf VNSI umgestiegen.
    • TV-Karte ist eine Digital CIne S2, V6.5. Hab ich jahrelang nur mit einem Tuner betrieben (nur 1 Kabel). Mittlerweile hab ich über einen Unicable-Splitter beide Tuner angeschlossen. Funktioniert soweit auch klasse. Das PayTV-Problem tritt aber unabhängig davon auf.


    Was ist jetzt noch testen werde:

    • EPG abschalten
    • Bis auf VNSI und SC sämtliche andere Plugins (sind ja nur 5) deaktivieren
    • Neustart des VDR gleich nach dem ersten Start, ohne einen Sender aufzurufen
    • Loglevel hochdrehen
    • Wenn alles nichts hilft, eventuell noch mal mit Dynamite rumspielen.


    Btw. der Dynamite-Patch

  • Ich bin einen halben Schritt weiter.


    Ich hab die setup.conf mal verschoben, d.h. mit einer Vanilla-Config für den VDR wieder begonnen.


    Als nächstes hab ich nur die Plugins aktiviert:

    Code
    1. eselect vdr-plugin list
    2. Available VDR plugins:
    3. [1] sc *
    4. [2] streamdev-client
    5. [3] streamdev-server
    6. [4] svdrpservice
    7. [5] vdrmanager
    8. [6] vnsiserver *
    9. [7] xineliboutput *


    D.h. Streamdev, SVRDP, VDRManager sind deaktiviert. Bis jetzt funktioniert es damit schon den 2. Tag in Folge. Ich werd jeden Tag mal etwas an der Config ändern und dann beobeachten, wer der eigentliche Übeltäter ist.


    Viele Grüße

  • So, jetzt hab ich's endgültig geschafft. Schaltet man das Debug-Log ein, dann wird das Problem sichtbar.


    Code
    1. [general.error] socket: name lookup error for …


    Oder mit anderen Worten, das Netzwerk war noch nicht da. Jetzt gibt's als mögliche Dependencies network-target, network-online.target. Das gewünschte Ergebnis brachte allerdings nur systemd-networkd-wait-online.


    /etc/systemd/system/vdr.service.d/02_wait_for_network.conf

    Code
    1. [Unit]
    2. Requires=systemd-networkd.socket
    3. After=systemd-networkd.socket
    4. [Service]
    5. ExecStartPre=/usr/lib/systemd/systemd-networkd-wait-online --interface=wlan0
  • Ja, "Netzwerk da" ist ein schwer zu fassender Zustand (Interface da? IP bekommen? Internet erreichbar? ...), in der systemd Doku gibt es einen langen Abschnitt dazu. In erster Linie dient das Target dazu, damit beim Shutdown Netzwerkdienste vor dem Abschalten des Netzwerks beendet werden.
    Heutzutage sollte jeder Dienst mit dynamischen Netzwerkinterfaces zurecht kommen oder mit systemd Socket Activation arbeiten, dann kümmert sich systemd um die Sockets und niemand braucht mehr darauf zu warten.


    Lars

  • Ich habe den Eindruck, dass es im VDR-Umfeld einiges an Software gibt, bei dem die Empfehlungen am Ende von https://www.freedesktop.org/wi…re/systemd/NetworkTarget/ noch nicht umgesetzt wurden.


    Die Socket-Activation hilft einem soweit ich das verstanden habe nicht bei einem Dienst, der beim Systemstart selbstständig starten soll aber versucht sich ohne INADDR_ANY oder IP_FREEBIND an einen Socket zu binden oder auf Änderungen an der Netzwerkkonfiguration dynamisch reagiert.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • In diesem Fall ist es ein Netzwerkclient, welcher einen Dienst erreichen will, den er nicht erreichen kann und stellt deshalb die Arbeit ein. Man könnte ja einfach ab und an noch mal versuchen, eine Verbindung aufzubauen. Bis dahin gibt es eben nur FTA...


    Lars