[PATCH] Mal wieder ein sectionsd-Versuch...

[PauleFoul]

@Seife

Wollte mal nachfragen ob Du mit dem Problem am EPG Filter schon weiter gekommen bist.
Ansonsten ist die aktuelle Version für mich nicht mehr einsetzbar, da mir der ARD EPG den
gesamten Speicher "zumüllt".

Oder ich müsste den Filter umschreiben...


Gruß
____Paule

[seife]

realistisch gesehen komme ich nicht vor Ende nächster Woche dazu mir das anzusehen. Wenn überhaupt so "früh"

[seife]

sectionsd-remove-eitthreads-pause-v2.diff

Nächster Versuch. Um Ganz ehrlich zu sein: das ist mehr stochern im Nebel als exakte Wissenschaft ;-)

@PauleFoul: ich kann das mit ARD und ZDF und deinem epgfilter.xml nicht reproduzieren, auf ARD und ZDF habe ich mehr als nur now&next (ASTRA 19.2E). Auf BR-Alpha, was im Filter mit drin ist, habe ich jedoch nur now&next. Insofern scheint das zu funktionieren.

[GetAway]

Bin jetzt auch etwas benebelt.
Sollen die 3 Zeilen aus dem mutex.diff mit da rein?
Oder ist es eventuell sinnvoller erstmal ohne den mutex Patch zu testen?

~Wissenschaft hin, Wissenschaft her, der User ist der beste Störungsmelder.~

[seife]

Nein, das mit dem mutex-Versuch ist wohl eher die falsche Richtung gewesen. Der schützt nur davor, wenn neutrino mehrere Anfragen gleichzeitig machen würde, was aber vermutlich eher nicht passiert. Das Problem ist, dass sectionsd tatsächlich intern deadlocked. Vermute ich mal (bei mir tritts ja nicht auf )

[rhabarber1848]

sectionsd-remove-eitthreads-pause-v2.diff

Nächster Versuch. Um Ganz ehrlich zu sein: das ist mehr stochern im Nebel als exakte Wissenschaft ;-)

Gerade eingespielt, sieht gut aus, keine Probleme, weder mit v1 noch jetzt mit v2 feststellbar.
Allerdings habe ich die Freezer noch nie beobachten können (Sagem 2x, 64MB, Kabel).

[rhabarber1848]

sectionsd-remove-eitthreads-pause-v2.diff

Ich habe meinen no_debug-Patch an den aktuellen CVS+Code + obigem Patch
angepasst und ein Binary daraus gemacht, no_debug-Patch und Binary gibt es hier:
sectionsd-remove-eitthreads-pause-v2_nodebug.tar.bz2

[GetAway]

...
Gerade eingespielt, sieht gut aus, keine Probleme, weder mit v1 noch jetzt mit v2 feststellbar.
Allerdings habe ich die Freezer noch nie beobachten können (Sagem 2x, 64MB, Kabel).

Sagem's crashen nicht. Bisher habe ich nur von Nokia's gelesen.
Deswegen kann es meiner Meinung nach kein reines sectionsd Problem sein.

[seife]

Mir geht es hier auch nicht um die Crashes/harten Hänger, die gehen mich erst mal nix an, mir geht es um die Deadlocks (Infobar hängt, aber "killall sectionsd" via telnet machts wieder ganz).

[seife]

So. Jetzt mal eine ganz andere Herangehensweise
Ich hatte schon länger vermutet, dass die {read,write}LockMessaging()-Calls das Problem waren.
Heute wollte ich mal die gefixten Error-Pfade für die ganzen Command*-Funktionen committen (das ist unabhängig vom Rest, aber schliesst aus, dass die GUI hängt, weil sie ein Kommando an den sectionsd schickt, der aber wegen eines Fehlers "vergisst" zu antworten). Als ich den Patch zum Test kompiliert hatte stolperte ich prompt wieder über diese Deadlocks.
Dabei kam raus, dass der sectionsd am messaging Lock hing. Also habe ich mal untersucht, welche davon eigentlich notwendig sind und welche nicht.

