streamdev mit 99% automatisch killen [help wanted]

Habe eben ein selbes Problem...

1.Grundlage: (FUNKTIONIERT NICHT)
Windows XP (Netzwerk über WLAN) mit VLC zu VDR

Sobald ich versuche mittels WINDOWS XP VLC zu starten
mit http://ipvdr:3000/PES/5
dann fangt es mal an mir das Bild zu zeigen.
Nach ca. 10 Sekunden geht bei top die VDR Last auf 97% ungefähr.
Und somit fängt es an zu hängen das ganze.

logread sagt

Sumsi:~# logread -f
Mar  2 20:20:19 Sumsi user.debug vdr: [4835] buffer usage: 70% (tid=4837)
Mar  2 20:20:19 Sumsi user.debug vdr: [4835] buffer usage: 60% (tid=4837)
Mar  2 20:20:19 Sumsi user.debug vdr: [4835] buffer usage: 70% (tid=4837)
Mar  2 20:20:19 Sumsi user.debug vdr: [4835] buffer usage: 60% (tid=4837)
Mar  2 20:20:19 Sumsi user.debug vdr: [4835] buffer usage: 70% (tid=4837)
Mar  2 20:20:19 Sumsi user.debug vdr: [4835] buffer usage: 60% (tid=4837)
Mar  2 20:20:19 Sumsi user.debug vdr: [4835] buffer usage: 70% (tid=4837)
Mar  2 20:20:19 Sumsi user.debug vdr: [4835] buffer usage: 60% (tid=4837)
Mar  2 20:20:19 Sumsi user.debug vdr: [4835] buffer usage: 70% (tid=4837)
Mar  2 20:20:19 Sumsi user.debug vdr: [4835] buffer usage: 60% (tid=4837)
Mar  2 20:20:19 Sumsi user.debug vdr: [4835] buffer usage: 70% (tid=4837)
Mar  2 20:20:19 Sumsi user.debug vdr: [4835] buffer usage: 60% (tid=4837)

2.Grundlage: (FUNKTIONIERT)
Windows XP (Netzwerk über Netzwerkkabel) mit VLC zu VDR

Hier klappt alles, auslastung ist auch vorhanden, aber es geht ohne Fehler. Selbe Grundlage wie die 1. jedoch mit Netzwerkkabel.

3.Grundlage: (FUNKTIONIERT)
Windows XP (Netzwerk über WLAN) mit VLC zu VDR

Diesmal die gleiche Grundlage wie die 1.
nur diesmal im VLC mit extern gearbeitet.
http://ipvdr:3000/EXTERN/5

Hierbei ist auch kein Fehler zu erkennen und es funktioniert auch alles.

Warum ist bei WLAN eine Auslastung von 97% vorhanden ??

Zitat

Warum ist bei WLAN eine Auslastung von 97% vorhanden ??

also bei mir ist das "nur" ab und zu.
leider auch völlig ohne System

Michi

Hi JDMario,

zu 1. - wahrscheinlich ist Deine WLAN Verbindung zu lahm und damit kommt es halt zu den buffer overruns

zu 2. - alles i.O.

zu 3. - nun wird in realtime trancodiert, das frißt natürlich CPU

Alles klar?

Gruß, ollo

Naja ..habe eigentlich ne gute Verbindung...
Mit 54 MBit WLAN

Zitat

Original von JDMario
Naja ..habe eigentlich ne gute Verbindung...
Mit 54 MBit WLAN

me2

54MBit WLAN heisst noch garnix. Habt ihr mal den Durchsatz gemessen - z.B. per ftp oder scp? Wenn's am WLAN Durchsatz liegt, dann müßten bei 1. einige Sender besser streamen als andere, je nachdem mit welcher Datenrate der Sender ankommt. ARD/ZDF senden mit bis zu 8MBit, andere (z.B. RTL oder einige der "Standbildsender") mit deutlich weniger -die müßten dann ohne buffer overruns laufen.

