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

[PauleFoul]

Hört sich jedenfalls sehr gut an...

[seife]

Dessen bin ich mir nicht so sicher. Aber wenn niemandein offensichtlicher Denkfehler auffällt, dann werden wir es wohl probieren müssen.

[GetAway]

Mit nem Diff bin ich dabei.

[Houdini]

ich versuche mal mein Glück...

Edit:
http://home.arcor.de/houdini/dbox/secti ... 2-15.patch

[GetAway]

Muss das noch abgesegnet werden, oder hast Du es schon bei Dir laufen?

[Houdini]

es läuft, aber ich habe das Gefühl als ob die c/n events viel später kommen würden

[re_Look]

Danke für diff, aber geht das nicht ganz ohne malloc ?
char *static_buf[MAX_SECTIONS_LENGHT] = {0};

und malloc mit delete ist auch nicht ok.
char *static_buf = (char *)malloc(MAX_SECTIONS_LENGHT);
delete [] static_buf;

[Houdini]

Code: Alles auswählen

Danke für diff, aber geht das nicht ganz ohne malloc ?

doch geht, aber ich wollte nicht 4k auf den stack pumpen, eine einmaliger malloc schien mir angebracht

und malloc mit delete ist auch nicht ok.

ups, stimmt

Edit: Patch aktualisiert

[re_Look]

Ich habe eine dumme Frage:
Was garantiert in dmx.cpp zwischen ersten read (header) und zweiten (buffer), dass es immer noch das gleiche teil in buffer kommt ?
Ich meine zwischen einem read und zweiten vergeht auch etwas zeit.

[seife]

Das ist so ungefähr so, wie ich es mir vorgestellt habe. Ich bin leider noch nicht dazugekommen, was zu machen oder zu probieren, weil ich immer noch mit den Drachentreibern kämpfe Da weiss man erst mal wieder, was man an der dreambox oder gar der dbox2 hat

re_Look: der Treiber garantiert das hoffentlich (auf der TD anscheinend nicht, das ist ja grad mein Problem). Der Kernel puffert die sectionsd ja, und du liest nur den Puffer aus.

[GetAway]

Kaputt gegangen ist scheinbar nichts. Auf ARD wird nach wie vor gePOLLERRt.
Kein Unterschied bemerkbar. Performancevorteile nicht spürbar.

[mb405]

jep hier das selbe.

[Striper]

Ich hab mal Probeweise diese beiden Zeilen in sectionsd auskommentiert:

Code: Alles auswählen

	dmxEIT.addfilter(0x60, 0xf1); //4a other TS, scheduled, even
	dmxEIT.addfilter(0x61, 0xf1); //4b other TS, scheduled, odd

Das EPG funktioniert weiterhin recht gut. Man muss eben auf den jeweiligen Transponder schalten um die späteren EPG-Daten dafür zu bekommen. Allerdings sind die hier beschriebenen Probleme damit komplett weg. Ich finde das eig. ganz OK so.

[re_Look]

Hat schon jemand von euch Speicher verbrauch verglichen ?

@Houdini
Ich will dich nicht nerven, aber weil bei section schon new/delete in Einsatz ist, sollte mann dabei bleiben.

[Striper]

Ich hab mal Probeweise diese beiden Zeilen in sectionsd auskommentiert:

Code: Alles auswählen

	dmxEIT.addfilter(0x60, 0xf1); //4a other TS, scheduled, even
	dmxEIT.addfilter(0x61, 0xf1); //4b other TS, scheduled, odd

Das EPG funktioniert weiterhin recht gut. Man muss eben auf den jeweiligen Transponder schalten um die späteren EPG-Daten dafür zu bekommen. Allerdings sind die hier beschriebenen Probleme damit komplett weg. Ich finde das eig. ganz OK so.

Hat das schon mal einer von den HDD Besitzern getestet? Ich denke das die Probleme bei Aufnahmen von z.B. ARD sich dadurch wesentlich verbessern, da der sectionsd nach dem zappen auf ARD nicht mehr die Box lahm legt. Sehr elegant ist meine Herangehensweise sicherlich nicht, allerdings schält sich imo dadurch der Kern des Problems etwas heraus.

Meine Idee wäre es die beiden oben erwähnten Filter von der Priorität extrem herab zu setzen, so das diese wirklich nur dann Daten sammeln wenn die Box nichts anderes zu tun hat.

[seife]

Typischerweise hält man den sectionsd ja an, wenn man aufnimmt, insofern sollte das für die Aufnahme keine Änderung sein.

[jojo]

