sectionsd Patches committed

[seife]

Ich habe soeben meine sectionsd-Patchqueue geleert (= ins CVS eingechecked). Bei mir funktioniert das seit langem recht ordentlich, die letzten Probleme habe ich in den letzten Tagen gefixt.

Vermutlich ist natürlich auch wieder was dabei kaputtgegangen, Bugreports also hierher.

Das Feature "sectionsd restart" kann man dazu benutzen, den sectionsd neu zu starten, ohne daß er seine Konfiguration verliert (ansonsten muß man nämlich auch neutrino neu starten). Nach dem Neustart pausiert er bis zu einem setPauseScanning(false).

Viel Spaß

[Hollo]

thX na dann mal testen ..........

[trulli]

Das Feature "sectionsd restart" kann man dazu benutzen, den sectionsd neu zu starten, ohne daß er seine Konfiguration verliert (ansonsten muß man nämlich auch neutrino neu starten). Nach dem Neustart pausiert er bis zu einem setPauseScanning(false).

Hi,

kannst Du mir bitte sagen, wie ich dieses Feature aufrufen kann oder muss?

MfG

[PT-1]

sectionsd -? oder --h oder -h sollte dir die Optionen zeigen

[trulli]

Hi,

zeigt dann nur an: usage [-d] [-nu]

Also ich brauche doch noch mehr Hilfe.
Weiss denn jemand, wie das mit dem restart geht?

MfG

[ingrid]

Laut CVS-Log müsste es "sectionsdcontrol --restart" sein.

Code: Alles auswählen

  	printf("        sectionsdcontrol --wepg <epgdir> write epgfiles to dir\n");
  	printf("        sectionsdcontrol --repg <epgdir> read epgfiles from dir\n");
  	printf("        sectionsdcontrol --freemem       unloads all events\n");
 +	printf("        sectionsdcontrol --restart       restart sectionsd\n");

[trulli]

Hi,

danke. Jetzt habe ich es verstanden.

Ist eine Option vom "sectionsdcontrol".
Das stand leider bei Seife nicht dabei.

Bringt bei mir aber nur einen "global symbol" Error.

Aber egal. Trotzdem vielen Dank.

MfG

[kroki]

Hi seife,

ich hab mir der Restart-Funktion auch ein Problem: Sobal ich einen Restart auslöse sowohl über sectionsdcontrol oder über den internen client 'g_Sectionsd->Restart()' kommt nocht restarting sectionsd und dann hängt sich die D-Box komplett weg.

Kroki

[seife]

Hm. Bei mir nicht
"Hängt sich komplett weg" heißt, du kannst dich nicht mehr per telnet einloggen und auf der seriellen Konsole geht auch nix mehr? Das wäre dann ein Kernel-Bug... Da wäre ein Log der seriellen Konsole hilfreich.

Edit: so sieht das bei mir aus (an der seriellen Konsole getippt):

Code: Alles auswählen

/ $ sectionsdcontrol --restart
restarting sectionsd
re-starting /bin/sectionsd
[sectionsd] starting '/bin/sectionsd'
/ $ $Id: sectionsd.cpp,v 1.257 2008/01/05 18:05:13 seife Exp $
[sectionsd] getting configuration from environment, starting paused
GETENVI(auto_scanning) = 1
GETENVL(secondsToCache) = 1209600
GETENVL(oldEventsAre) = 3600
GETENVL(secondsExtendedTextCache) = 86400
GETENVI(max_events) = 5000
GETENVI(ntprefresh) = 30
GETENVI(ntpenable) = 0
GETENVS(ntp_system_cmd) = /sbin/rdate -s de.pool.ntp.org
GETENVS(epg_dir) =
GETENVB(update_eit) = 1
GETENVB(bTimeCorrect) = 0
GETENVI(debug) = 0
[sectionsd] Caching max 5000 events
[sectionsd] Caching 14 days
[sectionsd] Caching 24 hours Extended Text
[sectionsd] Events are old 60min after their end time
/var/tuxbox/config/mybouquets.xml: No such file or directory
[eitThread] pid 771 start
[timeThread] - 06.01.2008 16:50:04, tim: Sun Jan  6 16:50:04 2008
[timeThread] Time set via DVB, going to sleep for 1800 seconds.
/ $ sectionsdcontrol --nopause
setPauseScanning false
/ $

