streamdev: Verbindung stirbt, wenn anderer Client zappt

Ich habe das Problem auch schon gesehen (5 DVB-Karten im Server, 3x S2, 2 mal S). Bislang war mein Verdacht, dass es aufgrund von "hängenden" Verbindungen zu einer Tuner-Knappheit im VDR kommt. Leider (oder zum Glück) tritt es bei mir sehr selten auf und ich habe noch keinen Weg gefunden, es zu reproduzieren.

SIehe auch http://vdr-portal.de/board/thread.php?threadid=100837&hilightuser=6337

Grüße,
Holger

Hatte gerade das selbe Problem.
Bei mir war die Ursache das ich mich mit meinem Browser vorher ein paar mal zum streamdev server verbunden haben.

Dabei wird
/var/lib/vdr/plugins/streamdev-server/externremux.sh
wohl nicht richtig beendet und blockt irgend was.
Bei mir war es auf jeden Fall min 10 mal gestartet obwohl ich schon ein paar Stunden nicht mehr mit dem Browser verbunden war.

Habe nun alle externremux Processe gekilled und vdr neu gestartet.
Nun läuft es.

Ich habe das Problem hier seit langem nicht mehr gesehen - ziemlich genau seit dem ich den TCP Connection timeout reduziert habe. Das ist zwar kein Beweis für einen Zusammenhang, aber doch ein recht deutlicher Hinweis darauf...

Grüße,
Holger

Das will ich erst mal nicht machen, da auf dem Server noch diverse andere Sachen laufen. Habe keine Lust mir da andere Probleme mit ein zu handeln.

Bei mir ist das Problem kurz nach dem letzten Post wiederauferstanden, als ich bei mir einige Experimente mit einem Netceiver als DVB-Device gestartet habe. Und zwar dieses mal wunderschön reproduzierbar beim Umschalten auf VOX und auf RTL2 (beide haben bei mir ein sehr schwaches Signal).

Daher bin ich gestern abend der Sache mal auf den Grund gegangen und habe auch die Ursache gefunden: Diese beiden Sender brauchen bei mir sehr lange zum Tunen. Der Client wartet aber mit einem TImeout von 1500 ms auf eine Antwort auf sein "PROV xxx" Kommando. Bekommt er in der Zeit keine, macht er seine lokale Verbindung dicht und versucht einen neuen Connect. Das geht wiederum schief, jetzt hängt der umschaltende Client mit einem schwarzen Bild und gibt auf.

Aus bislang ungeklärten Gründen führt aber der unsaubere Disconnect des einen Clients auch zum totalen Reset des Streamdev-Servers, sodass auch auf allen anderen verbunden Clients der Stream zusammenbricht. Hier bleibt dann das Bild einfach stehen.

Quickfix: in client/socket.h in den Methoden Command und Expect den Timeout-Default von 1500 auf 15000 erhöhen. Danach dauert das Schalten auf die kritischen Sender zwar drei, vier Sekunden, aber es knallt zumindest nicht mehr.

Die wahre Ursache für den Verbindungszusammenbruch auf den unbeteiligten Clients wird heute abend näher untersucht...

schmirl: gibt es im Moment eine aktuellere Version als die cvs20100915? Wenn ja, wo kann man die bekommen?

Grüße,
Holger

Nach dem Verlust des CVS auf vdr-developer.org ist streamdev nun ins git auf http://projects.vdr-developer.…ojects/show/plg-streamdev umgezogen. Wenn die Timeout-Geschichten gelöst sind, werde ich das zusammen mit einer neuen Version offiziell machen.

Bin wegen eines anderen Problems am Wochenende auf den selben problematischen Timeout gestoßen. Betrifft im aktuellsten streamdev nur noch das TUNE-Kommando, weshalb dort folgender Patch ausreichend sein sollte (in Deiner Version sind TUNE und PROV betroffen):