Bei mir gab es gravierende Unterschiede - positiver Natur. Während der Aufnahme war die Box bedienbar.
Da ich allerdings die Patches der letzten beiden Wochen eingespielt habe, kann ich noch nicht sagen ob
es am auskommentierten "addfilter" oder einem der anderen Patches liegt.

Typischerweise hält man den sectionsd ja an, wenn man aufnimmt, insofern sollte das für die Aufnahme keine Änderung sein.

Übernimmt das nicht Neutrino? Dachte, das Gefummel im recording.{start,end} wäre kontraproduktiv?

[seife]

Bei mir gab es gravierende Unterschiede - positiver Natur. Während der Aufnahme war die Box bedienbar.

Was machte den Unterschied: Houdini's Patch, das Entfernen der TS_OTHER-Filter oder beides zusammen?

Da ich allerdings die Patches der letzten beiden Wochen eingespielt habe, kann ich noch nicht sagen ob
es am auskommentierten "addfilter" oder einem der anderen Patches liegt.

Typischerweise hält man den sectionsd ja an, wenn man aufnimmt, insofern sollte das für die Aufnahme keine Änderung sein.

Übernimmt das nicht Neutrino? Dachte, das Gefummel im recording.{start,end} wäre kontraproduktiv?

AFAIR kann man das irgendwo im Neutrino einstellen....
...zumindest gibt's ne locale dazu:

Code: Alles auswählen

seife@stoetzler:/tmp/mainline> git grep "stopsectionsd Sectionsd anhalten"|cat
tuxbox/neutrino/data/locale/deutsch.locale:recordingmenu.stopsectionsd Sectionsd anhalten

;-)

[Striper]

Was machte den Unterschied: Houdini's Patch, das Entfernen der TS_OTHER-Filter oder beides zusammen?

Ich kann mir nicht vorstellen das Houdini's Patch da so viel Unterschied macht. Der sectionsd schlägt ja trotzdem voll rein sobald er auf ARD die TS_OTHER Filter anwirft. Könnte man die Priorität der beiden TS_OTHER Filter per setpriority() auf ein Minumum setzen?

[jojo]

Was machte den Unterschied: Houdini's Patch, das Entfernen der TS_OTHER-Filter oder beides zusammen?

Ich kann mir nicht vorstellen das Houdini's Patch da so viel Unterschied macht. Der sectionsd schlägt ja trotzdem voll rein sobald er auf ARD die TS_OTHER Filter anwirft. Könnte man die Priorität der beiden TS_OTHER Filter per setpriority() auf ein Minumum setzen?

Ich kompilier grad mal durch, um zu sehen woher der Unterschied rührt...

[seife]

Eine dmx.cpp wie die:
http://gitorious.org/projects/tuxbox-ap ... sd/dmx.cpp
könnte helfen, denn das teilweise Lesen der section (erst 3 bytes Header, dann den Rest) wird vermutlich durch umkopieren im Kernel gemacht. Da das mit dem Treiber der TD nicht geht, habe ich die dmx.cpp so gemacht, dass immer eine komplette section gelesen wird ohne retry.

Genauer ist es dieser diff: dmx-efficiency-fix.diff(achtung: "schmutzig")
Ob der allerdings auf der dbox überhaupt funktioniert, habe ich nicht getestet.

Sectionsd generell mit "nice nice sectionsd" zu starten ist vermutlich keine schlechte Idee, aber es wird dann mehr POLLERRs geben (auch wenn die Harmlos sind, genügend User beschweren sich ja drüber).

[Striper]

Meine Holzhammermethode hat den netten Nebeneffekt das man den EIT-Filter in der Größe auf 256 absenken kann und es trotzdem nie zu POLLER oder "Value too large for defined data type" kommt. ;)

[seife]

Zum 100. Mal: POLLERR oder EOVERFLOW sind Harmlos, schliesslich handelt es sich ja nicht um unwiederbringliche Daten. Ich glaub ich mach einfach mal die Meldungen weg

[Striper]

Zum 101 Mal. Das weiß ich. Weg sind sie trotzdem! ;) :P

Zudem sagen die doch (auch wenn sie harmlos sind) nix anderes aus, als das die Box hier überfordert ist.

[rhabarber1848]

Genauer ist es dieser diff: dmx-efficiency-fix.diff(achtung: "schmutzig")
Ob der allerdings auf der dbox überhaupt funktioniert, habe ich nicht getestet.

Der Patch ist mittlerweile wohl im CVS
http://cvs.tuxbox-cvs.sourceforge.net/c ... 45&r2=1.46

Bisher keine negativen Auffälligkeiten auf der Dbox2.