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

[bellum]

bellum-debug.diff
Probier das mal (ändert sectionsd und neutrino) und boote dann auf ProSieben mit log.

Patch angewendet, nachfolgend das Log:

Code: Alles auswählen

starting /bin/neutrino
[neutrino] frameBuffer Instance created
812k video mem
avia_gt_gv: set_input_mode (mode=2)
avia_gt_gv: set_input_size (width=720, height=576)
[neutrino] enable flash
[neutrino] Software update enabled
[lcdd] time-skin not found -> using default...
[lcdd] weekday-skin not found -> using default...
[lcdd] date-skin not found -> using default...
[lcdd] month-skin not found -> using default...
[LCDFONT] initializing core...
[LCDFONT] adding font /share/fonts/12.pcf.gz...OK (Fix12/Regular)
[LCDFONT] adding font /share/fonts/14B.pcf.gz...OK (Fix14/Bold)
[LCDFONT] adding font /share/fonts/15B.pcf.gz...OK (Fix15/Bold)
[LCDFONT] Intializing font cache...
[LCDFONT] FTC_Face_Requester (Fix15/Bold)
[LCDFONT] FTC_Face_Requester (Fix14/Bold)
/dev/input/event1: No such file or directory
[neutrino] menue setup
loading locales: scandir: No such file or directory
[neutrino] registering as event client
[controld] format: 16:9
01:00:14.941 [sectionsd] commandserviceChanged: Service changed to      453a018445d
[neutrino] initialized everything
01:00:15.251 [sectionsd] Request of current/next information for      453a018445d
01:00:15.256 currentEvt: '' (0000) nextEvt: '' (0000) flag: 0x28
PES, queue 0 normal.
[controld] VIDEO_EVENT_SIZE_CHANGED 720x576 (4:3 -> 16:9)
[timeThread] - 21.11.2008 19:13:12, tim: Fri Nov 21 19:13:12 2008
01:00:22.025 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[0] filter 0x4e mask 0xff
[timeThread] Time set via DVB, going to sleep for 5400 seconds.
01:00:22.040 dmxSDT: going to sleep...
19:13:12.100 dmxCN: going to sleep...
19:13:12.101 eit_set_update_filter, servicekey = 0x453a018445d, current version 255

[ .. ca. 1min auf LCD gewartet und dann auf ? gedrückt .. ]

19:15:09.111 [sectionsd] Request of current/next information for      453a018445d
19:15:09.119 currentEvt: 'Galileo' (453b) nextEvt: 'Projekt: Peacemaker' (453c) flag: 0x15

[ ..  LCD zeigt Sendungsfortschrittsbalken, vorher nicht .. ]

Gruß bellum

[seife]

Ok, ich weiss, woran es vermutlich liegt, und warums bei mir nicht auftritt ;-)

Ich kann es aber, vermutlich wegen der anderen Threading-Implementation in 2.6, nicht reproduzieren. Vermutlich dauert es nach dem settimeofday im TimeThread eine kurze zeit, bis alle Threads die korrekte Zeit bei time(NULL) zurückbekommen.

Ugly hack:

Code: Alles auswählen

--- sectionsd.cpp       16 Nov 2008 16:08:27 -0000      1.274
+++ sectionsd.cpp       21 Nov 2008 22:22:17 -0000
@@ -335,12 +335,13 @@ static bool       messaging_neutrino_sets_time
 inline bool waitForTimeset(void)
 {
        pthread_mutex_lock(&timeIsSetMutex);
        while(!timeset)
                pthread_cond_wait(&timeIsSetCond, &timeIsSetMutex);
        pthread_mutex_unlock(&timeIsSetMutex);
+       sleep(1);
        writeLockMessaging();
        messaging_last_requested = time(NULL);
        unlockMessaging();
        return true;
 }

Probier mal ob's hilft.

Bei mir tritt es nie auf, weil ich meine Uhr vor dem starten des sectionsd per rdate von meinem NTP-Server stelle ;-)

[bellum]

Ok, ich weiss, woran es vermutlich liegt, und warums bei mir nicht auftritt ;-)

Ich kann es aber, vermutlich wegen der anderen Threading-Implementation in 2.6, nicht reproduzieren. Vermutlich dauert es nach dem settimeofday im TimeThread eine kurze zeit, bis alle Threads die korrekte Zeit bei time(NULL) zurückbekommen.

Code: Alles auswählen

Ugly hack:

Probier mal ob's hilft.

Bei mir tritt es nie auf, weil ich meine Uhr vor dem starten des sectionsd per rdate von meinem NTP-Server stelle ;-)

habs gerade eingebaut ... und es funktioniert nun!
Habe testweise drei mal gebootet und immer wurde auch der Fortschrittsbalken aktualisiert - sehr schön!

Danke und Gruß
bellum

[seife]

Ok, dann funktioniert ja so langsam alles.
Es wird also Zeit, dass ich wieder mal was kaputt mache

[bellum]

Ok, dann funktioniert ja so langsam alles.
Es wird also Zeit, dass ich wieder mal was kaputt mache