--- a/client/socket.c
+++ b/client/socket.c
@@ -249,7 +249,7 @@ bool cClientSocket::SetChannelDevice(const cChannel *Channel) {
 
        std::string command = (std::string)"TUNE " 
                                + (const char*)Channel->GetChannelID().ToString();
-       if (!Command(command, 220)) {
+       if (!Command(command, 220, 10000)) {
                if (errno == 0)
                        esyslog("ERROR: Streamdev: Couldn't tune %s:%d to channel %s",
                                RemoteIp().c_str(), RemotePort(), Channel->Name());

Brechen die Verbindungen zu den anderen Clients auch mit dem höheren Timeout noch ab? Falls ja: passiert das auch, wenn der auf dem "unbeteiligten" Clients das Filter-Streaming deaktiviert ist?

Mit dem höheren Timeout konnte ich keinen Verbindungsabbruch mehr provozieren (Timeout global in der Socketklasse auf 15 Sekunden erhöht). Leider habe ich immer noch ein etwas ungutes gefühl, denn der andere Timeout behebt ja nicht das ursprüngliche Problem (es werden nicht betroffene Verbindungen "abgeräumt").

Filter Streaming hat noch meinen Erfahrungen weder positive noch negative Auswirkungen auf die Abbrüche gehabt. Für meine Tests hatte ich es letztendlich zur Reduzierung von Debug-Meldungen auf beiden Clients deaktiviert.

Leider kann ich die neue Streamdev-Version erst übernächstes Wochenende testen.

Grüße,
Holger

Kannst Du zum Abräumen der anderen Verbindungen mal das Log posten?

Leider nicht so ohne weiteres. Habe ich nicht aufgehoben und ich komme so schnell leider nicht in die Nähe meines VDRs. Allerdings kannst du das Verhalten sehr einfach reproduzieren, wenn Du den Timeout in den Bereich von 900-1000 ms verkürzt - dann ist zumindest auf meinem System jedes zweite Umschalten fehlgeschlagen. Anschließend war auch der Stream des zweiten Clients tot.

Grüße,
Holger

Ich habe nochmal versucht das Problem nachzustellen, indem ich einen Client per iptables abwürge. Das Server-Log sieht exakt so aus, wie Du es in Deinem zweiten Beitrag oben gepostet hast. Den anderen Client hat's nicht interessiert. Konnte weiterschauen und auch zappen.

Hat die neue streamdev-client Version etwas am Log des "unbeteiligten" Clients geändert?

Und welchen von den beiden muss man lahm legen, damit beim Anderen das Problem auftritt? Welchen Streamtyp nutzt HTTP (TS, EXT, ...)?

Durch bloßes zappen schon Störungen??? Da läuft dann aber irgendetwas anderes tierisch daneben!

Laut erstem Posting hast Du mit 4 DVB-S-Karten ja ausreichend Resourcen. Ein verschieben der Streams zwischen den Karten sollte daher nicht auftreten. Kannst Du trotzdem mal die "frontend x/y provides ..." Meldungen beim Start des Server posten sowie das Server-Log beim Zappen wenn VDR mit -l 3 (volles Logging) gestartet wird?

Hallo schmirl,

ich kann das Problem von owagner nur bestätigen (siehe auch streamdev server/client verbindung times out)
Für mich sieht es so aus, daß es dann Probleme gibt, wenn filterstreaming mit involviert ist.
Ich würde ggf weitere Traces erstellen.

vG
WoZ

... wobei Du im anderen Thread geschrieben hast, dass es seit dem Update des Server läuft. Dem ist also offenbar nicht so? Deine Vermutung war, dass das Problem auftritt, wenn alle Karten belegt sind und Live-TV umgeschaltet werden muss. Für diesen Fall lohnt sich evtl. ein Update des Servers auf den aktuellen git-Stand. Da gab es einen Bugfix.

Dass owagner ein Problem mit dem Umschalten von Live-TV hat, bezweifle ich aber, da er ja 4 DVB-Karten nutzt. Aber evtl. sind die 4 Karten doch nicht gleichwertig und VDR verschiebt Live-TV. Das werden die "frontend ... provides ..."-Meldungen zeigen.