streamdev mit 99% automatisch killen [help wanted]

Das Problem geistert so nebulös schon seit längerem durch die streamdev-Gemeinde. Bei mir ist es bislang nicht aufgetreten. Vorausgesetzt, das tritt auch bei der aktuellen streamdev Version aus dem CVS auf und ich kann es bei mir reproduzieren, würde ich versuchen das Problem aus der Welt zu schaffen. Dazu wäre es schön, wenn mir möglichst viele Betroffene folgende Informationen posten könnten:

• VDR Version
• Version des Plugins (laut Einstellungen -> Plugins)
• Herkunft des Plugins (Bei CVS: ungefähres Datum, bei Distri: Welche Distri, welche Version)
• Problem bei HTTP oder VDR-zu-VDR Streaming?
• Bei HTTP: Welcher Client in welcher Version
• Wie reproduzierbar (und mit welcher Erfolgsquote)

Habe dazu auch einen Eintrag im Bugtracking aufgemacht.

Hallo schmirl,

Ich denke, dass ich es relativ gut reproduzieren kann.
Ich brauch dann nur auf meinem Plattenlosen Client die Resettaste zu drücken. In der Regel ist dann sofort das Problem auf dem Server da.
Muss allerding gestehen, dass ich das Problem längere Zeit auch nicht gehabt habe. Werde heute Abend gleich mal testen und mich dann wieder melden.

Peter

Zitat

Schwester schaut fern, sobald sie sich aufregt das nix mehr geht und rumschreit hat der VDR 99% *g*

Oben schreibst Du

Zitat

das der VDR beim unsachgemäßen trennen vom Stream den Rechner auf 99% CPU last hochtreibt.

Was verstehst Du unter "unsachgemäß"? Bist Du Dir sicher, dass Deine Schwester nicht deshalb schreit, weil Sie gerade über das Netzwerkkabel gestolpert ist? Oder vielleicht versehentlich den Tassenhalter ihres Computers einfährt obwohl darauf noch eine volle Kaffeetasse steht und sich deren Inhalt gerade zischend in das Innere des Rechners ergießt :mua?

Im Ernst: Passiert das einfach so im laufenden Betrieb? Oder nur beim Zappen?

Ähnliche Phänome hab ich auch. Z.b. in Verbindung mit externremux, wenn das Script unter /root liegt und die Berechtigung nicht entsprechend gesetzt ist, geht die CPU Last auch auf 99% hoch.
Andere Probleme habe ich auch mit bestimmten Transpondern. Bei den "normalen" deutschen Programmen funktioniert das Streamen zuverlässig. Nehme übrigens VLC als Client. Schaltet man aber auf bestimmt Kanäle schmiert schonmal der ganze VDR ab oder das normale Programm wird umgeschaltet. Außerdem kommt es auch mal zu kurzen hängern in der normalen Wiedergabe wenn per VLC ein Kanal gewechselt wird. Nicht so tragisch, aber wenns während ner Aufnahme passiert nicht so toll. Da ich streamdev nur selten benötige um über Internet auf den VDR zuzugreifen habe ich mich dann auch nicht mehr um die anderen Probleme gekümmert. Aber du bist nicht alleine

Greetz

Zitat

Ähnliche Phänome hab ich auch. Z.b. in Verbindung mit externremux, wenn das Script unter /root liegt und die Berechtigung nicht entsprechend gesetzt ist, geht die CPU Last auch auf 99% hoch.

Danke für den Tipp. Das kann ich auf meinem Entwicklungs-Rechner reproduzieren ohne den Produktiv-Server vergewaltigen zu müssen. Hoffen wir, dass die Ursache die selbe ist wie bei den anderen Leidensgenossen.

... drei Jahre später...

Nachdem ich mich nun gestern endlich mal für ein paar ruhige Minuten mit dem Problem beschäftigen konnte, habe ich die Lösung für das von kayser beschriebene Problem gefunden. Patch ist im Bugtracking. Wäre prima wenn jemand der externremux nutzt den mal kurz antesten könnte.

Nun gehe ich mal davon aus, dass alle anderen externremux nicht verwenden. Damit stehen wir nun leider wieder nahe am Anfang. Werde nochmal versuchen, das ganze zu reproduzieren, ist mir aber leider bislang nicht gelungen. Interessant wäre, bei welchem Stream das Problem aktuell auftritt (VTP, HTTP/TS, HTTP/PS, HTTP/PES, HTTP/Extern mit Patch aus Bugtracking)?

Wenn es jemand relativ einfach reproduzieren kann, hilft vielleicht strace um das Problem ausfindig zu machen:

VDR von Hand starten mit

strace -o /tmp/strace -f -ff vdr VDR_OPTIONEN

Im /tmp/-Verzeichnis sollte nun je Thread eine strace-Datei erscheinen. Sobald sich der Client verbindet, kommen 2-3 Dateien dazu. "Übliche" Wachstumsrate dieser Dateien beobachten. Dann den Fehler provozieren. Jetzt sollte eine der Dateien überproportional zu wachsen anfangen. Folgende Infos wären für mich interessant (VDR muss dazu noch laufen):

Der Name des Logs enthält ja die Prozess-ID. Was zeigt

ls -l /proc/PROZESS_ID/fd/

Was sagt

netstat -ntx

Und das wichtigste: welche Zeilen wiederholen sich in dem betroffenen Log?

Hi,

tut sich ja was Zum test mit externremux komme ich die Woche bestimmt mal. Den Rest aber erst wenn ich am Wochenende daheim bin.

Greetz

