Einrichtung von VDR-VDR-Streaming unter Debian Stretch

    Hallo,


    erstmal zu den Voraussetzungen:

    Im Netzwerk gibt es einen VDR-Server, derzeit 2 VDR-Clients und einen MLD 5.4- Client.


    VDR-Server (NAS):

    Code
    OS: Debian Stretch 9 (mit Backports)
Kernel: 4.18.0-0.bpo.1-amd64
NIC: Intel I340-T4 (4xGLan, bonding-RR)
VGA: NVIDIA GK208 (nur zu TEstzwecken, Betrieb normalerweise "headless")
HDD: mehrere RAID, davon 1x 4TB Raid für Videos (vdr-Verzeichnis)
DVB-s: DigitalDevices CineS2 v6.5 mit 3x FlexKarte DVB-s
VDR-Ausgabe: keine
VDR-Version: 2.4.0-2~etobi1
weitere Dienste: LDAP-Server, MariaDB, NFS, Samba-Server, CUPS-Server, Apache (u.a. vdradmin-am)



    VDR-Client1:

    Code
    OS: Debian Stretch 9 (mit Backports)
Kernel: 4.18.0-0.bpo.1-amd64
NIC: onboard, NVIDIA MCP55 (2xGLan, bonding-RR)
VGA: NVIDIA GK104
HDD: mehrere, NFS-Mount für Videos (vdr-Verzeichnis)
DVB-s: keine
VDR-Ausgabe: über SoftHDDevice- Plugin
VDR-Version: 2.4.0-2~etobi1
weitere Clients: LDAP, NFS, CUPS


    VDR-Client2:

    Code
    OS: Debian Stretch 9 (mit Backports)
Kernel: 4.18.0-0.bpo.1-amd64
NIC:  onboard (1xGLan)
VGA: NVIDIA
HDD: 1x, NFS-Mount für Videos (vdr-Verzeichnis)
DVB-s: keine
VDR-Ausgabe: über SoftHDDevice- Plugin
VDR-Version: 2.4.0-2~etobi1
weitere Clients: LDAP, NFS, CUPS


    VDR-Client3:

    Code
    RaspberryPi 2