Gruß, ollo

Hallo Frank,

Dein Patch läuft jetzt seit einigen Wochen auf meinem Server.
Das Problem, welches ich damals beim ersten Test hatte icht nicht mehr aufgetreten. Das Problem mit den 100% CPU Last ist auch nicht mehr vorhanden.
Sehr selten passiert aber beim umschalten, dass nichts angezeigt wird. Ein erneutes Umschalten geht jedoch dann wieder problemlos. Tritt selten, aber regelmäßig auf. In den ca. drei Wochen vielleicht 5-6 Mal.
Logfiles zu dem Vorfall habe ich da. Ist aber nichts zu erkennen. Sieht so aus, als würde der Serverprozess des alten Kanäl sauber beendet und kein neuer gestartet werden.

Gibt es hier jemand im Board, welcher VTP produktiv einsetzt?

Peter

Zitat

Das Problem, welches ich damals beim ersten Test hatte icht nicht mehr aufgetreten.

Prima. Meine erste Vermutung, dass bei Dir das selbe wie bei kayser passiert ist, hat sich nicht bestätigt. Kaysers Problem kann nur bei HTTP-Streaming auftreten. Schreibe die Server-Schleife gerade um, komme aber gerade nicht viel dazu (Mittagspausen fallen der nahenden Cebit zum Opfer ;)).

Zitat

Sehr selten passiert aber beim umschalten, dass nichts angezeigt wird. Ein erneutes Umschalten geht jedoch dann wieder problemlos. Tritt selten, aber regelmäßig auf. In den ca. drei Wochen vielleicht 5-6 Mal.
Logfiles zu dem Vorfall habe ich da. Ist aber nichts zu erkennen. Sieht so aus, als würde der Serverprozess des alten Kanäl sauber beendet und kein neuer gestartet werden.

Das ist weniger prima. Ich nehme mal an, Du hast nur die "normalen" Logs, kein Log von streamdev-server oder -client mit DEBUG-Option? Naja - vielleicht hat es sich ja dann mit der überarbeiteten Version erledigt.

Hi schmirl,

ich bekomme jetzt häufiger folgende Fehler beim Beenden von Streams auf der Client Seite:

Mar 13 19:03:07 localhost vdr: [5246] ERROR: streamdev-server: couldn't send data: Die Verbindung wurde vom Kommunikationspartner zurýckgesetzt
Mar 13 19:03:07 localhost vdr: [5246] streamdev-writer thread ended (pid=5155, tid=5246)
Mar 13 19:03:07 localhost vdr: [5166] fatal error, server exiting: Ungýltiger Dateideskriptor
Mar 13 19:03:07 localhost vdr: [5166] cTS2PES got 0 TS errors, 1 TS continuity errors
Mar 13 19:03:07 localhost vdr: [5166] cTS2PES got 0 TS errors, 1 TS continuity errors
Mar 13 19:03:07 localhost vdr: [5166] buffer stats: 1569800 (37%) used
Mar 13 19:03:07 localhost vdr: [5166] streamdev server thread ended (pid=5155, tid=5166)
Mar 13 19:03:07 localhost vdr: [5248] receiver on device 1 thread ended (pid=5155, tid=5248)

mit dem Ergebnis, daß man den Streamingserver nicht mehr connecten kann bis der VDR restartet wird. Ich streame den PES per HTTP über Ethernet.

Irgend eine Idee?

Gruß, ollo

Zitat

mit dem Ergebnis, daß man den Streamingserver nicht mehr connecten kann bis der VDR restartet wird. Ich streame den PES per HTTP über Ethernet

Gleiches Problem wie bei kayser. Tritt nur mit HTTP-Streaming auf. Ursache ist schon gefunden, bin aber noch nicht dazu gekommen den Patch zu überarbeiten. Mach mich die nächsten Tage dran. Aber danke für's feedback!

