streamdev: Verbindung stirbt, wenn anderer Client zappt

  • Ein Zapvorgang ohne Nebenwirkungen:


    Mar 22 19:58:28 tvserver vdr: [1905] TS buffer on device 2 thread ended (pid=1051, tid=1905)
    Mar 22 19:58:28 tvserver vdr: [1904] buffer stats: 185556 (4%) used
    Mar 22 19:58:28 tvserver vdr: [1904] receiver on device 2 thread ended (pid=1051, tid=1904)
    Mar 22 19:58:28 tvserver vdr: [2095] receiver on device 2 thread started (pid=1051, tid=2095)
    Mar 22 19:58:28 tvserver vdr: [2096] TS buffer on device 2 thread started (pid=1051, tid=2096)
    Mar 22 19:58:31 tvserver vdr: [1903] streamdev-livestreaming thread ended (pid=1051, tid=1903)
    Mar 22 19:58:31 tvserver kernel: [ 3794.797378] stb6100_set_bandwidth: Bandwidth=61262500
    Mar 22 19:58:31 tvserver kernel: [ 3794.800672] stb6100_get_bandwidth: Bandwidth=62000000
    Mar 22 19:58:31 tvserver kernel: [ 3794.811831] stb6100_get_bandwidth: Bandwidth=62000000
    Mar 22 19:58:31 tvserver vdr: [2096] TS buffer on device 2 thread ended (pid=1051, tid=2096)
    Mar 22 19:58:31 tvserver vdr: [2095] buffer stats: 92872 (2%) used
    Mar 22 19:58:31 tvserver vdr: [2095] receiver on device 2 thread ended (pid=1051, tid=2095)
    Mar 22 19:58:31 tvserver vdr: [1902] streamdev-writer thread ended (pid=1051, tid=1902)
    Mar 22 19:58:31 tvserver vdr: [1080] buffer stats: 185932 (4%) used
    Mar 22 19:58:31 tvserver vdr: [1080] buffer stats: 0 (0%) used
    Mar 22 19:58:31 tvserver vdr: [1080] buffer stats: 0 (0%) used
    Mar 22 19:58:31 tvserver vdr: [1080] Streamdev: Setting data connection to 192.168.0.7:53566
    Mar 22 19:58:31 tvserver vdr: [2097] streamdev-writer thread started (pid=1051, tid=2097)
    Mar 22 19:58:31 tvserver vdr: [2098] streamdev-livestreaming thread started (pid=1051, tid=2098)
    Mar 22 19:58:31 tvserver vdr: [2099] receiver on device 2 thread started (pid=1051, tid=2099)
    Mar 22 19:58:31 tvserver vdr: [2100] TS buffer on device 2 thread started (pid=1051, tid=2100)
    Mar 22 19:58:31 tvserver kernel: [ 3794.888922] stb6100_set_frequency: Frequency=1236000
    Mar 22 19:58:31 tvserver kernel: [ 3794.891203] stb6100_get_frequency: Frequency=1235988
    Mar 22 19:58:31 tvserver kernel: [ 3794.900040] stb6100_get_bandwidth: Bandwidth=62000000
    Mar 22 19:58:34 tvserver vdr: [1051] connect from 192.168.0.215, port 50172 - accepted
    Mar 22 19:58:34 tvserver vdr: [2100] TS buffer on device 2 thread ended (pid=1051, tid=2100)
    Mar 22 19:58:34 tvserver vdr: [2099] buffer stats: 51700 (1%) used
    Mar 22 19:58:34 tvserver vdr: [2099] receiver on device 2 thread ended (pid=1051, tid=2099)
    Mar 22 19:58:34 tvserver vdr: [2102] receiver on device 2 thread started (pid=1051, tid=2102)
    Mar 22 19:58:34 tvserver vdr: [2103] TS buffer on device 2 thread started (pid=1051, tid=2103)
    Mar 22 19:58:34 tvserver vdr: [1051] ERROR: no OSD provider available - using dummy OSD!
    Mar 22 19:58:34 tvserver vdr: [1051] closing SVDRP connection

  • Die frontends sind gleichwertig. Nun wäre noch ein Log vom Umschalten mit Nebenwirkung und -l3 spannend. Am besten ab dem Zeitpunkt zu dem sich der erste der beiden Clients verbindet, damit sich die Thread-IDs im Log dem jeweiligen Client eindeutig zuordnen lassen.

  • Gerade gab es Nebenwirkungen. Ich habe mit dem VLC den Kanal gewechselt (vulgo: Verbindung beendet und neu aufgerufen), danach stand dann der vdr-client.


    192.168.0.7 ist der vdr-client
    192.168.0.215 ist VLC


    Log des Servers


    Verbindungsaufbau


    VDR:


    Code
    Mar 27 20:05:23 tvserver vdr: [1049] Streamdev: Accepted new client (VTP) 192.168.0.7:47641
    Mar 27 20:05:23 tvserver vdr: [1049] streamdev-server TUNE S19.2E-1-1101-28106: Priority unknown - using 0
    Mar 27 20:05:23 tvserver vdr: [1049] buffer stats: 0 (0%) used
    Mar 27 20:05:23 tvserver vdr: [1049] buffer stats: 0 (0%) used


    VLC:


    Code
    Mar 27 21:43:40 tvserver vdr: [1049] Streamdev: Accepted new client (HTTP) 192.168.0.215:53464
    Mar 27 21:43:41 tvserver vdr: [3326] streamdev-writer thread started (pid=1020, tid=3326)
    Mar 27 21:43:41 tvserver vdr: [3327] streamdev-livestreaming thread started (pid=1020, tid=3327)
    Mar 27 21:43:41 tvserver vdr: [3329] receiver on device 4 thread started (pid=1020, tid=3329)
    Mar 27 21:43:41 tvserver vdr: [3330] TS buffer on device 4 thread started (pid=1020, tid=3330)
    Mar 27 21:43:41 tvserver vdr: [3328] ecmhandler 3 filter thread started (pid=1020, tid=3328)


    Vorfall:



    Log des VDR-Clients:


  • Zu welchem Zeitpunkt im langen "Vorfall"-Log schaltet VLC denn um? Ich vermute, das hier ist der richtige Zeitraum?

    Zitat

    Mar 27 21:51:29 tvserver vdr: [1049] ERROR: read from client (HTTP) 192.168.0.215:53464 failed: Connection reset by peer
    ...
    Mar 27 21:51:33 tvserver vdr: [1049] Streamdev: Accepted new client (HTTP) 192.168.0.215:53639


    Zwischen den beiden Zeilen werden nur Threads mit IDs zwischen 3326 und 3330 beendet. Das sind genau die Threads die nach dem Verbindungsaufbau von VLC gestartet wurden. Passt also soweit.


    Der mögliche Verursacher des Problems könnte in dieser Zeile liegen:

    Zitat

    Mar 27 21:51:33 tvserver vdr: [1049] ERROR: streamdev-writer thread 3326 won't end (waited 3 seconds) - canceling it...


    Der streamdev-server ist 3 Sekunden blockiert, da er auf das Beenden der HTTP-Netzwerk-Verbindung wartet. Sollte nun innerhalb dieser Zeit der VDR-Client irgendetwas vom Server anfordern, läuft dieser Befehl wegen des Timeouts von 1,5 Sekunden auf einen Fehler und beendet die Verbindung.


    Ich werden in den nächsten Tagen auf jeden Fall den Fehler beheben, dass sich der streamdev-writer thread nicht zeitnah beendet. Falls Du schon vorher experimentieren willst, könntest Du den Timeout auf dem Client von 1,5 auf 4 Sekunden erhöhen. Du musst folgende Zeile in der Datei client/socket.h anpassen:

    Code
    bool Command(const std::string &Command, uint Expected = 0, uint TimeoutMs = 1500);
  • Hallo Schmirl,


    ... das war's! Es funktioniert!!!


    Ich hab die Änderung eingebracht und es funzt. Dann nochmal zurück und Fehler ist wieder da!


    Es ist nachvollziehbar: Immer wenn am Server:

    Code
    Mar 29 16:14:59 debian vdr: [8432] ERROR: read from client (HTTP) 192.168.6.145:1132 failed: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
    Mar 29 16:14:59 debian vdr: [8432] streamdev: closing streamdev connection to 192.168.6.145:1132
    Mar 29 16:14:59 debian vdr: [8962] streamdev-livestreaming thread ended (pid=8400, tid=8962)
    Mar 29 16:15:00 debian vdr: [8964] TS buffer on device 3 thread ended (pid=8400, tid=8964)
    Mar 29 16:15:00 debian vdr: [8963] buffer stats: 146452 (3%) used
    Mar 29 16:15:00 debian vdr: [8963] receiver on device 3 thread ended (pid=8400, tid=8963)
    Mar 29 16:15:02 debian vdr: [8432] ERROR: streamdev-writer thread 8961 won't end (waited 3 seconds) - canceling it...


    dann kommt am Client:

    Code
    Mar 29 16:15:01 ubuntu vdr: [1974] Streamdev: Lost connection to 192.168.6.15:2004: Die Wartezeit für die Verbindung ist abgelaufen


    vG
    WoZ

    Clients
    VDR1: yaVDR 0.5 stable auf ZOTAC ION A 4Gbyte RAM / mit ATRIC - IR - Einschalter softhddevice per streamdev am Server
    VDR2 / VDR3: MLD 5.1 auf Raspberry pi3
    2 x VOMP 0.4 auf mediamvp
    Server
    Cubietruck, Lubuntu Trusty, vdr aus yaVDR - sourcen, 1 x TT S2-3600, 1 x TT S2-3650 CI, 1 x sundtek SkyTV III, 1 x sundtek SkyTV IV

  • Ich habe den Patch mal eingebaut. Vielen lieben Dank!


    Mein zweites Problem -- dass der VLC-Client nach einiger Zeit ständig Ring Buffer Overflows hat und diese irgendwann als Decoding-Fehler sichtbar werden, hat damit dann wahrscheinlich nichts zu tun. Vielleicht habe ich mir hier auch den Zusammenhang zwischen Umschalten und Eintreten des Fehlers eingebildet. Ich werde das weiter beobachten.


    Viele Grüße,
    Olli

  • Hallo Schmirl,


    viene Dank! Ich werde dann mal den Compiler anwerfen!
    Willst Du eigentlich auch das suspend - Verhalten (dieser Patch) über das setup konfigurierbar machen?


    vG
    Wolfgang

    Clients
    VDR1: yaVDR 0.5 stable auf ZOTAC ION A 4Gbyte RAM / mit ATRIC - IR - Einschalter softhddevice per streamdev am Server
    VDR2 / VDR3: MLD 5.1 auf Raspberry pi3
    2 x VOMP 0.4 auf mediamvp
    Server
    Cubietruck, Lubuntu Trusty, vdr aus yaVDR - sourcen, 1 x TT S2-3600, 1 x TT S2-3650 CI, 1 x sundtek SkyTV III, 1 x sundtek SkyTV IV

    3 Mal editiert, zuletzt von woz ()

  • Ich weiß nicht ob es das selbe Problem ist aber zumindest der Titel passt.
    Ich habe streamdev server mit git von heute und zwei Streamdev Clients.



    Nach ein paar Minuten bleibt das Bild beim Client stehen.


    Server



    Client



    setup.conf vom Server



    Der Client in diesem Beispiel ist ein 0.5.0-pre aber ich habe das selbe Problem mit einem yavdr Client der eine recht aktuelle Version hat.


    Jemand eine Idee?

  • Ich habe nun erst mal den EPG Scan Timer auf 0 gesetzt


    Code
    EPGScanTimeout = 0


    Scheinbar keine Aussetzer mehr.
    Ist aber auch keine echte Lösung.
    Kann zwar nun den EPG Scan per Cron Job machen aber so toll finde ich das nicht.

  • Wie - Dein Client startet einen epgscan über streamdev-client während Du über streamdev-client Live-TV schaust?


    Ob Dein yavdr schon den in diesem Thread diskutierten Fix beinhaltet, weiß ich nicht. Wenn die Meldungen exakt die selben sind, dann eher nicht. Auch die Server-Version spielt eine Rolle. Um auf Nummer sicher zu gehen, könntest Du im Client mal den Workaround aus meinem Posting von oben versuchen. Setze den Timeout aber gleich auf 10000 Millisekunden.

  • Nein der Client startet keinen EPG Scan.
    Die oben genannten Einstellungen habe ich beim Server gemacht.


    Der Server von Yavdr war relativ aktuell, es fehlt nur noch die letzte Änderung die jedoch nur noch den Patch etwas optimiert. Aber wie gesagt, der Server ist jetzt auf den neusten git Stand.
    Ich werde heute noch mal ein Wireshark trace machen. Mal sehen welche Seite zuerst aufhört Daten zu senden.
    Das Problem ist wohl immer noch da jedoch nicht mehr so Häufig.

  • So ich habe nun mal einen Wireshark Trace gemacht.
    Für mich sieht es so aus als wenn alles OK läuft.


    Kennt sich da jemand besser aus und hat Lust den Trace zu analysieren?
    Könnte mit Syslog auf Client und Server Seite + Wireshare Trace dienen.

Jetzt mitmachen!

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