Ja, Du hast diese und letzte Woche zwei in meinen Augen wichtige Bugs gefixt!
Von meiner Seite vielen Dank für Deine Hilfe und Dein Engagement!

Gruß bellum

P.S.: Wandert das jetzt so ins CVS?

[seife]

http://cvs.tuxbox-cvs.sourceforge.net/l ... 00062.html

[GetAway]

Ok, dann funktioniert ja so langsam alles.
Es wird also Zeit, dass ich wieder mal was kaputt mache

Joa, --freemem wartet auf dich

[rhabarber1848]

Habe testweise drei mal gebootet und immer wurde auch der Fortschrittsbalken aktualisiert - sehr schön!

Auch von mir ein Daumen nach oben! Nachdem sectionsd die Uhrzeit per DVB
erhalten hat, wird das LCD-Display aktualisiert, sieht gut aus. Danke!

[dbt]

Hier passt was nicht

Code: Alles auswählen

Thu Jan  1 01:00:00 CET 1970
$Id: sectionsd.cpp,v 1.275 2008/11/22 08:58:10 seife Exp $
[sectionsd] Caching max 6000 events
[sectionsd] Caching 14 days
[sectionsd] Caching 6 hours Exte/var/tuxbox/config/mybouquets.xml: No such file 
or directory
Segmentation fault

[seife]

kannst du mal "sectionsd -d &" im startskript machen? Das zeigt evtl. eher, wobei er abschmiert...

[dbt]

Entwarnung. Die Meldung kam nicht vom sectionsd, sondern vom alternativem camd2

Code: Alles auswählen

~ > /var/bin/camd2
Segmentation fault
~ >

In der start_neutrino waren nur die Startbefehle kurz hintereinander. Da kommt nur keine Meldung was gestartet wird, deswegen der Schnellschuß.

[GetAway]

@seife

Mir ist noch etwas aufgefallen. Vielleicht könntest du das noch ändern,
wenn es überhaupt möglich ist.
Wechsel ich, nach einem mit sectionsdcontrol --restart, --nopause
Neustart, auf einen Transponder bei dem noch keine EPG-Daten eingelesen
wurden, so steht in der Infobar, während Sie eingeblendet wird
"Keine EPG-Informationen verfügbar". Das LCD zeigt weder EPG-Info's noch
den Fortschrittsbalken an, aber den Kanalnamen. Schaut man anschließend
in die Channellist, so kann man sehen das Sendungsfortschritt und Sendungsname
eingelesen wurden.
Leider aktualisiert sich das LCD, auch nach längerer Wartezeit, nicht.
Ein Druck auf "?" hilft.
Ich weiss das ich Neutrino neustarten müßte, aber wäre es nicht auch ohne
realisierbar?
Imgage ist sebstgebaut aus den aktuellen CVS.

[seife]

Dann müsste man wieder regelmässig pollen, genau das will man aber nicht.
Warum wollen denn alle immer noch den sectionsd neu starten? Er sollte doch nun wirklich nicht mehr obszön viel Speicher verbrauchen. Ich bin mir nicht mal sicher, ob das "restart vor der Aufnahme" (was ja schon im CVS ist, man muss halt ein #define machen) überhaupt noch sinnvoll ist.

[GetAway]

Bei Aufnahme und Wiedergabe gehts doch um fraqmentierten Speicher.
Ist er zu stark fraqmentiert, klappt mit der Speicherallocation nicht richtig.
Deswegen das "freiblasen" durch den neustart.
Ein --freemem und anschliesender pause wäre natürlich ideal.
Aber leider werden ja nur die Events gelöscht und der Speicher bleibt
belegt.

[rhabarber1848]

@seife: Vielen Dank für das blacklist-Feature, besonders die except_current_next-Option.

Ich bin (leider) bei Kabel Deutschland und habe bei meiner 64MB-Dbox die EPG-Events
auf über 20000 aufgedreht, da ich gerne zwei Wochen im voraus informiert sein möchte.
Das trifft auf den EPG der ARD-Radiosender allerdings nicht zu, mit folgendem Skript,
das ich auf Basis von apps/tuxbox/neutrino/doc/epgfilter.txt geschrieben habe, konnte
ich eine passende epgfilter.xml erstellen, die mein "Radio"-Bouquet auf die blacklist setzt:

Code: Alles auswählen

#!/bin/sh
BOUQ=/var/tuxbox/config/zapit/bouquets.xml
echo '<?xml version="1.0" encoding="UTF-8"?>'
echo '<epgfilter is_whitelist = "0" except_current_next = "1">'
sed -n '/<Bouquet.*name="Radio"/,/<\/Bouquet>/{
        s/^.*<channel/ <filter/p};' $BOUQ
echo '</epgfilter>'

[seife]

Der ursprüngliche EPGfilter support ist von Nirvana (nur um hier den richtigen Leuten die Ehre zukommen zu lassen ) und wurde von Houdini in sectionsd.cpp v1.231 eingecheckt.

[GetAway]