@all: Auf zur nächsten Runde. Hier ist der überarbeitete Patch. Getestet nur mit HTTP, sehe aber keinen Grund warum es mit VTP nicht funktionieren sollte.

Ah, pünktlich zum Wochenende. Dann werden wir das mal ausprobieren

Greetz

So, mal ein kurzer Zwischenbericht. Wenn ich den Patch anwende findet er irgendwie die Files nicht. Manuell angeben geht allerdings. Einmal ist bei mir eben folgendes aufgetreten:

Mar 18 15:12:38 D0000029 vdr: [4091] Streamdev: Accepted new client (HTTP) 192.168.0.161:4428
Mar 18 15:12:46 D0000029 vdr: [4091] ERROR: read from client (HTTP) 192.168.0.161:4428 failed: Connection reset by peer
Mar 18 15:12:46 D0000029 vdr: [4091] streamdev: closing streamdev connection to 192.168.0.161:4428
Mar 18 15:12:46 D0000029 vdr: [4091] Streamdev: Accepted new client (HTTP) 192.168.0.161:4429
Mar 18 15:12:49 D0000029 vdr: [4091] ERROR: read from client (HTTP) 192.168.0.161:4429 failed: Connection reset by peer
Mar 18 15:12:49 D0000029 vdr: [4091] streamdev: closing streamdev connection to 192.168.0.161:4429
Mar 18 15:12:49 D0000029 vdr: [4091] Streamdev: Accepted new client (HTTP) 192.168.0.161:4430
Mar 18 15:13:44 D0000029 vdr: [4091] ERROR: read from client (HTTP) 192.168.0.161:4430 failed: Connection reset by peer
Mar 18 15:13:44 D0000029 vdr: [4091] streamdev: closing streamdev connection to 192.168.0.161:4430
Mar 18 15:13:44 D0000029 vdr: [4091] Streamdev: Accepted new client (HTTP) 192.168.0.161:4436
Mar 18 15:14:00 D0000029 vdr: [4091] ERROR: read from client (HTTP) 192.168.0.161:4436 failed: Connection reset by peer
Mar 18 15:14:00 D0000029 vdr: [4091] streamdev: closing streamdev connection to 192.168.0.161:4436
Mar 18 15:14:01 D0000029 vdr: [4091] Streamdev: Accepted new client (HTTP) 192.168.0.161:4437
Mar 18 15:14:11 D0000029 vdr: [4091] client (HTTP) 192.168.0.161:4437 has closed connection
Mar 18 15:14:11 D0000029 vdr: [4091] streamdev: closing streamdev connection to 192.168.0.161:4437
Mar 18 15:14:11 D0000029 vdr: [4091] Streamdev: Accepted new client (HTTP) 192.168.0.161:4438
Mar 18 15:14:18 D0000029 vdr: [4091] client (HTTP) 192.168.0.161:4438 has closed connection
Mar 18 15:14:18 D0000029 vdr: [4091] streamdev: closing streamdev connection to 192.168.0.161:4438
Mar 18 15:14:18 D0000029 vdr: [4091] Streamdev: Accepted new client (HTTP) 192.168.0.161:4439
Mar 18 15:14:23 D0000029 vdr: [4091] client (HTTP) 192.168.0.161:4439 has closed connection

Da habe ich auf einen Premiere Feed geschaltet, danach ging dann das streamen nicht mehr (ab da wo die "Connection reset by peer" im Log fehlen). Allerdings konnte ich den Fehler bis jetzt nicht reproduzieren. Wäre also vielleicht auch ohne Patch passiert. Jedenfalls musste ich den VDR restarten.

Greetz

Zitat

Wenn ich den Patch anwende findet er irgendwie die Files nicht. Manuell angeben geht allerdings