Edit2: ich sehe aber gerade, daß das so nicht richtig funktionieren kann, da die event-Registrierung beim restart verloren geht (das was in CNeutrinoApp::run() mit den ganzen g_Sectionsd->registerEvent() gemacht wird. Deswegen bekommt neutrino keine Events mehr von sectionsd, und das ganze kommt etwas aus dem Tritt. Naja. Nice try, aber ich würde diese neue Funktion erstmal ignorieren...

[Gaucho316]

Das Feature "sectionsd restart" kann man dazu benutzen, den sectionsd neu zu starten, ohne daß er seine Konfiguration verliert (ansonsten muß man nämlich auch neutrino neu starten). Nach dem Neustart pausiert er bis zu einem setPauseScanning(false).

Bist du dir sicher, dass man Neutrino neu starten muss nach dem Killen und einem anschließendem Neustart des sectionsd? Wenn ich das nämlich über Telnet mache, zeigt der sectionsd mir ja beim Start sein Log. Dort stehen dann meine Einstellungen und es wird wohl nicht die Standardkonfiguration genommen.

[kroki]

@seife

die Box hängt sich wirklich komplett weg Telnet tot und auf der seriellen Konsole ist nur noch das "restarting sectionsd" zu sehen und dann ist aus.

Kroki

[seife]

Bist du dir sicher, dass man Neutrino neu starten muss nach dem Killen und einem anschließendem Neustart des sectionsd? Wenn ich das nämlich über Telnet mache, zeigt der sectionsd mir ja beim Start sein Log. Dort stehen dann meine Einstellungen und es wird wohl nicht die Standardkonfiguration genommen.

Ja. Das habe ich ja auch implementiert. Aber die Event-Registrierung hatte ich dabei übersehen. Die vergißt er.

[seife]

@seife

die Box hängt sich wirklich komplett weg Telnet tot und auf der seriellen Konsole ist nur noch das "restarting sectionsd" zu sehen und dann ist aus.

Mist.
Probier bitte mal diesen Diff aus, ob der hilft:
sectionsd-for-kroki.diff
Dabei werden (hoffentlich) alle Threads, die Devices geöffnet haben, beendet und erst dann der sectionsd neu gestartet (in diesem Fall sollte man das commandRestart() natürlich blockend machen, da es durchaus einige Sekunden dauern kann, bis der sectionsd sich nun neu startet, aber das ist erstmal nicht so wichtig). Das ganze riecht zwar nach Treiberproblem, aber ist vermutlich schwierig zu lokalisieren und zu fixen, darum hoffe ich, daß ich es somit umgehen kann.
Wenn jemand sich mit pthreads besser auskennt als ich (wozu nicht viel gehört), dann wäre ein Blick auf diesen Patch auch eine gute Idee, ich weiß da nämlich nicht genau, was ich tue

[Gaucho316]

Bist du dir sicher, dass man Neutrino neu starten muss nach dem Killen und einem anschließendem Neustart des sectionsd? Wenn ich das nämlich über Telnet mache, zeigt der sectionsd mir ja beim Start sein Log. Dort stehen dann meine Einstellungen und es wird wohl nicht die Standardkonfiguration genommen.

Ja. Das habe ich ja auch implementiert. Aber die Event-Registrierung hatte ich dabei übersehen. Die vergißt er.

Ich hätte noch einen Satz mehr schreiben sollen. Ich nutze das JtG-Image vom 21.12.2007. Dort verhält sich der sectionsd wie oben beschrieben.

[seife]

Aber nur, wenn du die Config vorher gespeichert hast
Und die auto_scanning config wird auch nicht aus der Datei geladen.
Aber egal, auch dann geht die Event-Registrierung verloren.

[Gaucho316]

Wie äußert sich den eigentlich das Verlieren der Event-Registrierung? Ich kille den sectionsd immer beim Start des Movieplayers und starte ihn dann wieder beim Beenden des Movieplayers. Ich kann keine Unterschiede vorher und nachher feststellen. Es werden alle Events wieder ganz normal eingelesen.

[seife]

Da Neutrino soviele Workarounds drin hat und sich praktisch gar nicht mehr auf die sectionsd-Events verläßt, fällt das kaum auf. Das ist ein Grund, warum Neutrino so ineffizient ist
Z.B. kriegt es nicht mehr mit, wenn die Zeit neu gestellt wird, was interne Timer falsch ticken läßt etc.
Nichts dramatisches, aber halt viele Kleinigkeiten.
Genau für Anwendungsfälle wie deinen, nämlich beim Start des Movieplayers oder einer Aufnahme den sectionsd neu zu starten (und pausieren zu lassen, bis die Aufnahme beendet ist) habe ich den restart-Befehl auch vorgesehen, aber das braucht offensichtlich noch ein wenig Feintuning.

[kroki]

@seife

Hat sich leider nix geändert .....

Code: Alles auswählen

[neutrino] registering as event client
[controld] setting VideoFormat to auto 
[controld] format: 4:3(LB)
[neutrino] initialized everything
[controld] VIDEO_EVENT_SIZE_CHANGED 480x576 (4:3 -> 4:3)
[controld] VIDEO_EVENT_SIZE_CHANGED 720x576 (4:3 -> 16:9)
[controld] format: 16:9
login[411]: root login on 'pts/0'
re-starting /bin/sectionsd
18:34:50.093 [sectionsd] signalling threadTOT to exit...
18:34:50.136 [sectionsd] threadTOT exited
18:34:50.181 [sectionsd] signalling threadEIT to exit...
18:34:50.241 [sectionsd] threadEIT exited
18:34:50.287 [sectionsd] signalling threadPPT to exit...
18:34:50.452 [sectionsd] threadPPT exited
18:34:50.453 [sectionsd] signalling threadSDT to exit...
18:34:51.080 [sectionsd] threadSDT exited
18:34:51.080 [sectionsd] signalling threadNIT to exit...
18:34:51.275 [sectionsd] threadSDT exited

Und dann ist Feierabend .....

Kroki

[seife]

Hm. Seltsam. Vermutlich hängt er sich beim schließen der Filedeskriptoren weg, das kommt nämlich danach:

Code: Alles auswählen

        printdate_ms(stderr);fprintf(stderr,"[sectionsd] signalling threadNIT to exit...\n");
        pthread_mutex_lock(&dmxNIT.start_stop_mutex);
        pthread_cond_broadcast(&dmxNIT.change_cond);
        pthread_mutex_unlock(&dmxNIT.start_stop_mutex);
        pthread_join(threadNIT, NULL);
        printdate_ms(stderr);fprintf(stderr,"[sectionsd] threadSDT exited\n");

        // we don't care for the housekeeping thread, since it is not
        // holding any devices open...

        for (int i = 3; i < 256; i++)
                close(i);
        char *val = (char*)malloc(32);  // needed for SETENV?-macros
        unlink(SECTIONSD_UDS_NAME);

Mache hier mal folgendes draus:

Code: Alles auswählen

        for (int i = 3; i < 256; i++) {
                printdate_ms(stderr);
                fprintf(stderr, "closing fd %d\n", i);
                close(i);
        }

Und ich verstehe das richtig: wenn die Kiste hängt, ist auch nix mehr mit ftp oder neuer telnet-Verbindung?

Achso. Nochwas: vor du den sectionsd restartest, mach noch folgendes:

Code: Alles auswählen

pidof sectionsd        # die PID notieren
ls -l /proc/$PID/fd/   # $PID durch die PID ersetzen

Damit wir wissen, welches Device zu welchem Filedescriptor gehört hatte.

[kroki]

@seife,

ja die Kiste hängt sich komplett weg. Kein Telnet, ftp , keine Fernbedienung mehr gar nichts! Einfach tot!

Code: Alles auswählen

~ > pidof sectionsd
128 127 126 125 123 121 119 118

 ls -l /proc/118/fd
lrwx------    1 root     root           64 Jan  7 20:43 0 -> /dev/console
lrwx------    1 root     root           64 Jan  7 20:43 1 -> /dev/console
lrwx------    1 root     root           64 Jan  7 20:43 2 -> /dev/console
lrwx------    1 root     root           64 Jan  7 20:43 3 -> socket:[167]
lr-x------    1 root     root           64 Jan  7 20:43 4 -> pipe:[169]
l-wx------    1 root     root           64 Jan  7 20:43 5 -> pipe:[169]
lrwx------    1 root     root           64 Jan  7 20:43 6 -> /dev/dvb/adapter0/demux0



[neutrino] registering as event client
[controld] setting VideoFormat to auto 
[controld] format: 4:3(LB)
[neutrino] initialized everything
[controld] VIDEO_EVENT_SIZE_CHANGED 480x576 (4:3 -> 4:3)
login[178]: root login on 'pts/0'
re-starting /bin/sectionsd
19:45:24.986 [sectionsd] signalling threadTOT to exit...
19:45:25.030 [sectionsd] threadTOT exited
19:45:25.075 [sectionsd] signalling threadEIT to exit...
19:45:25.138 [sectionsd] threadEIT exited
19:45:25.180 [sectionsd] signalling threadPPT to exit...
19:45:26.245 [sectionsd] threadPPT exited
19:45:26.245 [sectionsd] signalling threadSDT to exit...
19:45:26.520 [sectionsd] threadSDT exited
19:45:26.520 [sectionsd] signalling threadNIT to exit...
19:45:29.093 [sectionsd] threadSDT exited
19:45:29.094 closing fd 3
19:45:29.138 closing fd 4
19:45:29.166 closing fd 5

Und wieder tot !

Kroki

[seife]

Hm. Das ist seltsam. Die pipe kommt vermutlich irgendwoher aus der glibc, da kommunizieren vermutlich die threads im sectionsd irgendwie miteinander. Zumindest sehe ich nicht, daß sie explizit angelegt wird. Wegen der anderen Threading-Implementierung im 2.6 ist mir das nicht aufgefallen (ich habe diese Pipe auf den 2.6er Boxen nicht, nur auf der 2.4er. Die kann ich jetzt aber nicht testen, da ich 400km von Zuhause weg bin und mir solche Aktionen immer massiven Ärger einbringen:-)
Mach doch mal die Schleife mit dem close() ganz raus und versuche es dann nochmal.
Falls es dann zu funktionieren scheint: vorher und nachher die PIDs des sectionsd prüfen, nur eine darf gleich sein. Außerdem mußt du dann nach dem restart (so er denn funktioniert) schauen, ob es nicht auf wundersame Weise mehr Filedeskriptoren wurden - schließlich habe ich mir schon was bei dem close() gedacht, auch wenn's nicht unbedingt richtig war

[Gaucho316]

ich hab mir der Restart-Funktion auch ein Problem: Sobal ich einen Restart auslöse sowohl über sectionsdcontrol oder über den internen client 'g_Sectionsd->Restart()' kommt nocht restarting sectionsd und dann hängt sich die D-Box komplett weg.

Ich habe mir gestern den neuen JtG-Snap installiert und kann dieses Verhalten bestätigen. Somit ist Kroki nicht allein mit diesem Problem.

[seife]

Dann müssen wir halt ein #ifdef reinmachen, daß diese Funktion nur bei kernel 2.6 eingebaut wird ;-)

[seife]

Sollte im aktuellen CVS jetzt gefixt sein.

[kroki]

@seife

funktioniert soweit, nur das nach einem Neustart der EPG nicht automatisch auf ein geht.
Du hast die variable "scanning" nicht mit im ENV gespeichert setzt die nach dem Restartauf auf 0. Und dann liest du die Variablen ein und diese werden von der Main-Routine gleich wieder überschreiben ... da solltest du noch mal drüber schauen ....

Ansonsten hast du im Imageinfo die Routine zum Flash-Type erkennen geändert. Ich finde die Lösung so nicht ok, weil ich und andere ein anderes Flashlayout nutzen, wo es den BR-Bootloader nicht mehr drinnen gibt, sowas z.B:

Code: Alles auswählen

dev:    size   erasesize  name
mtd0: 00020000 00020000 "U-Boot (flfs)"
mtd1: 006a0000 00020000 "root (squashfs)"
mtd2: 00120000 00020000 "var (jffs2)"
mtd3: 007e0000 00020000 "Flash komplett"

Die Erkennung kann man auch über das flfs machen :

Code: Alles auswählen

string CImageInfo::getChipInfo()
{
                FILE* fd = fopen("/dev/mtd/0", "r");
                if(fd)
                {
                        char buffer[20];

                        for ( int i=0;i<=10;i++)
                                buffer[i]=fgetc(fd);

                        if(buffer[2] == 0x03 && buffer[3] == 0x01 && buffer[4] == 0x00 && buffer[5] == 0x3F )
                                        chiptype = "1xI";
                        else if(buffer[4] == 0x03 && buffer[5] == 0x01 && buffer[8] == 0x00 && buffer[9] == 0x7E )
                                        chiptype = "2xI";
                        else
                                        chiptype ="n/a";

                        fclose(fd);
                }
                else
                         chiptype ="Error";

        return chiptype;
}

Ist auch nicht komplizierter, aber einfacher an die Images anzupassen ....


Kroki