Alle diese messaging_*-Variablen, die nur innerhalb eines einzelnen Threads benutzt werden, brauchen IMHO kein Locking, also habe ich es mal auskommentiert. Patch und Binary giibt's hier:
sectionsd-fix-error-paths-and-rework-messaging-locks-v1.diff
sectionsd-fix-error-paths-and-rework-messaging-locks-v1.gz
Erfahrungsberichte, insbesondere von denen, die bisher reproduzierbar Hänger hatten, sind willkommen.
Oh - und wenn mir jemand den Fehler in meinem Gedankengang aufzeigt, ist mir das auch recht

[GetAway]

Auf zum fröhlichen testen.
Einen einfachen timeout einzubauen wäre wohl etwas zu trivial?

[seife]

Wenn du mir sagst, was ich machen soll, wenn ich den Lock nicht bekomme, dann mach ich das gerne ;-)

Achso: natürlich für jeden Fall, das sind genau:

Code: Alles auswählen

seife@stoetzler:.../daemons/sectionsd> gcc -E sectionsd.cpp 2>/dev/null|grep -v inline|egrep -i '(read|write)lockmessaging'| wc -l
49

Fälle .

Tatsächlich muss man dafür sorgen, dass der Deadlock nicht auftritt. Wenn das jetzt nichts hilft, dann muss man eben feiner locken, also nicht "lockMessaging" für alle messaging_*-Variablen, sondern tatsächlich für jede Variable einzeln. Dann wird es auch einfacher festzustellen, ob man per Timeout einfach weitermachen kann, auch wenn man den Lock nicht bekommen hat.

[mb405]

ich hab se mal loofen seit gestern abend.
auf was soll ich achten ?
epg kommt subjektiv schneller.

cache 4 tage
verwerfen nach 3 stunden
langtext 6 stunden
maxevents 6000

hdd mit swap auf sec.ide

[seife]

ich hab se mal loofen seit gestern abend.
auf was soll ich achten ?

Ob er sich auf den bekannt verdächtigen Sendern weghängt. Bei mir tritt es ja normalerweise nicht auf...
Achso, und ob alles noch so funktioniert wie vorher, evtl. habe ich ja zuviel wegoptimiert ;-)

epg kommt subjektiv schneller.

Hm, das kann schon sein, da bestimmt auch ohne Deadlocks ab und zu unnötig(?) an den Locks gewartet wurde...

[Boardgeist]

Ich hatte vor geraumer Zeit auch ständig das "weghängen" bei diversen Sendern, ist aber ohne Änderungen am sectionsd bei mir schon lange nicht mehr aufgetreten.
Ich denke da mal eher an eine Änderung bei den betroffenen Sendern.

Also versteift Euch mal nicht ganz so doll auf die Fixe (nur so ne Idee von mir)!
Wobei Fixe für diverse Probleme natürlich Klasse sind !!!!


gruß boardgeist

[Striper]

Also versteift Euch mal nicht ganz so doll auf die Fixe (nur so ne Idee von mir)!

Sehe ich überhaupt nicht so. Irgendwo ist da der Wurm drin, sonst würden sich einige Boxen bei diversen Sendern nicht weghängen. Ich finds gut das seife da Zeit investiert um das Problem zu finden bzw. zu beheben. Das dann ganz nebenbei auch noch Geschwindigkeitssteigerungen beim EPG "abfallen" sollte uns allen nur Recht sein.

@Seife

Der V2 Patch hat leider keinerlei spürbare Änderung gebracht. Muss man den V2 vor dem Error-Path-Fix anwenden oder funktioniert der "solo"?

/edit

Hier mal eine schnelle Rückmeldung eines Testers des Binaries:

Bei mir unverändert bei Passion und RTL Crime (hängt, bis sich der EPG aufgebaut hat und ist danach wieder normal verwendbar) aber bei QVC keine Freezer mehr - die Box bleibt normal bedienbar.

[seife]