Wie meinst Du das ?(?

Zitat

Da habe ich auf einen Premiere Feed geschaltet, danach ging dann das streamen nicht mehr (ab da wo die "Connection reset by peer" im Log fehlen).

Dem entnehme ich, dass die "Connection reset by peer" noch normal sind, oder (sprich: kommen beim Umschalten)? Könnte evtl. der selbe Effekt sein, den Elchi beobachtet hat (Elchis Posting). Von Elchi gibt es aber nur de Debug-Ausgabe von streamdev, nicht das zugehörige Log. Hast Du ein CAM für Premiere? Hast Du danach - wie Elchi - auch hohe Load am Server bekommen?

Solltest Du das ganze nochmal reproduzieren können, dann vielleicht mal mit einem Sniffer prüfen was streamdev schickt (oder Streamdev mit Debug-Option laufen lassen). Laut Log macht Dein Client einfach die Verbindung wieder zu. Vielleicht bekommt er wie bei Elchi auch ein "Channel not available".

Hi,

hab mir die Sourcen frisch aus dem CVS gezapft, und dann:

[vdr@D0000029 src]$ cd streamdev
[vdr@D0000029 streamdev]$ patch -p1 < ../streamdev-select-new.diff
can't find file to patch at input line 10
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|? .dependencies
|? server/.server.c.swp
|Index: server/connection.h
|===================================================================
|RCS file: /var/cvsroot/streamdev/server/connection.h,v
|retrieving revision 1.3
|diff -u -r1.3 connection.h
|--- server/connection.h        9 May 2005 20:22:29 -0000       1.3
|+++ server/connection.h        14 Mar 2007 12:04:20 -0000
--------------------------
File to patch:

Die CPU Last ist nach dem Problem normal geblieben. Werd mir das nochmal genauer anschauen.

Greetz

patch -p0 wäre der Preis gewesen. Die Dateinamen in diesem Patch sind relativ zum streamdev-Verzeichnis (server/connection.h). Wenn Du also mit cd in das streamdev-Verzeichnis gehst, muss von den Dateinamen im Patch kein Pfad mehr weggenommen werden (daher -p0). Ein -p1 bräuchtest Du, wenn die Pfade im Patch das streamdev-Verzeichnis beinhalten würden (also z.B. streamdev-cvs/server/connection.h)

Hi,

war ich gestern noch überglücklich mit dem Patch, gab es heute erste Probleme.
Merkwürdigerweise im Bereich FB / LIRC. Der VDR nahm (fast) keine Befehle mehr per LIRC auf. Control-Plugin ging aber. Reboot brachte auch keine Änderung. Leere Batterien waren es auch nicht.
Da im Log was von Streamserver stand (* genaue Meldung werde ich noch nachreichen - Mist oder Glück: ist noch nicht wieder aufgetreten!), habe ich das Streamserver-Plugin deaktivert, rebootet und der Spuk war erst einmal vorüber. Auch waren zwei VDR-Instanzen bei je 49%-CPU-Last am Amok laufen...

Zitat

Original von schmirl
patch -p0 wäre der Preis gewesen. Die Dateinamen in diesem Patch sind relativ zum streamdev-Verzeichnis (server/connection.h). Wenn Du also mit cd in das streamdev-Verzeichnis gehst, muss von den Dateinamen im Patch kein Pfad mehr weggenommen werden (daher -p0). Ein -p1 bräuchtest Du, wenn die Pfade im Patch das streamdev-Verzeichnis beinhalten würden (also z.B. streamdev-cvs/server/connection.h)

Hatte es auch mal ohne "-p" probiert, aber das wollte er auch nicht. Auf die Idee mit -p0 bin ich nicht gekommen

Greetz

Das Wochenende ist vorbei und kein neues Posting? Damit bleiben eigentlich nur zwei Möglichkeiten: Entweder es läuft bei allen oder streamdev-select-new.diff hat kaum mehr jemand getestet ?(.

Hi schmirl,

... getestet und für "gut" befunden. Bisher habe ich keine weiteren Probleme gehabt. Ich nutze die CVS Version + WMM patch + streamdev-select-new.diff.

Danke & Gruß, ollo

PS: keine Nachricht - gute Nachricht!