Die Wurzel des Übels ist schon mal gefunden (siehe Attachment im Bugtracking). Aber nicht zu früh freuen - damit ist es wahrscheinlich noch nicht getan.

An dieser Stelle vielen Dank an pixelpeter für das anfertigen der strace-Logs :]. Brauche für den Moment erstmal keine weiteren Logs.

Kurzer Nachtrag: Der Patch hat scheinbar beträchtliche Nebenwirkungen, braucht also noch niemand auszuprobieren. Hoffe ich hab am Wochenende genug Zeit um dem Problem auf den Grund zu gehen...

Hi schmirl,

sorry für den thread-highjack bzw. die Zwischenfrage.

Kannst Du dem streamdev-plugin WMM (wireless multimedia) "beibringen". Die Fritz!Box unterstützt das und soweit ich das verstanden habe muß "nur" das QoS Bit im Netzwerkpacket gesetzt sein?!?

Gruß, ollo

Zitat

Kannst Du dem streamdev-plugin WMM (wireless multimedia) "beibringen". Die Fritz!Box unterstützt das und soweit ich das verstanden habe muß "nur" das QoS Bit im Netzwerkpacket gesetzt sein?!?

... und QoS im AccessPoint aktiviert sein. Sehe ich auch so. Habe ich mal kurz zusammengestrickt, ist aber noch völlig ungetestet: http://www.vdr-developer.org/mantisbt/view.php?id=237

Hi schmirl,

danke, das ging ja flott!

Ich habe den patch mal eingespielt und stelle bisher keine "Nebenwirkungen" fest. Ob's allerdings nun besser ist als vorher ist schwer zu sagen Jedenfalls streamt mein VDR über die Fritz!Box 7170 auch 2 Sender parallel (PES bei perfekten 11g WLAN Empfangsbedingungen) über mehrere Minuten hinweg stabil und ohne buffer overflows.

Gruß, ollo

Hi schmirl,

zurück zum Thema; bei mir treibts den VDR auf 99,9% wenn während des Streamens z.B. die Netzwerkverbindung des WLAN clients an der Fritz!Box abbricht. Dann bekommt der streamdev server wohl den disconnect nicht mit?!? Der VDR hängt dabei per Ethernetkabel an der Fritz!Box.

Gruß, ollo

Hi,

ähnliches wie Ollo vermute ich auch. Benutze den EOF Patch und habe mal einen Absturz produziert. Da ich nur einen PIII 933MHz habe ist das nicht allzu schwer, der läuft beim kodieren absolut an der Grenze. Ein Aufruf vom VDRAdmin z.B. reicht dann bei mir schon aus, damit das Streaming abricht. Und so sieht dann mein Log aus:

Feb 12 19:35:14 D0000029 vdr: [4535] streamdev-server: EOF reading from externremux
Feb 12 19:35:25 D0000029 vdr: [3640] ERROR: 1 ring buffer overflow (165 bytes dropped)
Feb 12 19:35:31 D0000029 vdr: [3640] ERROR: 10635 ring buffer overflows (1999380 bytes dropped)
Feb 12 19:35:37 D0000029 vdr: [3640] ERROR: 12129 ring buffer overflows (2280252 bytes dropped)

die Meldungen kommen dann immer wieder. Heißt dass, das der VDR weiter in diesen Buffer schreibt, und da nichts mehr abgeholt wird kommt es dann zum overflow ?
Nach ca. 5 min. scheint der VDR dann die Verbindung zu beenden:

Feb 12 19:40:19 D0000029 vdr: [2999] streamdev: closing streamdev connection to 192.109.50.10:3970
Feb 12 19:40:22 D0000029 vdr: [2999] ERROR: streamdev-livestreaming thread 4537 won't end (waited 3 seconds) - canceling it...

Ein mencoder Prozess bleibt allerdings über.

[root@D0000029 bin]# ps -aef|grep vdr|grep mencoder
vdr       4542     1  0 18:36 ?        00:00:22 /usr/bin/mencoder -cache 8192 -ovc lavc -oac mp3lame -lameopts cbr:br=64 -of mpeg -vf scale=320:240 -lavcopts vcodec=mpeg2video:vbitrate=500:keyint=25 -o /tmp/out.avi -- -

Den Stream erneut aufzurufen geht zwar, aber er bricht nach ein paar Sekunden dann wieder zusammen. Lösung VDR durchstarten.

Greetz

ollo, kayser: Richtig vermutet. Der streamdev-Server bekommt nicht mit, wenn der Client sich weghängt.

@all: Im Bugtracking liegt nun ein Patch der das Problem behebt. Wenn streamdev 15 Sekunden lang nix mehr zum Client schicken kann, wird die Verbindung abgebaut. Wer mit externremux arbeitet, sollte noch den EOF-Patch dazunehmen.

Pixelpeter hat den Patch getestet (an dieser Stelle nochmal Danke!) und er tut was er soll. Allerdings hat bei ihm nach ca. 3 Stunden streamdev die Arbeit eingestellt und ein Neustart des Servers war fällig. Könnte Zufall gewesen sein aber natürlich auch der Patch. Mutige Tester vor! Wenn was schief geht bitte die Ausgabe von netstat -nta auf Client und Server sichern. Dann Client neu starten und nochmal netstat -nta sichern. Dann das Log von Server und Client ab dem Zeitpunkt zu dem das Problem auftrat zusammen mit den netstat Ausgaben posten. Sollte jemand in der Lage sein das Problem schnell (innerhalb weniger Minuten) zu reproduzieren wäre das strace super (Anleitung siehe weiter oben in diesem Thread).

Sind in der CVS Version die Patches schon integrier t?