streamdev-client Probleme

  • Hallo,

    nach langer Zeit wollte ich vor ungefähr 4 Monaten "mal alles neu machen", weil mich so einiges gestört hatte. yaVDR 0.5 war es glaube ich. Hat bis vor zwei Wochen gedauert, weiterzumachen...


    Egal, jetzt habe ich mit Ansible den DVB-Rechner als Server (headless) und einen Streaming-Client (mit nvidia-GraKa und streamdev-client) auf Basis von Ubuntu 20.04 aufgesetzt.

    Hat auch soweit geklappt, allerdings bekomme ich die Verbindung streamdev-client -> streamdev-server nicht hin. Jedenfalls nicht funktionierend. (Hinweis: stimmt nicht ganz, alle 20 Bootvorgänge etwa kommt der Client mit funktionierender Darstellung hoch (!!!); ein Umschalten scheitert dann aber wieder)


    Ich habe natürlich die channels.conf erstellt (Aufnahmen auf dem Server funktionieren) und auf beiden Rechnern identisch hinterlegt. Ich habe auf dem Server die svdrphosts.conf und streamdevhosts.conf mittels der Einträge in host_vars/localhost angepasst. Mittels des Webservers von streamdev-server kann ich Aufnahmen ansehen, falls das ein Indikator sein sollte und VTP benutzt.


    Das erhalte ich im Log des Clients, wenn ich auf einen Kanal umschalten:


    Das System ist soweit aktuell und mit den Standard-PPA des Ansible-Playbooks ausgestattet:

    Code
    branch: experimental
    ppa_owner: 'ppa:yavdr'
    repositories:
      - '{{ ppa_owner }}/{{branch}}-main'
      - '{{ ppa_owner }}/{{branch}}-vdr'
      - '{{ ppa_owner }}/{{branch}}-kodi'


    Kann mir jemand sagen, was vielleicht ganz einfach ist? Vielen Dank!


    vdr (2.4.7/2.4.7) - The Video Disk Recorder

    conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu

    dbus2vdr (31) - control vdr via D-Bus

    devstatus (0.4.1) - Status of dvb devices

    epgsearch (2.4.1) - search the EPG for repeats and more

    epgsearchonly (0.0.1) - Direct access to epgsearch's search menu

    live (3.1.3) - Live Interactive VDR Environment

    markad (3.0.18) - Mark advertisements

    quickepgsearch (0.0.1) - Quick search for broadcasts

    streamdev-server (0.6.1-git) - VDR Streaming Server

    vnsiserver (1.8.0) - VDR-Network-Streaming-Interface (VNSI) Server

    Edited once, last by cduerr ().

  • Klingt fast so, als würde der Client den Server nicht zulassen, oder?
    Hast du in allen möglichen notwendigen "allow-host"-conf-Files wirklich ALLE deine Server/Clients IPs bzw. das ganze Subnet erlaubt?

    Und warum sagt dein Client zum Server erstmal, dass er die Übertragung bestimmter PIDs beenden soll (DELP 5xxx)?

    Oder ist das normal und das sind die PIDs des vorher geschauten Kanals?

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • Und warum sagt dein Client zum Server erstmal, dass er die Übertragung bestimmter PIDs beenden soll (DELP 5xxx)?

    Oder ist das normal und das sind die PIDs des vorher geschauten Kanals?

    tja, gute Frage, nächste Frage! ;)

    511x klingt nicht gut. Egal auf welchen Kanal ich gehen wollte, die Meldungen blieben dieselben.


    Ich bin aber mittlerweile einen Schritt weiter - und zwar habe ich ein paar Settings, die ich am Anfang geändert hatte um auszuprobieren als es nicht ging auf hier unter Probleme http://www.vdr-wiki.de/wiki/index.php/Streamdev-plugin genannt eingestellt:

    Quote

    Kanal nicht verfügbar/Umschaltproblem

    • Man kann immer nur den Kanal anschauen, welcher auch gerade auf dem VDR-Server eingestellt ist.
    • Lösung:
      • Im OSD: OSD --> Einstellungen --> Plugins --> streamdev-server: Pausierverhalten "immer pausieren"
      • per setup.conf des VDR: streamdev-server.AllowSuspend = 1 streamdev-server.SuspendMode = 1

    Umschaltprobleme wegen Primary Limit

    • Einstellung "Primär-Limit" im Menü "Einstellungen -> Aufnahme" muss auf 0 stehen.
    • Ist ein höherer Wert eingetragen und eine der DVB-Karten im Server wurde zum "Primary Device" ernannt, dann steht diese Karte Streamdev nicht zur Verfügung.

    für letzteres in setup.conf PrimaryDVB=0.

    Außerdem habe ich noch gefunden, dass unter Misc. eine Einstellung für SVDRP peering existiert - die habe ich auf Server und Client mal angemacht.

    Die Fehlermeldungen von oben bekomme ich nicht mehr, "nur noch" ein "Channel not available".


    Klingt fast so, als würde der Client den Server nicht zulassen, oder?
    Hast du in allen möglichen notwendigen "allow-host"-conf-Files wirklich ALLE deine Server/Clients IPs bzw. das ganze Subnet erlaubt?

    ich meine: ja.

    Aber wie gesagt, scheinbar ist *dieses* Problem jetzt schon behoben. Leider weiß ich nicht, was es war.

    Edited once, last by cduerr ().

  • Außerdem habe ich noch gefunden, dass unter Misc. eine Einstellung für SVDRP peering existiert - die habe ich auf Server und Client mal angemacht.

    Das ist unabhängig vom Streamdev-Plugin, damit reden die VDRs übers Netzwerk miteinander (und man kann dann z.B. Timer vom Client aus auf dem Server setzen, so wie es das remotetimers-Plugin früher konnte).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wie viele Tuner hat dein Server? Das Umschalten wird normalerweise nur dann vom Server blockiert, wenn dieser einen Tuner hat und Live-TV wiedergibt - sonst würde ein Kanalwechsel am Client, der einen anderen Transponder benötigt, dazu führen, dass am Server ebenfalls der Kanal gewechselt wird.


    Falls dein Server mehrere Tuner hat, aber der VDR nur einen sieht, musst du ggf. den VDR auf die Tuner warten lassen (das Playbook bietet dafür eine Option: https://github.com/yavdr/yavdr…/focal/group_vars/all#L34 ff.) oder das dynamite-Plugin installieren, damit die Tuner nachträglich eingebunden werden, sobald sie verfügbar werden.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Leider weiß ich nicht, was es war.

    die PIDs und "DELP"-Messages kamen von der Einstellungen "Simultaneously used devices" (>0) in Einstellungen/Streamdev-client.

  • Wie viele Tuner hat dein Server? Das Umschalten wird normalerweise nur dann vom Server blockiert, wenn dieser einen Tuner hat und Live-TV wiedergibt - sonst würde ein Kanalwechsel am Client, der einen anderen Transponder benötigt, dazu führen, dass am Server ebenfalls der Kanal gewechselt wird.

    Sind 3. Werden unter DVB status aber angezeigt. Ich habe die Option im Playbook wait_for_dvb_devices entsprechend hinzugefügt und neu installiert; eine Auswirkung dürfte das dann nicht haben?

    Warum könnte es jetzt noch scheitern?

    Code
    Dec 18 18:25:52 vdr3 vdr: [8616] switching to channel 2 C-1-1019-10302 (arte HD)
    Dec 18 18:25:52 vdr3 vdr: [8616] info: Channel not available!

    Im Server erhalte ich gar keinen Log-Eintrag.

    Edited once, last by cduerr ().

  • hm - da dachte ich, ich hätte schon ein Teilproblem behoben. Aber die "simultaneously used devices" in den Einstellungen ist in der setup.conf übersetzt mit "streamdev-client.StartClient. D.h. wenn ich das auf 0 gesetzt habe, ist der Client gar nicht gestartet worden. Etwas verwirrend, irgendwie.


    Jetzt ist es wieder auf 1 und die Fehlermeldungen vom Anfang ebenso wieder da.

  • tja, gute Frage, nächste Frage!

    511x klingt nicht gut. Egal auf welchen Kanal ich gehen wollte, die Meldungen blieben dieselben.

    die PIDs kommen vom ersten Eintrag der channels.conf, die ich selbst erzeugt habe:

    Das Erste HD;ARD:314000:C0M256:C:6900:5101=27:5102=deu@3,5103=mis@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0

  • Auf meinen Rechnern funktioniert Streamdev - da sieht das so am Server aus:

    Und am Client:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Vielen Dank!


    ...habe ich so angepasst und auch noch die streamdevhosts.conf und svdrphosts.conf auf 0.0.0.0/0 erweitert - Verhalten bleibt dasselbe. Hm.

    Mittendrin habe ich gesehen, dass im Server das Live-Plugin auch streamdev benutzt - da habe ich live.usestreamdev=0 gesetzt, aber brachte auch nichts.

  • Ist die Netzwerkverbindung vom Client zum Server stabil? Hängt da irgendetwas dazwischen, dem man mal einen Neustart gönnen könnte? Gibt es eventuell Hinweise in der Ausgabe von dmesg auf Probleme mit den Netzwerkkarten?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Die sollte stabil sein. End-to-end funktioniert es (bis auf das obige Problem) und der Paketverlust über längere Zeit ist 0. Sind intel-Gigabit-Adapter.


    Könnte das Problem vielleicht beim Aufbau der Datenverbindung entstehen (darauf deutet das Log ja hin)? Gibt es eine lokale Firewall, die angepasst werden müsste?


    Ich finde auch den Eintrag "ERROR: Channel locked (recording)!" im syslog des Servers - ist das damit verbunden? Es läuft kein Recording (erst wieder Montag).

    Ich will hier nicht mit Windows-Denke ankommen, aber: macht es Sinn, die Systeme neu aufzusetzen? Sind nach Anleitung des yavdr-Projekts installiert.

    Edited 6 times, last by cduerr ().

  • Ich finde auch den Eintrag "ERROR: Channel locked (recording)!" im syslog des Servers - ist das damit verbunden? Es läuft kein Recording (erst wieder Montag).

    Was hast du den für die Aufnahme für einen Vorlauf (im OSD) eingestellt? Evtl. blockt der Server das Umschalten, weil er sich schon auf die Aufnahme "vorbereitet"?

    Ich denke, aber doch, dass du noch ein - wie immer geartetes - Verbindungsproblem hast. Blockt dein Router vielleicht bestimmte Ports?

    Viel Erfolg jedenfalls!

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • Vielen Dank!

    Die Verbindung zwischen Server und Client sollte rein geswitcht (Layer2) sein. Zwar habe ich auch eine Fritzbox am Start (und denen trau ich einigen Schund zu; aber die übliche Problematik mit dem MAC-Filter sollte ausgeschlossen sein, wenn die Kommunikation im Prinzip funktioniert). Sie ist auch nur als Router "am Rande" angeschlossen; sämtliche Geräte sind im lokalen Netz und können sich mittels Layer2 direkt erreichen.

    Ich habe mir einen Dump des Netzwerkinterfaces auf dem Server erstellt, während ich umschalten wollten.

    Ich bekommen einen Control-Channel und einen Daten-Channel. Wenn ich mir nur den Daten-Channel angucke, habe ich

    vdrserver (irgendein Port x)->vdr3 (irgendein Port y) TCP, SYN

    vdr3 (y)->vdrserver (x) TCP, SYN, ACK

    vdrserver (x)->vdr3 (y) TCP, ACK

    vdr3 (y)->vdrserver (x) TCP, RST


    Dazwischen (direkt vor dem RST) sind noch ein (für den Control-Channel)

    vdrserver (2004) -> vdr3 (53001) TCP PSH, ACK und

    vdr3 (53001) -> vdrserver (2004) TCP ACK.

    In dem PSH, ACK-Paket ist ein Payload, aber nichts, was ich jetzt entziffern könnte. Da fehlt mir irgendwie die Spezifikation zu.

    Von der Logik her hilft mir das leider auch nicht weiter. Entweder, der Server sagt "gut, ich leg dann mal los!" und der Client bricht unerwartet ab, oder der Server sendet schon eine Info, die den Client veranlasst, den RST zu schicken. Keine Ahnung.


    Was hast du den für die Aufnahme für einen Vorlauf (im OSD) eingestellt? Evtl. blockt der Server das Umschalten, weil er sich schon auf die Aufnahme "vorbereitet"?

    schau ich mir an, danke


    Ist das "Margin at start"? Steht auf den Default-2min.

    Edited 2 times, last by cduerr ().

  • IIRC hatte ich in zwei Netzwerken mit Fritzbox als Router und DHCP-Server merkwürdige Effekte nach dem Wechsel von yaVDR 0.5 zu einer neueren Version auf der selben Maschine, die nach einem Neustart weg waren.


    Hast du mal versucht den Timeout fürs Umschalten am Client etwas hochzusetzen?

    die PIDs kommen vom ersten Eintrag der channels.conf, die ich selbst erzeugt habe:

    Ist die Handgeklöppelt? Hast du mal versucht mit w_scan2 (Paket w-scan2) oder w_scan_cpp (Paket w-scan-cpp) einen Kanalscan zu machen oder gibt es da irgendwelche Besonderheiten bei deinem Kabel-Empfang?


    Ansonsten wäre ein ungekürztes Log des Servers ab Boot (journalctl -b -l > log.txt) interessant, vielleicht sieht man dann, warum da Tuner vermeintlich blockiert sind (IIRC kann das devstatus-Plugin auch Probleme im Zusammenspiel mit streamdev machen).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • IIRC hatte ich in zwei Netzwerken mit Fritzbox als Router und DHCP-Server merkwürdige Effekte nach dem Wechsel von yaVDR 0.5 zu einer neueren Version auf der selben Maschine, die nach einem Neustart weg waren.

    habe ich getan, hat nichts verbessert. Wie gesagt, dass die mitunter komische Dinge tun (vor allem wenn man die Internetsperre aktiviert hat), habe ich auch schon selbst leidvoll erleben dürfen ;) - In dem Fall funktioniert der Handshake, von daher schließe ich die Fritzbox-Paketfilterfunktionalität einfach mal aus.



    Ist die Handgeklöppelt? Hast du mal versucht mit w_scan2 (Paket w-scan2) oder w_scan_cpp (Paket w-scan-cpp) einen Kanalscan zu machen oder gibt es da irgendwelche Besonderheiten bei deinem Kabel-Empfang?

    habe ich mittels w_scan -c de -f c > channels.conf.dvbc.pyur.20211218 erstellt.


    Code
    Das Erste HD;ARD:314000:C0M256:C:6900:5101=27:5102=deu@3,5103=mis@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0
    arte HD;ARD:314000:C0M256:C:6900:5111=27:5112=deu@3,5113=fra@3,5116=mul@3,5117=mis@3:5114;5115=deu,5118=fra,5119=deu:0:10302:1:1019:0
    SWR BW HD;ARD:314000:C0M256:C:6900:5121=27:5122=deu@3,5123=mis@3;5126=deu@106:5124;5125=deu:0:10303:1:1019:0
    SWR RP HD;ARD:314000:C0M256:C:6900:5121=27:5122=deu@3,5123=mis@3;5126=deu@106:5134;5135=deu:0:10304:1:1019:0
    ServusTV HD Deutschland;PYUR:554000:C0M256:C:6900:4920=27:4921=deu@4,4922=eng@4;4924=deu@106:4925:0:1537:61697:49158:0

    Ansonsten wäre ein ungekürztes Log des Servers ab Boot (journalctl -b -l > log.txt) interessant, vielleicht sieht man dann, warum da Tuner vermeintlich blockiert sind (IIRC kann das devstatus-Plugin auch Probleme im Zusammenspiel mit streamdev machen).

    ich probiere mal, das devstatus Plugin zu deaktivieren und würde mich dann mit dem Log noch einmal melden.

  • Devstatus zu deaktivieren (auf Client und Server) hat auch nichts gebracht. Das Log wäre jetzt angefügt.

    Ich mach auch gerne den Debug-Modus für den streamdev-server/-client an - habe nur in der Plugin-Doku nicht den Parameter gefunden, den ich vermutlich in /etc/vdr/conf.d/50-streamdev-server.conf setzen müsste.

    Files

  • so, habe den Server jetzt auf einen USB-Stick neu aufgesetzt - und dasselbe Verhalten. Mit den Default-Einstellungen.


    Was ist denn mit dem cloud-init gemeint? Ich fand die Auswahl auf der Ubuntu-Seite sehr verwirrend. Da stand was mit cloud-init, also habe ich nicht gleich das genommen, sondern noch auf die anderen Options geklickt. Das Ergebnis war dann aber ein Ubuntu 20.04._02_, wo beim Boot ganz viele cloud-init-Meldungen durchflitzen. Könnte das damit zu tun haben? Bis jetzt habe ich nur gelesen, dass der vielleicht bei X Probleme macht (hier betreibe ich aber headless ohne X), außerdem bekomme ich beim Betrachten der Playbook-Ausgaben den Eindruck, dass das deaktiviert werden können sollte.


    Hm. Oder es liegt am Client. Argh. Wo ist der nächste USB-Stick?

    Edited once, last by cduerr ().

  • Mit yaVDR-Ansible darf/soll cloud-init NICHT installiert werden, afaik.

    Lt. Doku muss es Ubuntu-Server ohne cloud-init sein.

    btw: hab übrigens auch neuerdings eine Fritzbox und keinerlei VDR-Probleme damit.

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!