Nur zur Info.
Version 1.283 zeigt unter statistics jetzt immer max. Events+1 an.
Mit "rc = 0;" habe ich auch mal getestet. Hat keine negativen aber
auch keine spürbaren positven Auswirkungen auf ARD wenn's POLLERR(t).
Bei mir hängt die GUI jedensfalls nicht, wenn es kurzzeitg mal auf 85% Last geht.

[Striper]

Nur zur Info.
Version 1.283 zeigt unter statistics jetzt immer max. Events+1 an.
Mit "rc = 0;" habe ich auch mal getestet. Hat keine negativen aber
auch keine spürbaren positven Auswirkungen auf ARD wenn's POLLERR(t).
Bei mir hängt die GUI jedensfalls nicht, wenn es kurzzeitg mal auf 85% Last geht.

Bei 85% würde sie wohl hier auch nicht hängen. Bei mir geht die CPU Last allerdings auf 100% und das über 2-3 Minuten hinweg.

[Houdini]

Ich habe nach einigen Stunden mühsamen printk debugging herausgefunden wann die Nokia Boxen auf den/m Problemtransponder/n abkacken. Sie kommen übrigens nach ca. 4 min wieder.
Ich weiss zwar nicht was da passiert, aber der BH (:-)) des demuxer interrupts hängt und wird nicht fertig.
Das passiert wenn in der while Schleife im dvb_dmx_swfilter_section_packet() nur noch ein byte übrigbleibt.

Ich habe als brute force workaround einen Abbruch in diesem Fall eingebaut.
Es läuft soweit. Es gibt eine print Ausgabe um zu sehen, ob und wann der Workaround auf anderen TPs oder Boxen zuschlägt.

Ein Dank geht an Gurgel der mir dafür eine Nokia Box zur Verfügung gestellt hat.
Riker will heute noch einen Testsnap machen.

Code: Alles auswählen

RCS file: /cvs/tuxbox/driver/dvb/drivers/media/dvb/dvb-core/dvb_demux.c,v
retrieving revision 1.24
diff -b -B -u -r1.24 dvb_demux.c
--- a/dvb_demux.c	19 Dec 2003 20:30:09 -0000	1.24
+++ b/dvb_demux.c	29 Jan 2009 22:00:56 -0000
@@ -296,6 +295,10 @@
 					count=0;
 
 			} else { // section continues to following TS packet
+				if (1 == count) {
+					printk("Nokia epg workaround!\n");
+					return -1;
+				}
 				demux->memcopy(feed, sec->secbuf, buf+p, count);
 				sec->secbufp+=count;
 				count=0;

[JtG-Riker]

Hier der Link zum Thread im JTG-Forum

http://www.jackthegrabber.de/viewtopic. ... 74#p108374

Gruß Riker

[tine1084]

Also nach fast 6 stunden test auf meiner nokia box und ohne der epgfilter.xml bisher keine hänger mehr auf den problemsendern. Danke houdini für deine mühe!

Hier ein log von einem problemsender:

12:10:58.270 dmxCN: going to sleep...
12:10:58.271 eit_set_update_filter, servicekey = 0x45400012f44, current version 13
Nokia epg workaround!
Nokia epg workaround!
Nokia epg workaround!
Nokia epg workaround!
Nokia epg workaround!
12:11:37.530 EIT Update Filter: Activate cnThread
12:11:37.567 dmxCN: waking up again - requested from .change()
Nokia epg workaround!
Nokia epg workaround!
Nokia epg workaround!
Nokia epg workaround!
12:12:13.310 dmxCN: going to sleep...
12:12:13.311 eit_set_update_filter, servicekey = 0x45400012f44, current version 14
Nokia epg workaround!
Nokia epg workaround!
Nokia epg workaround!
Nokia epg workaround!
Nokia epg workaround!
12:12:52.570 EIT Update Filter: Activate cnThread
12:12:52.606 dmxCN: waking up again - requested from .change()

Also von mir aus kann es ins cvs eingecheckt werden.

[rhabarber1848]

Tritt das Problem auch mit Kernel 2.6 auf? Ich frage deshalb,
weil driver/dvb/drivers/media/dvb/dvb-core/dvb_demux.c
in driver_2_6_branch anders aussieht.

[Striper]

Das war auch mein erster Gedanke. Dort wurde allerdings doch sehr viel geändert. Vielleicht würde es aber trotzdem lohnen wenn einer mit Ahnung da mal drüber sieht und evtl. einen Backport erstellt.

[seife]

Es müsste einfach mal ein nokia-Betroffener mit 2.6 testen. Aber ich glaube mich zu erinnern, dass es Meldungen gab, dass es dort auch auftritt.

Mit dem Topic dieses Threads haben wir hier übrigens überhaupt nichts mehr zu tun

[seife]

in 2.6 ist der code imvho in dvb_dmx_swfilter_section_copy_dump() und dort wird explizit nur bis "pufferlänge - 2" gezählt, insofern scheint der bug dort nicht drin zu sein.
Man könnte auch mal versuchen, 2.4 auf die letzten Treiber (1.1.1 für 2.4) von linuxtv.org "aufzurüsten", inzwischen wurde bestimmt schon einiges gefixt.