Streamdev: Server bzw. Hauptrechner fährt nach Streaming nicht mehr runter

  • Hallo Leutz,


    ich bin jetzt endlich mal dazu gekommen mir einen funktionierenden Streamdev-Client zu basteln. Das Streamen mittels streamdev-server (0.5.0~pre20090706+cvs20100307.2102-2yavdr1) bzw. -client (yavdr 0.3.0a) funzt 1a. Der Hauptrechner (siehe Sig) fährt allerdings nicht mehr runter sobald mal der Client aktiv war. Wenn man den Hauptrechner ausschalten will, erscheint die Meldung "Streaming aktiv - trotzdem herunterfahren?". Der Client ist aber schon mindestens 20Minuten nicht mehr aktiv.
    Ist das eine Einstellungssache? Denke wohl nicht, hab mir mal alles angesehen was ich finden konnte. Beim Streaming via http tritt das Problem übrigens nicht auf.


    Markus

    Streamingclient 1:
    [-] RaspiVDR MLD 5.x an Panasonic TV mit CEC :D


    Streamingclient 2:
    [-] RaspiVDR MLD 5.x - Samsung TV mit CEC


    Streamingserver:
    [---] Proxmox Server PVE7
    [- ] MLD 5.x Server - OctopusNet 4 Tuner

  • Ich hab nochmal gestestet: Client gestartet, bisschen rumgezappt und wieder ausgeschalten. Nach ca. 30 Minuten (!) seh ich am Server immer noch eine Verbindung zum Clienten:



    markus@srv2-tv:~$ netstat -nt
    Aktive Internetverbindungen (ohne Server)
    Proto Recv-Q Send-Q Local Address Foreign Address State
    tcp 0 0 10.10.1.75:2004 10.10.1.71:35924 VERBUNDEN
    tcp 52 0 10.10.1.75:22 10.10.1.78:49688 VERBUNDEN


    Anscheinend trennt der Client beim runterfahren nicht sauber, kann das jemand bestätigen? Gibts da beim runterfahren vielleicht ne Option um das zu machen?


    Markus

    Streamingclient 1:
    [-] RaspiVDR MLD 5.x an Panasonic TV mit CEC :D


    Streamingclient 2:
    [-] RaspiVDR MLD 5.x - Samsung TV mit CEC


    Streamingserver:
    [---] Proxmox Server PVE7
    [- ] MLD 5.x Server - OctopusNet 4 Tuner

    Einmal editiert, zuletzt von MarkusH ()

  • So, den Client zweimal neu gebootet und es werden mehr:


    markus@srv2-tv:~$ netstat -nt
    Aktive Internetverbindungen (ohne Server)
    Proto Recv-Q Send-Q Local Address Foreign Address State
    tcp 0 0 10.10.1.75:2049 10.10.1.71:917 VERBUNDEN
    tcp 0 0 10.10.1.75:2004 10.10.1.71:41221 VERBUNDEN
    tcp 0 0 10.10.1.75:2004 10.10.1.71:38748 VERBUNDEN
    tcp 0 0 10.10.1.75:2004 10.10.1.71:35924
    VERBUNDEN
    tcp 0 0 10.10.1.75:22 10.10.1.78:49688 VERBUNDEN
    tcp 0 0 10.10.1.75:35165 10.10.1.71:48402 VERBUNDEN


    Kann das mal jemand test ob das bei ihm auch so ist, dass der Server die alten Verbindungen nicht rauswirft?


    Markus

    Streamingclient 1:
    [-] RaspiVDR MLD 5.x an Panasonic TV mit CEC :D


    Streamingclient 2:
    [-] RaspiVDR MLD 5.x - Samsung TV mit CEC


    Streamingserver:
    [---] Proxmox Server PVE7
    [- ] MLD 5.x Server - OctopusNet 4 Tuner

  • Clients melden sich bei mir alle sauber ab. Wird Dein VDR sauber runtergefahren? Im Log sollte die Meldung "deleting plugin: streamdev-client" zu finden sein und der exit code von VDR sollte 0 sein. Oder wird evtl. das Netzwerk vor VDR gestoppt?

  • Zitat

    Original von schmirl
    Clients melden sich bei mir alle sauber ab. Wird Dein VDR sauber runtergefahren? Im Log sollte die Meldung "deleting plugin: streamdev-client" zu finden sein und der exit code von VDR sollte 0 sein. Oder wird evtl. das Netzwerk vor VDR gestoppt?


    Muss ich prüfen, der Client ist wie gesagt ein yaVDR 0.3. Werd mir heut abend mal das Log von dem Client anschauen, muss nur noch überlegen wie ich das anstelle.
    Kann das evtl. auch mit den unterschiedlichen streamdev-Versionen zusammenhängen, oder ist das egal?

    Streamingclient 1:
    [-] RaspiVDR MLD 5.x an Panasonic TV mit CEC :D


    Streamingclient 2:
    [-] RaspiVDR MLD 5.x - Samsung TV mit CEC


    Streamingserver:
    [---] Proxmox Server PVE7
    [- ] MLD 5.x Server - OctopusNet 4 Tuner

  • Hallo,


    den Verdacht einer hängenden Verbindung hatte ich auch schon. Speziell beim Basteln (mit häufen Reboots) wurden nämlich hin und wieder laufende Streams durch das Umschalten eines anderen Clients "abgeklemmt", trotz mehr als ausreichend Karten im Server.


    Allerdings bekomme ich die Probleme gerade nicht reproduziert.
    Hier läuft streamdev 0.5.0+cvs20100804-2yavdr6 - also yavdr 0.3


    Grüße,
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

    Einmal editiert, zuletzt von hsteinhaus ()

  • Jetzt hab ichs doch noch hinbekommen. Der Client fährt eigentlich sauber runter, das Plugin wird ordentlich gelöscht. Allerings gibts eine seltsame Meldung:


    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

  • Und noch eine ähnliche Situation aus den Logs, dieses mal aus Server-Sicht.


    Der Client wurde um 23:39 ausgeschaltet, der Server hat die Verbindung jedoch erst um 01:50 für tot erklärt...


    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

  • Hier mal mein Log, sieht eigentlich auch ok aus:


    Streamingclient 1:
    [-] RaspiVDR MLD 5.x an Panasonic TV mit CEC :D


    Streamingclient 2:
    [-] RaspiVDR MLD 5.x - Samsung TV mit CEC


    Streamingserver:
    [---] Proxmox Server PVE7
    [- ] MLD 5.x Server - OctopusNet 4 Tuner

  • Am Server siehts bei mir eigentlich genau so aus:


    Code
    Oct 28 21:11:52 srv2-tv vdr: [1268] Streamdev: Accepted new client (VTP) 10.10.1.71:53956
    Oct 28 23:13:56 srv2-tv vdr: [1268] ERROR: read from client (VTP) 10.10.1.71:38748 failed: Connection timed out
    Oct 28 23:22:35 srv2-tv vdr: [1268] ERROR: read from client (VTP) 10.10.1.71:41221 failed: Connection timed out


    Der Client wurde um ~22:02 runtergefahren, aber erst um 23:22 hat der Server die Verbindung gekappt.


    Könnte man da beim runterfahren am Client was ausführen um die Verbindung nochmal explizit zu beenden?

    Streamingclient 1:
    [-] RaspiVDR MLD 5.x an Panasonic TV mit CEC :D


    Streamingclient 2:
    [-] RaspiVDR MLD 5.x - Samsung TV mit CEC


    Streamingserver:
    [---] Proxmox Server PVE7
    [- ] MLD 5.x Server - OctopusNet 4 Tuner

    Einmal editiert, zuletzt von MarkusH ()

  • Wenn ich den Client jetzt runterfahr, sehe ich am Server folgendes:



    Trotzdem bleibt die Verbindung am Server:

    Code
    markus@srv2-tv:~$ netstat -nt
    Aktive Internetverbindungen (ohne Server)
    Proto Recv-Q Send-Q Local Address           Foreign Address         State
    tcp        0      0 10.10.1.75:22           10.10.1.78:49592        VERBUNDEN
    tcp        0      0 10.10.1.75:2004         10.10.1.71:59775        VERBUNDEN

    Streamingclient 1:
    [-] RaspiVDR MLD 5.x an Panasonic TV mit CEC :D


    Streamingclient 2:
    [-] RaspiVDR MLD 5.x - Samsung TV mit CEC


    Streamingserver:
    [---] Proxmox Server PVE7
    [- ] MLD 5.x Server - OctopusNet 4 Tuner

    Einmal editiert, zuletzt von MarkusH ()

  • Sieht nach dem selben Problem aus. In den Client-Logs von euch beiden steht folgende Meldung:

    Zitat

    Streamdev: Lost connection to x.x.x.x:2004: Connection timed out


    Würde meinen Verdacht untermauern, dass evtl. schon das Netzwerk gestoppt wird während VDR noch herunterfährt. Prüft doch bitte mal, ob z.B. ein ping an den Server möglich ist nachdem VDR gestoppt wurde.

  • Ok, werd ich heut abend mal testen

    Streamingclient 1:
    [-] RaspiVDR MLD 5.x an Panasonic TV mit CEC :D


    Streamingclient 2:
    [-] RaspiVDR MLD 5.x - Samsung TV mit CEC


    Streamingserver:
    [---] Proxmox Server PVE7
    [- ] MLD 5.x Server - OctopusNet 4 Tuner

  • Hallo,


    ich habe soeben etwas getestet - der Fehler ist auch durch ein einfaches "stop vdr" ohne Herunterfahren des Clients zu provoziern. Interessanterweise scheint das Problem gehäuft aufzutreten, wenn mehr als ein Client gestartet wurden, bevor der erste beendet wird.


    Das ganze scheint seine Ursache in mindestens zwei Bugs im Streamdev-Plugin zu haben:


    1.) unter bestimmten Umständen muss es eine Art Race Condition im Client geben, die die Socket-Verbindung kappt, bevor der Befehl "Quit" gesendet wird


    2.) Der Server kümmert sich nicht um hängende Streams: er startet einen Thread je stream, wenn der Thread leise stirbt, räumt niemand die Verbindung weg. Dieser ist m.e. der gravierendere Bug. Leider ist die Sache nicht mit ein oder zwei Zeilen zu fixen,


    Als Hotfix habe ich bei mir erst mal die folgenden Zeilen in die /etc/sysctl.conf eingetragen:


    Code
    #/proc/sys/net/ipv4/tcp_keepalive_time
    net.ipv4.tcp_keepalive_time = 30
    #/proc/sys/net/ipv4/tcp_keepalive_probes
    net.ipv4.tcp_keepalive_probes = 2
    #/proc/sys/net/ipv4/tcp_keepalive_intvl
    net.ipv4.tcp_keepalive_intvl = 15


    Damit wird nach etwa einer Minute die hängende Verbindung vom Betriebssystem entsorgt.


    Grüße,
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

    2 Mal editiert, zuletzt von hsteinhaus ()

  • Ok, habs getestet. Der Client ist nach stoppen des VDR nach wie vor erreichbar (ping und ssh). Die offene Verbindung verschwindet dann auch nach kurzer Zeit. Und vor allem: Das funktioniert immer! Ich kann also am Client den vdr starten und stoppen wie ich will, die Verbindung wird immer sauber getrennt (4 x hintereinander probiert). Logfile:


    Und jetzt kommts: Fahre ich den Client komplett herunter kommt es nicht zu einer sauberen Trennung - Ausschnitt aus dem Log am Server:


    Hier fehlt das "closing streamdev connection" wie es im log zu lesen ist wenn ich am Client den vdr händisch beende (siehe oben). Der Rechner fährt also zu schnell runter so dass der vdr die Verbindung nicht mehr sauber trennen kann.
    Mal schauen ob ich da was unter yaVDR finde, um nach dem Beenden des vdr noch ein paar Sekündchen zu warten ehe alles runtergefahren wird...


    --- Markus ---

    Streamingclient 1:
    [-] RaspiVDR MLD 5.x an Panasonic TV mit CEC :D


    Streamingclient 2:
    [-] RaspiVDR MLD 5.x - Samsung TV mit CEC


    Streamingserver:
    [---] Proxmox Server PVE7
    [- ] MLD 5.x Server - OctopusNet 4 Tuner

  • Also, bei mir gehts jetzt. Ich hab in der /etc/init.d/networking im Abschnitt wo das Netzwerk gestoppt wird einfach ein "sleep 10" eingebaut. Das reicht aus um die Verbindung sauber zu trennen.
    Ist zwar keine schöne Lösung, aber ich hab jetzt nicht wirklich den Durchblick was wann bei yaVDR beim Runterfahren aufgerufen wird. Vielleicht weiss ja ein der Profis ne schönere Lösung.


    --- Markus ---

    Streamingclient 1:
    [-] RaspiVDR MLD 5.x an Panasonic TV mit CEC :D


    Streamingclient 2:
    [-] RaspiVDR MLD 5.x - Samsung TV mit CEC


    Streamingserver:
    [---] Proxmox Server PVE7
    [- ] MLD 5.x Server - OctopusNet 4 Tuner

  • Zitat

    1.) unter bestimmten Umständen muss es eine Art Race Condition im Client geben, die die Socket-Verbindung kappt, bevor der Befehl "Quit" gesendet wird


    Dazu passt aber die Fehlermeldung nicht. Wäre das Socket schon geschlossen, käme "Invalid Filedescriptor" und kein "Connection timed out".


    Zitat

    2.) Der Server kümmert sich nicht um hängende Streams: er startet einen Thread je stream, wenn der Thread leise stirbt, räumt niemand die Verbindung weg. Dieser ist m.e. der gravierendere Bug. Leider ist die Sache nicht mit ein oder zwei Zeilen zu fixen,


    Auch da muss ich Dir widersprechen. Wenn der Client die Video-Daten nicht mehr annimmt (Schreib-Puffer des Sockets ist also voll und der Empfang der per TCP übertragenen Video-Daten wird vom Client nicht mehr bestätigt), greift ein Timeout von 15 Sekunden bis der Stream und damit die zugehörige TCP-Verbindung beendet wird.


    Was offen bleibt ist die Kontrollverbindung zu Port 2004 auf dem Server. Über diese Verbindung werden ausschließlich Befehle abgesetzt (für die Streams gibt es eigene Verbindungen). Die Kontrollverbindung bleibt auch offen, wenn z.B. der Client eine Aufnahme ansieht und streamdev folglich nichts zu tun hat. Da könnte man einen Keepalive-Mechanismus nachrüsten. Derzeit greift hier nur der TCP-Keepalive, der standardmäßig im Linux auf 2 Stunden eingestellt ist. Dein Workaround, diesen auf 30 Sekunden zu reduzieren, setzt genau an der richtigen Stelle an. Seltsam finde ich allerdings, dass der Fehler bei Markus wie erwartet ein frühzeitiger Netzwerk-Stop ist, bei Dir mit identischer Symptomatik jedoch nicht.

  • Hallo schmirl,


    Zitat

    Originally posted by schmirl


    Dazu passt aber die Fehlermeldung nicht. Wäre das Socket schon geschlossen, käme "Invalid Filedescriptor" und kein "Connection timed out".


    Müsste es bei einem Timeout-Fehler nicht erst mal eine zeit des "Hängens" geben? In den Logs ist davon aber nix zu sehen.



    Zitat

    2.) Der Server kümmert sich nicht um hängende Streams: er startet einen Thread je stream, wenn der Thread leise stirbt, räumt niemand die Verbindung weg. Dieser ist m.e. der gravierendere Bug. Leider ist die Sache nicht mit ein oder zwei Zeilen zu fixen,


    Auch da muss ich Dir widersprechen. Wenn der Client die Video-Daten nicht mehr annimmt (Schreib-Puffer des Sockets ist also voll und der Empfang der per TCP übertragenen Video-Daten wird vom Client nicht mehr bestätigt), greift ein Timeout von 15 Sekunden bis der Stream und damit die zugehörige TCP-Verbindung beendet wird.
    Was offen bleibt ist die Kontrollverbindung zu Port 2004 auf dem Server. Über diese Verbindung werden ausschließlich Befehle abgesetzt (für die Streams gibt es eigene Verbindungen). Die Kontrollverbindung bleibt auch offen, wenn z.B. der Client eine Aufnahme ansieht und streamdev folglich nichts zu tun hat. Da könnte man einen Keepalive-Mechanismus nachrüsten. Derzeit greift hier nur der TCP-Keepalive, der standardmäßig im Linux auf 2 Stunden eingestellt ist. Dein Workaround, diesen auf 30 Sekunden zu reduzieren, setzt genau an der richtigen Stelle an. Seltsam finde ich allerdings, dass der Fehler bei Markus wie erwartet ein frühzeitiger Netzwerk-Stop ist, bei Dir mit identischer Symptomatik jedoch nicht.[/quote]
    Leider passt das nicht zu meinen Symptomen. Bei mir hängen meistens drei offene Verbindungen pro Client, teilweise mit signifikanten Datenmengen in der Queue. Ohne die modifizierten Timeouts hält der Zustand ziemlich genau 2h an.


    Grüße,
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

  • Zitat

    Müsste es bei einem Timeout-Fehler nicht erst mal eine zeit des "Hängens" geben? In den Logs ist davon aber nix zu sehen.


    Der Timeout auf der Client-Seite (Fehlermeldung "Lost connection to x.x.x.x:2004: Connection timed out") liegt bei nur 1,5 Sekunden. Diese Zeitspanne ist auch in den geposteten Client-Logs zu erkennen.


    Zitat

    Bei mir hängen meistens drei offene Verbindungen pro Client, teilweise mit signifikanten Datenmengen in der Queue. Ohne die modifizierten Timeouts hält der Zustand ziemlich genau 2h an.


    Ist in Deinem Server-Log von oben tatsächlich so zu erkennen. Filterstreaming- und Writer-Thread werden erst nach 2 Stunden zusammen mit der Kontrollverbindung beendet. Anhand der Thread-ID ist aber zu erkennen, dass beide schon recht alte Threads sind (tid=1397/1398 ). Zu Beginn des Log-Auszugs habe sich die Threads mit tid=1517/1519 beendet.


    Auffällig ist, dass es zu den alten Threads offenbar keinen Receiver mehr gibt (keine Meldung "receiver on device x thread ended") . Ist das in dieser Form reproduzierbar? Kannst Du im Log prüfen, ob es beim Start der alten Threads einen Receiver gab und wann dieser beendet wurde?

  • Hallo schmirl,


    leider kann ich in meinem Log den Start der entsprechenden Threads überhaupt finden - irgendwas stimmt wohl mit dem Logs nicht oder es fehlt ein Ausschnitt. Deswegen habe ich nochmal einen neuen Anlauf gestartet, um konsistente und vollständige Logs zu erhalten.


    Folgende Rechner sind am Szenario beteiligt
    1. vdrsrv: der Server (mit den oben beschriebenen sysctl-Einstellungen zur Timeout-Verkürzung)
    2. vdratom1: ein Client mit der IP 192.168.2.41, Atom 330 mit HDD
    3. vdrclient2: ein anderer Client mit der IP 192.168.2.32, AMD Athlon DC 2900 MHz, CF als Root-Medium


    Alle Rechner laufen unter yavdr 0.3 mit dem streamdev-Plugin in Version 0.5.0+cvs20100915-1yavdr1. Auf dem Server habe ich das Streamdev-Plugin mit gesetztem DEBUG-Makro selbst durchkompiliert.


    Die Uhren sind NTP-synchronisiert.


    Der Server läuft im Rahmen der folgenden Auszüge durch, die TIDs
    sollten also eindeutig sein. Die beiden Clients werden gestartet und per Power-Taste heruntergefahren. Ein Restart des VDRs hat übrigens gerade eben scheinbar doch nicht gereicht, um einen Fehler auszulösen (entgegen meinem obigen Post).


    Der Log des Servers:


    Der Log des 1. Clients


    Der Log des 2. Clients


    Grüße,
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

Jetzt mitmachen!

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