Ich bitte darum, nun nur den Patch von hier http://forum.tuxbox-cvs.sourceforge.net ... 13#p360913 (sectionsd-fix-error-paths-and-rework-messaging-locks-v1.diff) zu testen. Der ältere sectionsd-remove-eitthreads-pause-v2.diff wird nicht gleichzeitig damit gehen. Das Entfernen der eitthreads-pause-Funktion ist wohl eher eine Mikrooptimierung und trifft das hier auftretende Problem nicht. Sprich: das kann man später trotzdem mal machen, es ist aber momentan nicht wichtig.

[Boardgeist]

@striper: Ich schrieb: "Wobei Fixe für diverse Probleme natürlich Klasse sind !!!!"

Und so meine ich das auch!
Ich hatte selbst eine Zeit lang Abstürze und Unbedienbarkeit, die aber im Moment nicht mehr da sind (Nokia Avia600 Sat).

Derzeit teste ich auch die neue Versuchsversion von Seife und habe noch keine Probleme festgestellt.


gruß boardgeist

[Striper]

Ich hatte selbst eine Zeit lang Abstürze und Unbedienbarkeit, die aber im Moment nicht mehr da sind (Nokia Avia600 Sat).

Achso, und da du nun keine Probleme mehr hast muss man da nix mehr machen weil irgendwann gehts dann ja bei jedem wieder... *bonk*

[GetAway]

Hi,

ich habe mir zusätzlich eine nodebug Variante für meine 2. Nokia gebaut.
Keine Probleme bisher, dafür eine exzellente Performance.
Wüsste nicht wann das zappen mal so schnell ging.

Gruß GetAway

[Striper]

Seife, ich hab nun schon von mehreren Leuten gehört das dein letzter Patch zumindest die harten Hänger in den Griff bekommt bei denen sich die Box weghängt.

Jetzt sind nur noch die Verzögerungen beim durchzappen übrig wie sie z.B. bei RTL Crime oder Passion auftreten.

[seife]

Seife, ich hab nun schon von mehreren Leuten gehört das dein letzter Patch zumindest die harten Hänger in den Griff bekommt bei denen sich die Box weghängt.

Hm, Achtung, Missverständnis: Die Hänger, wo sich die Box so weghängt, dass kein Telnet mehr geht? Das habe ich sicherlich nicht gefixt (weil's ein Treiberproblem ist), aber wenn es nun nicht mehr triggert, ist das auch schon was wert. Oder die, wo "killall sectionsd" noch was gebracht hat?

Jetzt sind nur noch die Verzögerungen beim durchzappen übrig wie sie z.B. bei RTL Crime oder Passion auftreten.

Heisst: es dauert ein paar Sekunden, fängt sich dann aber wieder? Oder sind das die, wo "killall sectionsd" benötigt wird?

[Striper]

Hm, Achtung, Missverständnis: Die Hänger, wo sich die Box so weghängt, dass kein Telnet mehr geht? Das habe ich sicherlich nicht gefixt (weil's ein Treiberproblem ist), aber wenn es nun nicht mehr triggert, ist das auch schon was wert. Oder die, wo "killall sectionsd" noch was gebracht hat?

Naja dann hast du es eben indirekt gefixt. Hab jedenfalls von keinem gehört das sich die Box mit dem Patch noch komplett weghängt bzw. nen Reeboot durchführt.

Heisst: es dauert ein paar Sekunden, fängt sich dann aber wieder?

Exakt!

[GetAway]

Hi,

teste mal auf BBC, Sky News, Al Jazeera und Luxe TV SD.

[seife]

Hm, Achtung, Missverständnis: Die Hänger, wo sich die Box so weghängt, dass kein Telnet mehr geht? Das habe ich sicherlich nicht gefixt (weil's ein Treiberproblem ist), aber wenn es nun nicht mehr triggert, ist das auch schon was wert. Oder die, wo "killall sectionsd" noch was gebracht hat?

Naja dann hast du es eben indirekt gefixt. Hab jedenfalls von keinem gehört das sich die Box mit dem Patch noch komplett weghängt bzw. nen Reeboot durchführt.

Heisst: es dauert ein paar Sekunden, fängt sich dann aber wieder?

Exakt!

Ok, das hört sich ja gut an. Ich habe deswegen auch mal diese Version ins CVS committet. Wenn es die Nokia-Hänger fixt, ist das schon mal ein Anfang