OS: MiniLinuxDVB MLD 5.4
Kernel: MLD-Kernel
NIC:  intern
VGA: "Pi", Ausgabe: HDMI
HDD: 1x 8GB SD-Karte, NFS-Mount für Videos (vdr-Verzeichnis)
DVB-s: keine
VDR-Ausgabe: über rpiHDDevice- Plugin
VDR-Version: 2.4 von MLD
weiter Clients: LDAP, NFS


    Ziel:

    1. Es soll ein VDR-Server im Haus die Client-Rechner mit Live-Fernsehen und den zentral gespeicherten Aufnahmen per VDR-VDR-Streaming ("streamdev-server" und "streamdev-client") versorgen. Die Senderlisten sollen identisch sein. Ggf. sollen die Clienten nicht selbst nach neuen Sendern suchen, sondern die Listen von Zeit zu Zeit von Hand ersetzt/ aktualisiert werden.

    2. Das Videoverzeichnis (/var/lib/video auf dem jeweiligen Client) soll per NFS eingebunden werden, um allen die Aufnahmen zur Verfügung zu stellen.

    3. Die Bearbeitung (Schnitt/ Werbung entfernen) soll nur an Client1 erfolgen. Deshalb sollen am Ende die Clients unterschiedliche Nutzer für den VDR bekommen (per LDAP gesteuert). Die anderen Client-Rechner sollen nur Leserechte bekommen. (Problem: Timeshift, wie kann man das kombinieren? Event. ein zweites Videoverzeichnis? Geht das überhaupt? Wenn nicht: wie kann ich das Timeshift deaktivieren?)

    4. Aufnahmen (Timer) werden per "vdradmin-am" auf dem Server gesteuert/ verwaltet.

    5. Außerdem sollen die EPG-Daten in eine SQL-Datenbank auf dem Server gespeichert werden und bei den Clienten dann aus der DB abgerufen werden, damit die Clients nicht selbst alles neu scannen/ abrufen müssen.

    6. IP-TV soll auf dem Server und jedem Client in die normale Programmliste aufgenommen werden und als "normales" Fernsehprogramm angesehen werden. Ideal wäre ein Relay auf dem Server, damit im Fall, dass 2 Clients den selben Stream schauen dieser nur 1x per Internet abgerufen wird (ähnlicht dem Paket "streamdev-server" für Musikstreams).

    7. Auf CLient1 soll ein HDMI-USB3.0- Adapter (Inogeni), der für eine Kamera genutzt wird als "Programm" eingebunden werden.

    8. Auf Server und Client1/2 sollen später ggf. auch USB-Webcams als Programm bzw. auch später noch Überwachungskameras auf dem Server eingebunden werden.


    Probleme:

    1. VDR Client bricht immer wieder ab

    2. Installation/ Einrichtung von eepgd mit SQL-DB (auf Server)

    3. unterschiedliche VDR-Nutzer auf den Clients mit einem Video-DIR

    4. Problem mit eepgd- Einrichtung

    5. IPTV funktioniert nur auf dem MLD und ich komme mit der Einrichtung auf den Debian-Clients bzw. dem Server nicht klar

    6. Wie kann ich den Inogeni-Adapter korrekt einbinden und, im Idealfall, auch anderen Clients oder dem Server verfügbar machen?

    Kommen wir zu Problem 1:

    Auf allen Debian-Clients hängt die Wiedergabe der Sendungen immer wieder. Manchmal verschwindet auch das "SoftHDDevice"- Fenster. Ich kann das Problem auch "provozieren", indem ich mit dem Mausrad "scrolle" (Mauspfeil über Ausgabefenster). Auf dem MLD habe ich das noch nicht beobachtet. Dort kann ich hin- und herschalten, ohne "Hänger"/ Absturz. Der VDR "fängt" sich meist nicht wider und ich muss auf dem Client mittels "systemctl restart vdr.service" das ganze neu starten.

    Da die Rechner nur "nebenbei" als VDR-Client dienen, wird der VDR-Client "detached" gestartet und per Script das Ausgabefenster als normales FEnster unter KDE geöffnet. Dazu sendet das Script "/usr/bin/svdrpsend plug softhddevice stat", ermittelt damit den Status und öffnet das Fenster mit "/usr/bin/svdrpsend plug softhddevice atta". Gleichzeitig wird ggf. das Compositing mit "qdbus org.kde.KWin /Compositor suspend" ausgesetzt. Beim Beenden wird das nat. alles wieder rückgängig gemacht.


    Während des Problems zeigt das "journal" folgende Einträge auf dem Client namens "dorsy":

    Teil 2 zu Problem 1:


    Die "alsa" Einträge werden endlos wiederholt. Die Ausgabe zeigt mehrere FEhler. Normalerweise steht da nicht so viel. Was aber immer in einem solchen Fehlerfall im Log auftaucht, ist die Zeile mit "ERROR: xx TS packet(s) not accepted in Transfer Mode".


    Der Server-VDR wird mit folgenden Optionen gestartet:



    Der Client-VDR auf Client1 wird mit folgenden Optionen gestartet:



    Nun stellt sich natürlich die Frage, wie man das beheben kann? Woran liegt das? Das Problem trat i.Ü. auch schon mit Debian Jessie auf und ist nun nach dem Wechsel auf Stretch aber schlimmer/ häufiger geworden! Auch stürzt der VDR bzw. SoftHDDevice auch gern beim schnellen Vor-/ Rücklauf bei Aufnahmen auf.

    Hat jemand eine Idee/ einen Tipp, wie ich das Problem finden/ beheben kann?

    Hi,

    Im Übrigen nutzen nur sehr wenige aktuelle Versionen der Systeme mit VDR. An den Distris arbeiten auch nur wenige (sehr aktive!).


    Daher hat kaum einer die Fehler denke ich...


    Und so ein Setup ist nicht mal so eben aufgesetzt.


    Mach doch eins nach dem anderen...


    Eepg etc. Ist doch vollkommen unwichtig...


    Erst mal Ton...


    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.easy-vdr.de

    Hallo,


    Das mit den Logs in die Code-Tags habe ich in meiner Verzweiflung glatt vergessen. Natürlich nehme ich die Kritik an und habe das geändert.

    Das Thema "zu neues System", na ja, ich hatte die Probleme auch schon unter "Jessie" und vdr 2.2, nur nicht so schlimm. Das das alles nicht trivial ist, ist mir natürlich auch klar, deshalb wollte ich das auch Schritt für Schritt durchgehen. Außerdem habe ich auch schon auf das Thema "Themes/ Skins" verzichtet.

    Da der neue vdr 2.4 ja einen "Watchdog" mitbringt, der eigentlich zum Neustart beim Einfrieren führen sollte, hatte ich die Hoffnung, dass zum einen der neue vdr das Verhalten (Einfrieren) nicht mehr zeigt oder sich eben selbst neu startet. Leider ist dem eben nicht so.


    Ich glaube auch, dass ich eine Spur gefunden habe. Auf dem Client war das zentrale Video-/Aufnahmenverzeichnis eingebunden und per "bind"-mount in "/var/lib/video" eingehangen. Seit dem ich den Bind-Mount entfernt und das zentrale Videoverzeichnis als separaten Eintrag beim vdr- Starten mit gebe, hängt der vdr nur kurz und fängt sich meist wieder. Die Zeilen mit "invalid TS packets" und die "alsa delay" Meldungen erscheinen aber weiterhin im Log/Journal.


    Was bedeuten die "invalid TS packets"? Ist das Problem eher Server- oder Client-Seitig oder gar im Netzwerk zu suchen?

    Gibt es noch einen Weg besser zu sehen, was im Fehlerfall passiert?


    MfG

    SNR

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden