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

[Tommy]

das muß aber nicht an diesem Patch liegen. Dieses Phänomen abe ich des öfteren gesehen wenn ich beim Movieplayer den sectionsd aus Performancegründen kille. Nach restart reagiert der Sectionsd teilweise nicht. Hatte das aber noch nie an einem sender festgemacht

[GetAway]

Habe gerade mal die 3 Sender getestet. Keine Probs festgestellt.
Ich habe allerdings auch Privatkabel mit Sateinspeisung.
EPG-Info's laufen sofort nach dem starten rein.

Wie wärs mal mit nem LOG des sectionsd 1.264-try2 auf einem
dieser Sender?

Desweiteren könnte man mal über einen "ECHTEN" EPG-Reset nachdenken.

[weinleiche]

Wie wärs mal mit nem LOG des sectionsd 1.264-try2 auf einem
dieser Sender?

Mache ich gerne, jedoch, wie?
Ich habe keine Entwicklungsumgebung für die dbox und keinen Rechner mit serieller Schnittstelle (ist bei den neueren Rechnern irgendwie nicht mehr so modern). Kann man die dbox dazu überreden irgendwie aufs Netz zu loggen?
Wenn ich den sectionsd von Hand starte, logged er ja ein bisschen was auf die Konsole, ist das ausreichend? Oder gibt es einen switch beim sectionsd, damit er gesprächiger wird?

Desweiteren könnte man mal über einen "ECHTEN" EPG-Reset nachdenken.

Das fänd ich auch nicht schlecht, bzw. für mich wäre eher so eine Art "clear" interessant. Aber da mein Anwendungsfall sicherlich etwas exotisch ist, wollte ich die Entwickler damit nicht nerven. Ich benutze die dbox u.a. als meine "Fernsehzeitung", also des Nächtens zappe ich (bzw. mein Server) durch die Sender und ziehe die EPGs ab um sie auf meinem Server in eine Datenbank zu schreiben. Dabei ist mir aufgefallen, dass der sectionsd anscheinend nicht mehr so willig neue Events aufnimmt, wenn er bereits von anderen Sendern gut gefüllt ist. Daher kille ich den sectionsd nach 'nem Transponderwechsel und starte ihn neu. Nachdem alle Sender abgegrast sind, wird die dbox resettet. Funktioniert eigentlich ganz gut, aber ein "sauberes" löschen der events im sectionsd wäre mir natürlich lieber. Aber das nur so am Rande, ich kann auch so damit leben. Nur dass er eben manchmal gar keine Events zieht, ist dann natürlich ärgerlich.

[dwilx]

Kann man die dbox dazu überreden irgendwie aufs Netz zu loggen?

setconsole? Geht das bei Dir?

[DrStoned]

Wenn ich den sectionsd von Hand starte, logged er ja ein bisschen was auf die Konsole, ist das ausreichend? Oder gibt es einen switch beim sectionsd, damit er gesprächiger wird?

Das genügt.

Falls Du setconsole in Deiner busybox drin hast, kannst Du auch diesen Befehl verwenden. Dieser Befehl leitet die Ausgaben der seriellen Schnittstelle auf die Telnet-Console um. Damit es funktioniert, unter Dbox-Taste -> Einstellungen -> Treiber- und Bootoptionen -> EXPERT! Boot-Konsole auf seriell stellen, und danach die Box neu starten. Dann per Telnet auf die Box einloggen und den Befehl setconsole eingeben.

Greetz von DrStoned

[weinleiche]

setconsole? Geht das bei Dir?

Kann ich erst heute Abend probieren, bin gerade im Büro.
Bin mit "setconsole" nicht vertraut, was muss ich da als console angeben?

[weinleiche]

@DrStoned: Danke für die ausführliche Info. Werde das dann heute Abend mal machen und die Ergebnisse hier rein posten. Ich habe ein Standard JtG Image 2.2.7a(?, jedenfalls von irgendwann im Mai diesen Jahres).

[DrStoned]

@DrStoned: Danke für die ausführliche Info. Werde das dann heute Abend mal machen und die Ergebnisse hier rein posten. Ich habe ein Standard JtG Image 2.2.7a(?, jedenfalls von irgendwann im Mai diesen Jahres).

Damit geht das auf jeden Fall.

Hier habe ich übrigens eine Anleitung gepostet, wie man den neuen sectionsd im JtG-Image verwenden kann.

Greetz von DrStoned

[Tommy]

bzw. für mich wäre eher so eine Art "clear" interessant.

das kann doch sectionsdcontrol mit parameter fremem oder so. Mach mal an der Konsole sectionsdcontrol dan kriegst Du alles angezeigt.

Betr. serielle Schnittstelle -> faule Ausrede. Die USB2Seriell Adapter kriegst Du an jeder Ecke nachgeworfen. Wer sich ernsthaft mit der Box beschäftigt kommt um einen Comport nicht herum.

[weinleiche]

das kann doch sectionsdcontrol mit parameter fremem oder so. Mach mal an der Konsole sectionsdcontrol dan kriegst Du alles angezeigt.

Das wusste ich nicht, danke für den Hinweis, werde ich mir mal anschauen.

Betr. serielle Schnittstelle -> faule Ausrede. Die USB2Seriell Adapter kriegst Du an jeder Ecke nachgeworfen. Wer sich ernsthaft mit der Box beschäftigt kommt um einen Comport nicht herum.

Das glaube ich gerne, aber 1) beschäftige ich mich nicht ernsthaft mir der dbox-Entwicklung (zwar würde es mich interessieren, aber ich habe einfach nicht die Zeit dafür), 2) hat mein Rechner wirklich keine serielle und ich brauche eigentlich auch keine, 3) geht es anscheinend für meinen speziellen Fall auch ohne. Also, einfach entspannen.

Mir ist beim herumprobieren mit dem sectionsd was aufgefallen, was ich den Entwicklern mitteilen wollte, in der Hoffnung, dass es vielleicht hilft. Ich stelle keine Forderungen, ich habe nichtmal große Erwartungen, freue mich aber natürlich, wenn ich etwas beitragen kann. Das ist alles. Ich habe keinen Grund für faule Ausreden.

[PauleFoul]

bzw. für mich wäre eher so eine Art "clear" interessant.

das kann doch sectionsdcontrol mit parameter fremem oder so. Mach mal an der Konsole sectionsdcontrol dan kriegst Du alles angezeigt.

Betr. serielle Schnittstelle -> faule Ausrede. Die USB2Seriell Adapter kriegst Du an jeder Ecke nachgeworfen. Wer sich ernsthaft mit der Box beschäftigt kommt um einen Comport nicht herum.

Bitte locker bleiben...

[jmittelst]

Recht hat er aber. Nullmodem und ggf. dafür nötigen USB>Seriell-Adapter gehören zur Dbox, wie Strom.

cu
Jens

[weinleiche]

Recht hat er aber. Nullmodem und ggf. dafür nötigen USB>Seriell-Adapter gehören zur Dbox, wie Strom.

Bitte keine Grabenkämpfe. Es war eine reine Feststellung von mir, dass ich keine serielle Schnittstelle habe (zum reinen benutzen der dbox scheint es auch ohne zu gehen ), verbunden mit der Frage, ob man auch anders ans Log kommt. Eine Antwort "geht nur mit Nullmodem" hätte mich dazu bewogen entweder zu sagen, dann hab ich halt Pech gehabt, oder ich hätte mir ein Nullmodemkabel zuzüglich eines USB/Seriell Konverters besorgt. Punkt. So what? Es gibt kein Problem, also machen wir uns doch auch keins.

[Tommy]

War auch nicht so "Bierernst" gemeint aber *just kidding* Paule fühlt sich bei "faul" ja immer gleich angesprochen

[SnowHead]

Ich habe keine Entwicklungsumgebung für die dbox und keinen Rechner mit serieller Schnittstelle (ist bei den neueren Rechnern irgendwie nicht mehr so modern). Kann man die dbox dazu überreden irgendwie aufs Netz zu loggen?

Wenn in der Busybox das Applet "setconsole" implementiert ist, kann man sich im
Telnet nach Eingabe dieses Befehls das Log auch auf die Telnet-Konsole ausgeben
lassen. Gib im Telnet mal "busybox" ein und schau nach, ob "setconsole" mit aufge-
listet ist. Wenn nicht, kann man zum Test auch eine Busybox mit implementierten
setconsole mit den Rechten 755 nach /tmp/ schieben und sich das Log nach Ein-
gabe von "/tmp/busybox setconsole" anschauen.

[weinleiche]

So, dank Euren Tipps habe ich nun also auch ein paar Logs. Man muss sich nur nach dem boot schnell genug auf der dbox einloggen und dann bekommt man sogar noch den Start des sectionsd mit .

Also, dann mal von vorne (hoffentlich passt das in ein Post):

Ich habe die dbox auf MDR neu gestartet, daher ist das Log noch vom alten sectionsd aus dem JtG Image:

Code: Alles auswählen

Willkomen auf Ihrer d-box 2 - Kernel 2.4.36.3-dbox2 (01:28:43). - JtG-Image -
dbox login: root
Password:


BusyBox v1.10.1 (2008-04-19 22:17:14 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ > setconsole
~ > Thu Jan  1 12:00:00 CET 1970
$Id: sectionsd.cpp,v 1.261 2008/05/01 18:06:46 seife Exp $
[sectionsd] Caching max 6000 events
[sectionsd] Caching 14 days
[sectionsd] Caching 24 hours Extended Text
[sectionsd] Events are old 60min after their end time
/var/tuxbox/config/zapit/epgfilter.xml: No such file or directory
/var/tuxbox/config/mybouquets.xml: No such file or directory
[eitThread] pid 117 start
$Id: zapit.cpp,v 1.410 2008/04/25 21:23:23 houdini Exp $
[frontend] uncommitted_switch_mode 0
/tmp/currentservices.xml: No such file or directory
[camd] ca system id: 1722
$Id: controld.cpp,v 1.130 2008/01/03 11:09:27 seife Exp $

[controld] Boxtype detected: (1, Nokia D-BOX2)
[controld]: ROUTEVIDEO v1 = 5 a1 = 1 v2 = 1 a2 = 1 v3 = 0 a3 = 1 fblk=1
[controld] format: 4:3(LB)
[yhttpd] Webserver nhttpd/3.1.8 (yhttpd_core/1.2.0)
[LCDFONT] initializing core...
[LCDFONT] adding font /share/fonts/micron.ttf...OK (Micron/Regular)
[LCDFONT] adding font /share/fonts/micron_bold.ttf...OK (Micron/Bold)
[LCDFONT] adding font /share/fonts/pakenham.ttf...OK (Pakenham/Regular)
[LCDFONT] Intializing font cache...
[yhttpd] Webserver starting...
rdate: timeout connecting to time server
/bin/neutrino: /lib/libpng12.so.0: no version information available (required by /bin/neutrino)
starting /bin/neutrino
[neutrino] frameBuffer Instance created
812k video mem
[neutrino] Software update enabled
[neutrino] enable flash
[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
[CFSMounter] Mount(0) 10.42.43.1:/data/dbox -> /mnt/custom
[CFSMounter] Mount(0) 10.42.43.1:/data/dbox -> /mnt/filme
[neutrino] menue setup
imageinfo: JTG-Image [IDE] (2.2.7)
loading locales: scandir: No such file or directory
[neutrino] registering as event client
[neutrino] initialized everything
[controld] VIDEO_EVENT_SIZE_CHANGED 720x576 (4:3 -> 4:3)
login[143]: root login on 'pts/1'
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[LCDFONT] FTC_Face_Requester (Fix12/Regular)
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out

Auffallend ist schonmal, dass er den NTP-Server nicht erreichen kann. Das ist merkwürdig, denn der verwendete Zeit-Server geht (benutze ihn auf meinem anderen Server) und kann auch von der dbox aus angepingt werden. Aber das ist auch nicht das Problem, habe später die gleichen Tests nochmal ohne NTP gemacht, die Ergebnisse sind identisch ausser, dass im Log kein "rdate: timeout connecting to time server" mehr erscheint.

Ich habe die box dann mehrere Minuten so gelassen und es ist nichts mehr passiert. top zeigte keine Aktivität vom sectionsd:

Code: Alles auswählen

top - 12:04:26 up 4 min,  0 users,  load average: 0.35, 0.29, 0.13
Tasks:  41 total,   1 running,  40 sleeping,   0 stopped,   0 zombie
Cpu(s):   3.4% user,  20.1% system,   0.0% nice,  76.5% idle
Mem:     30732k total,    20576k used,    10156k free,     2936k buffers
Swap:        0k total,        0k used,        0k free,     8672k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  141 root       9   0  4468 3656 2468 S  0.0 11.9   0:12.86 neutrino
  144 root       9   0  4468 3656 2468 S  0.0 11.9   0:00.03 neutrino
  145 root       9   0  4468 3656 2468 S  0.6 11.9   0:00.91 neutrino
  153 root       9   0  4468 3656 2468 S  0.0 11.9   0:00.01 neutrino
  140 root       9   0  1772 1772 1356 S  0.0  5.8   0:00.00 nhttpd
  130 root       9   0  1444 1444 1136 S  0.0  4.7   0:00.79 zapit
  113 root       9   0  1360 1360 1144 S  0.0  4.4   0:00.07 sectionsd
  114 root       9   0  1360 1360 1144 S  0.0  4.4   0:00.01 sectionsd
  115 root       6   0  1360 1360 1144 S  0.0  4.4   0:00.02 sectionsd
  117 root       9   0  1360 1360 1144 S  0.0  4.4   0:00.00 sectionsd
  120 root       9   0  1360 1360 1144 S  0.0  4.4   0:00.00 sectionsd
  121 root       9   0  1360 1360 1144 S  0.0  4.4   0:00.00 sectionsd
  122 root       9   0  1360 1360 1144 S  0.0  4.4   0:00.01 sectionsd
  123 root       9   0  1360 1360 1144 S  0.0  4.4   0:00.00 sectionsd
  136 root       9   0  1188 1188 1024 S  0.0  3.9   0:00.09 controld
  138 root       9   0  1188 1188 1024 S  0.0  3.9   0:00.00 controld
  139 root       9   0  1188 1188 1024 S  0.0  3.9   0:00.00 controld

Nach ein paar Minuten habe ich dann einfach auf EinsPlus umgeschaltet, ohne irgendwas anderes zu machen. sectionsd fing an zu arbeiten:

Code: Alles auswählen

top - 23:39:21 up 6 min,  0 users,  load average: 0.72, 0.39, 0.17
Tasks:  41 total,   2 running,  39 sleeping,   0 stopped,   0 zombie
Cpu(s):  68.4% user,  31.6% system,   0.0% nice,   0.0% idle
Mem:     30732k total,    22840k used,     7892k free,     2936k buffers
Swap:        0k total,        0k used,        0k free,     8676k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  122 root       9   0  4344 4344 1272 S  0.0 14.1   0:00.15 sectionsd
  123 root       9   0  4344 4344 1272 S  0.0 14.1   0:00.46 sectionsd
  113 root       9   0  4340 4340 1272 S  0.0 14.1   0:00.07 sectionsd
  114 root       9   0  4340 4340 1272 S  0.0 14.1   0:00.01 sectionsd
  115 root       8   0  4340 4340 1272 S  0.0 14.1   0:00.03 sectionsd
  117 root      20   0  4340 4340 1272 R 94.8 14.1   0:25.04 sectionsd
  120 root       9   0  4340 4340 1272 S  0.0 14.1   0:00.00 sectionsd
  121 root       9   0  4340 4340 1272 S  0.0 14.1   0:00.00 sectionsd
  141 root       9   0  4480 3668 2476 S  0.0 11.9   0:13.43 neutrino
  144 root       9   0  4480 3668 2476 S  0.0 11.9   0:00.03 neutrino
  145 root       9   0  4480 3668 2476 S  0.7 11.9   0:01.34 neutrino
  153 root       9   0  4480 3668 2476 S  0.0 11.9   0:00.01 neutrino
  140 root       9   0  1772 1772 1356 S  0.0  5.8   0:00.00 nhttpd
  130 root       9   0  1448 1448 1140 S  0.0  4.7   0:00.91 zapit
  124 root       9   0  1204 1204 1004 S  0.0  3.9   0:00.20 timerd
  127 root       9   0  1204 1204 1004 S  0.0  3.9   0:00.00 timerd
  128 root       9   0  1204 1204 1004 S  0.0  3.9   0:02.11 timerd

Die einzigen Logausgaben bis sich sectionsd wieder beruhigt hatte waren:

Code: Alles auswählen

[timeThread] - 25.07.2008 23:38:46, tim: Fri Jul 25 23:38:46 2008
[timeThread] Time set via DVB, going to sleep for 1800 seconds.
[controld] VIDEO_EVENT_SIZE_CHANGED 720x576 (4:3 -> 16:9)
21:39:02.102 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:05.190 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:08.169 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:11.263 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:14.022 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:17.096 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:20.311 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:23.105 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:27.753 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:31.306 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:34.696 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:38.123 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:41.206 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:48.441 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:39:51.313 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0

und wie man am Speicherbedarf sehen kann, hat er einige events gesammelt:

Code: Alles auswählen

top - 23:41:16 up 8 min,  0 users,  load average: 0.41, 0.43, 0.21
Tasks:  41 total,   1 running,  40 sleeping,   0 stopped,   0 zombie
Cpu(s):   2.5% user,  15.0% system,   0.0% nice,  82.6% idle
Mem:     30732k total,    23444k used,     7288k free,     2936k buffers
Swap:        0k total,        0k used,        0k free,     8676k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  113 root       9   0  5328 5328 1272 S  0.0 17.3   0:00.14 sectionsd
  114 root       9   0  5328 5328 1272 S  0.0 17.3   0:00.01 sectionsd
  115 root       8   0  5328 5328 1272 S  0.0 17.3   0:00.03 sectionsd
  117 root       9   0  5328 5328 1272 S  0.0 17.3   0:59.03 sectionsd
  120 root       9   0  5328 5328 1272 S  0.0 17.3   0:00.00 sectionsd
  121 root       9   0  5328 5328 1272 S  0.0 17.3   0:00.00 sectionsd
  122 root       9   0  5328 5328 1272 S  0.0 17.3   0:00.15 sectionsd
  123 root       9   0  5328 5328 1272 S  0.0 17.3   0:00.46 sectionsd
  141 root       9   0  4480 3668 2476 S  0.0 11.9   0:13.45 neutrino
  144 root       9   0  4480 3668 2476 S  0.0 11.9   0:00.03 neutrino
  145 root       9   0  4480 3668 2476 S  0.4 11.9   0:01.87 neutrino
  153 root       9   0  4480 3668 2476 S  0.0 11.9   0:00.01 neutrino
  140 root       9   0  1772 1772 1356 S  0.0  5.8   0:00.00 nhttpd
  130 root       9   0  1448 1448 1140 S  0.0  4.7   0:00.91 zapit
  124 root       9   0  1204 1204 1004 S  0.0  3.9   0:00.20 timerd
  127 root       9   0  1204 1204 1004 S  0.0  3.9   0:00.00 timerd
  128 root       9   0  1204 1204 1004 S  0.0  3.9   0:02.11 timerd

Nun habe ich wieder ohne was anderes zu tun auf MDR umgeschaltet, und siehe da, nun wurden auch auf MDR events gesammelt:

Code: Alles auswählen

top - 23:41:59 up 8 min,  0 users,  load average: 0.54, 0.45, 0.22
Tasks:  41 total,   2 running,  39 sleeping,   0 stopped,   0 zombie
Cpu(s):  74.5% user,  25.2% system,   0.0% nice,   0.3% idle
Mem:     30732k total,    23860k used,     6872k free,     2936k buffers
Swap:        0k total,        0k used,        0k free,     8680k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  113 root       9   0  5352 5352 1272 S  0.0 17.4   0:00.19 sectionsd
  114 root       9   0  5352 5352 1272 S  0.0 17.4   0:00.01 sectionsd
  115 root       8   0  5352 5352 1272 S  0.0 17.4   0:00.03 sectionsd
  117 root      14   0  5352 5352 1272 R 92.8 17.4   1:05.57 sectionsd
  120 root       9   0  5352 5352 1272 S  0.0 17.4   0:00.00 sectionsd
  121 root       9   0  5352 5352 1272 S  0.0 17.4   0:00.00 sectionsd
  122 root       9   0  5352 5352 1272 S  0.0 17.4   0:00.15 sectionsd
  123 root       9   0  5352 5352 1272 S  0.0 17.4   0:00.46 sectionsd
  141 root       9   0  4500 3688 2484 S 16.5 12.0   0:14.32 neutrino
  144 root       9   0  4500 3688 2484 S  0.0 12.0   0:00.03 neutrino
  145 root       9   0  4500 3688 2484 S  0.4 12.0   0:01.99 neutrino
  153 root       9   0  4500 3688 2484 S  0.0 12.0   0:00.01 neutrino
  140 root       9   0  1772 1772 1356 S  0.0  5.8   0:00.00 nhttpd
  130 root       9   0  1448 1448 1140 S  2.1  4.7   0:01.02 zapit
  124 root       9   0  1204 1204 1004 S  0.0  3.9   0:00.20 timerd
  127 root       9   0  1204 1204 1004 S  0.0  3.9   0:00.00 timerd
  128 root       9   0  1204 1204 1004 S  0.0  3.9   0:02.11 timerd

Nachdem er "fertig" war, hatte er auch einen größeren Speicherverbrauch (18.1%), hatte also wirklich weitere Events gesammelt. Im Log stand folgendes:

Code: Alles auswählen

~ > [controld] VIDEO_EVENT_SIZE_CHANGED 720x576 (16:9 -> 4:3)
21:41:58.716 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[3] filter 0x50 mask 0xf0
21:42:05.067 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[3] filter 0x50 mask 0xf0
21:42:10.505 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[3] filter 0x50 mask 0xf0
21:42:20.992 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[3] filter 0x50 mask 0xf0
21:42:31.800 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[3] filter 0x50 mask 0xf0
21:42:48.430 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:42:55.747 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0
21:43:06.677 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x60 mask 0xf0

Dieses Verhalten ist hier bei mir jederzeit zu 100% reproduzierbar. Ich habe das ganze dann auch noch mit dem neuesten sectionsd probiert. Ergebnis das gleiche. Die Logs dazu sahen folgendermaßen aus:

Start auf MDR:

Code: Alles auswählen

~/bin > ./sectionsd
$Id: sectionsd.cpp,v 1.264 2008/06/23 09:27:47 seife Exp $
[sectionsd] Caching max 6000 events
[sectionsd] Caching 14 days
[sectionsd] Caching 24 hours Extended Text
[sectionsd] Events are old 60min after their end time
/var/tuxbox/config/zapit/epgfilter.xml: No such file or directory
/var/tuxbox/config/mybouquets.xml: No such file or directory
~/bin > rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server
[sectionsd] getUTC: read: Connection timed out
rdate: timeout connecting to time server

Start auf EinsPlus:

Code: Alles auswählen

~/bin > ./sectionsd
$Id: sectionsd.cpp,v 1.264 2008/06/23 09:27:47 seife Exp $
[sectionsd] Caching max 6000 events
[sectionsd] Caching 14 days
[sectionsd] Caching 24 hours Extended Text
[sectionsd] Events are old 60min after their end time
/var/tuxbox/config/zapit/epgfilter.xml: No such file or directory
/var/tuxbox/config/mybouquets.xml: No such file or directory
~/bin > rdate: timeout connecting to time server
[timeThread] - 25.07.2008 23:49:16, tim: Fri Jul 25 23:49:16 2008
[timeThread] Time set via DVB, going to sleep for 1800 seconds.
23:49:16.018 dmxSDT: going to sleep...
23:49:18.206 changeDMX [EIT]-> 1 (0x4f/0xff) other transport stream, now/next (2 seconds)
23:49:41.178 changeDMX [EIT]-> 2 (0x50/0xff) actual transport stream, scheduled (23 seconds)
23:49:52.147 dmxCN: going to sleep...
23:49:52.152 eit_set_update_filter, servicekey = 0x0, current version 0
[sectionsd] Request of current/next information for      41ba4017033
(*currentEvt).service_id != 0: 7033, flag: 0x0
*nextEvt not from cur/next V1!
(*nextEvt).service_id != 0: 7033, flag: 0x5
currentEvt: 'Panda, Gorilla & Co.' (0389) nextEvt: 'Wilhelma-Geschichten' (038b) flag: 0x15
[sectionsd] Request of current/next information for      41ba4017033
(*currentEvt).service_id != 0: 7033, flag: 0x0
*nextEvt not from cur/next V1!
(*nextEvt).service_id != 0: 7033, flag: 0x5
currentEvt: 'Wilhelma-Geschichten' (038b) nextEvt: 'Wilhelma-Geschichten' (038d) flag: 0x15
23:50:18.586 changeDMX [EIT]-> 3 (0x50/0xf0) actual transport stream, scheduled2 (37 seconds)
23:50:44.820 changeDMX [EIT]-> 4 (0x60/0xf1) other transport stream, scheduled 1/2 (26 seconds)
23:50:47.811 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[4] filter 0x60 mask 0xf1
23:50:51.644 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[4] filter 0x60 mask 0xf1
23:50:55.800 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[4] filter 0x60 mask 0xf1
23:50:59.758 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[4] filter 0x60 mask 0xf1
23:51:04.605 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[4] filter 0x60 mask 0xf1
23:51:15.508 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[4] filter 0x60 mask 0xf1
23:51:25.567 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[4] filter 0x60 mask 0xf1
23:51:52.083 changeDMX [EIT]-> 5 (0x61/0xf1) other transport stream, scheduled 2/2 (68 seconds)
23:52:04.158 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x61 mask 0xf1
23:52:18.454 [sectionsd] DMX::readNbytes received POLLERR, pid 0x12, filter[5] filter 0x61 mask 0xf1

Könnte es vielleicht sein, dass bei mir der MDR keine Zeitstempel sendet und der sectionsd ohne Zeit einfach nicht arbeitet? Aber warum klappt das mit dem NTP nicht, er ist erreichbar und funktioniert auch, nur anscheinend nicht mit der dbox?!?

Sorry für diesen ultralangen Post, aber ich weiß nicht, wie ich mich kürzer fassen soll. Ich hoffe, jemand kann was erkennen. Aber da er ja beim Start auf MDR praktisch nichts logged, ist das wohl eher etwas schwierig. Wenn ich noch mit weiteren Infos dienen kann, fragt einfach.

cu und Danke für die Mühe

[DrStoned]

NTP geht nur, wenn die Box über eine Internetverbindung verfügt. Da wird die Uhrzeit von einem Zeitserver im Internet geholt. Als NTP-Server time.fu-berlin.de eintragen. Ansonsten DVB auswählen.

Greetz von DrStoned

[MacFco]

rdate: timeout connecting to time server
Aber warum klappt das mit dem NTP nicht, er ist erreichbar und funktioniert auch, nur anscheinend nicht mit der dbox?!?

rdate synchronisiert die Zeit über den TCP-time-Port 37, anstatt über den UDP-ntp-Port 123.
Wenn der eingestellte NTP-Server den Zeitabgleich über Port 37 nicht unterstützt, gibt es
obige timeout-Meldung. Proxxy/Firewall dazwischen, bei denen Port 37 gesperrt ist, wäre
auch noch eine Möglichkeit, falls time.fu-berlin.de schon eingetragen ist. Ansonsten, wie
DrStoned schon schreibt, DVB wählen.

[Tommy]

AFAIK ist DVB ist immer aktiv als Fallback. Bei Weinleiche scheint aber die Zeit auf MDR tatsächlich über DVB nicht verfügbar zu sein. Das der sectionsd ohne aktuelle Zeit nix macht ist aber schon irgendwie logisch. Keine Zeit oder Zeit = 0 heißt ja unter Linux 1.1.1970, 00:00:00. Is gibt im EPG sicher keine Events mit diesem Datum.

Falls Du das rdate/ntp Problem nicht gefixt kriegst und Deine Box <> Philips ist wäre evtl. eine RTC für Dich interessant. Da gibts dann solche Probleme nicht mehr.

[amiga23]

Ja das ganze ist etwas verwirrend, vielleicht sollte jemand das in Neutrino umbenennen.
Es wird nicht das Network Time Protocol nach RFC 958 http://www.faqs.org/rfcs/rfc958.html sondern das ältere Time Protocol nach RFC 868 http://www.faqs.org/rfcs/rfc868.html verwendet. Daher muss der Server das auch unterstützen. Ein reiner NTP Server funktioniert nicht.

[weinleiche]

Hey cool, danke für die Tipps. Nun geht es auch wieder mit MDR und Konsorten!

Ich habe natürlich eine permanente Internetverbindung, deswegen hatte ich ja NTP der DVB Zeitgabe vorgezogen. Und ausserdem läuft bei mir zu Hause auf dem Server auch noch ein NTP Server. Aber eben keiner mit Time Protocol nach RFC 868. Muss einem ja auch gesagt werden

Habe bisher immer ntps1-0.cs.tu-berlin.de oder de.pool.ntp.org verwendet. Scheinen aber beide nicht das alte Protokoll zu unterstützen.

Interessant wäre jetzt nur noch, warum über den MDR keine DVB-Zeit kommt. Naja, habe die DVB-Zeit auch noch aus BetaNova Zeiten in schlechter Erinnerung. Egal, für mich ist das Problem gelöst, und auch der sectionsd hat diesbezüglich keinen Fehler.

Danke nochmal.

[rhabarber1848]

Interessant wäre jetzt nur noch, warum über den MDR keine DVB-Zeit kommt.

Hi,

ich habe das gerade mal getestet. Beim Einschalten kommt MDR Sachsen, den NTP-Server habe
ich so verbogen, dass eine Fehlermeldung beim Booten der Box kommt:

rdate: bad address 'router2'

Dennoch findet sectionsd (try2) die Uhrzeit:

[timeThread] - 26.07.2008 11:59:15, tim: Sat Jul 26 11:59:15 2008
[timeThread] Time set via DVB, going to sleep for 18000 seconds.

und der MDR-EPG ist da, ebenso wie für alle anderen ARD/ZDF-Sender, ohne Umschalten.

[flasher]

Ich habe schon seit Stunden Probleme mit dem EPG bei VIVA, Comedy Central und MTV.
Bei Viva oder Comedy Central ist es so, das wenn man umschaltet den richtigen current/next Event angezeigt bekommt.
Nach 2-3 Sekunden springt die Anzeige aber auf einen current-Event zurück der um 10.00 beginnt und einen next-Event um 14:00.
Bei MTV ist es schon den ganzen Tag, das nur zwei Events 10:00/14:00 angezeigt werden.

Zur Zeit sieht das auf Viva so aus: 27.07.08 - 00:50:00h

Beim Umschalten:
00:00 Loveline
01:00 Money Express

Zwei Sekunden später
10:00 Viva Spezial
14:00 Abschlussklasse 2004

Die Events scheinen also erst einmal richtig gelesen und angezeigt werden. Abgesehen vom MTV EPG.
Liegt das nun an dem letzten Patch oder an MTV, VIVA, Comedy Central. Die drei sind ja bekanntlich eine Senderfamilie.

Gruß

[PauleFoul]

@ Seife

Also bei mir wird bei der Version sectionsd-1.264-current-next-try2.gz auf ARD und ZDF nur das "Now&Next" Event angezeigt.
Keine Ahnung warum mit dem aktuellen geht alles. Könnte es an meinem EPG-Filter liegen?

Code: Alles auswählen

<?xml version="1.0" encoding="UTF-8"?>
<epgfilter is_whitelist = "0" except_current_next = "1">
    <filter name="" onid="0001" tsid="0445" serviceID="0000"/> 
    <filter name="" onid="0085" tsid="0001" serviceID="0000"/>
    <filter name="" onid="f001" tsid="2717" serviceID="0000"/>
    <filter name="" onid="0085" tsid="0004" serviceID="0000"/>
    <filter name="3Sat" onid="0001" tsid="0437" serviceID="6d67"/>
    <filter name="KiKa" onid="0001" tsid="0437" serviceID="6d68"/>
    <filter name="ZDFinfokanal" onid="0001" tsid="0437" serviceID="6d6b"/>
    <filter name="DKULTUR" onid="0001" tsid="0437" serviceID="6d6c"/>
    <filter name="DLF" onid="0001" tsid="0437" serviceID="6d6d"/>
    <filter name="ZDFdokukanal" onid="0001" tsid="0437" serviceID="6d6e"/>
    <filter name="ZDFtheaterkanal" onid="0001" tsid="0437" serviceID="6d70"/>
    <filter name="" onid="0001" tsid="044d" serviceID="6dcb"/>
    <filter name="hr-fernsehen" onid="0001" tsid="044d" serviceID="6dcc"/>
    <filter name="arte" onid="0001" tsid="044d" serviceID="6dcd"/>
    <filter name="" onid="0001" tsid="044d" serviceID="6dcf"/>
    <filter name="BR-alpha*" onid="0001" tsid="044d" serviceID="6dd0"/>
    <filter name="SWR Fernsehen BW" onid="0001" tsid="044d" serviceID="6dd1"/>
    <filter name="Phoenix" onid="0001" tsid="044d" serviceID="6dd2"/>
    <filter name="P_60ER" onid="0085" tsid="0004" serviceID="0091"/>
    <filter name="P_DINNER_PARTY" onid="0085" tsid="0004" serviceID="0092"/>
    <filter name="P_KLASSIK" onid="0085" tsid="0004" serviceID="0093"/>
    <filter name="P_JAZZ" onid="0085" tsid="0004" serviceID="0094"/>
    <filter name="P_COUNTRY" onid="0085" tsid="0004" serviceID="0095"/>
    <filter name="P_UK_HITS" onid="0085" tsid="0004" serviceID="0096"/>
	 <filter name="P_DEUTSCHE_CHARTS" onid="0085" tsid="0004" serviceID="0097"/>
	 <filter name="P_HARD_ROCK" onid="0085" tsid="0004" serviceID="0098"/>
	 <filter name="P_SOUL_CLASSICS" onid="0085" tsid="0004" serviceID="0099"/>
	 <filter name="P_ROCK_N_ROLL" onid="0085" tsid="0004" serviceID="009a"/>
	 <filter name="P_CLASSIC_ROCK" onid="0085" tsid="0004" serviceID="009b"/>
	 <filter name="P_LOVE_SONGS" onid="0085" tsid="0004" serviceID="009c"/>
	 <filter name="P_REGGAE" onid="0085" tsid="0004" serviceID="009d"/>
	 <filter name="P_ALTERNATIVE_ROCK" onid="0085" tsid="0004" serviceID="009e"/>
	 <filter name="P_R_B_HIP_HOP" onid="0085" tsid="0004" serviceID="009f"/>
	 <filter name="P_SCHLAGER" onid="0085" tsid="0004" serviceID="00a2"/>
	 <filter name="P_ROCK_HYMNEN" onid="0085" tsid="0004" serviceID="00a3"/>
	 <filter name="P_90ER" onid="0085" tsid="0004" serviceID="00a4"/>
	 <filter name="P_DANCE" onid="0085" tsid="0004" serviceID="00a5"/>
	 <filter name="P_70ER" onid="0085" tsid="0004" serviceID="00a6"/>
	 <filter name="P_80ER" onid="0085" tsid="0004" serviceID="00a7"/>
	 <filter name="RTL Shop" onid="0001" tsid="0441" serviceID="2f30"/>
	 <filter name="n-tv" onid="0001" tsid="0441" serviceID="2f3a"/>
	 <filter name="EuroNews" onid="0001" tsid="0441" serviceID="79f4"/>
	 <filter name="9 Live" onid="0001" tsid="0453" serviceID="4460"/>
	 <filter name="N24" onid="0001" tsid="0453" serviceID="445f"/>
	 <filter name="PREMIERE SERIE" onid="0085" tsid="0002" serviceID="0010"/>
	 <filter name="PREMIERE KRIMI" onid="0085" tsid="0002" serviceID="0017"/>
	 <filter name="PREMIERE FILMFEST" onid="0085" tsid="0003" serviceID="0014"/>
	 <filter name="PREMIERE FILMCLASSICS" onid="0085" tsid="0003" serviceID="0029"/>
	 <filter name="PREMIERE NOSTALGIE" onid="0085" tsid="0003" serviceID="0204"/>
	 <filter name="CLASSICA" onid="0085" tsid="0011" serviceID="0018"/>
	 <filter name="FOCUS GESUNDHEIT" onid="0085" tsid="0011" serviceID="000f"/>
	 <filter name="ANIMAL PLANET" onid="0085" tsid="0011" serviceID="000c"/>
	 <filter name="DISCOVERY GESCHICHTE" onid="0085" tsid="0011" serviceID="000d"/>
	 <filter name="JUNIOR" onid="0085" tsid="0011" serviceID="0013"/>
	 <filter name="JETIX" onid="0085" tsid="0011" serviceID="001c"/>
	 <filter name="CLASSICA" onid="0085" tsid="0011" serviceID="0018"/>
	 <filter name="DISNEY CHANNEL" onid="0085" tsid="0011" serviceID="0022"/>
</epgfilter>

Gruß
____Paule

[GetAway]

@seife,

erstmal schönen Urlaub, vll ließt du ja mit.

Folgendes Szenario ist mir aufgefallen und klingt unplausible.
Ich schalte z.B. morgens auf den Transponder von ARD. Es werden schön Events
gesammelt, für ca. 6 Tage, genau gesagt, in diesem Fall bis zum 4.8.

Wenn ich dann irgendwann, z.B. auf den Tranponder wechsle auf dem Premiere läuft
und mir nach ca. 8 Stunden in der EPG-Vorschau die gesammelten Events von ARD nochmal anschaue,
habe ich nur noch Einträge bis zum bis 30.7. Es werden also die ältesten und die, die am
weitesten in der Zukunft liegen scheinbar gelöscht! Klingt irgendwie unlogisch, dazu kommt noch
das die Anzahl der max. Events niemals meine eingestellten 6000 erreicht hatten.

Jetzt das unglaubliche. Schau ich mir die EPG vom aktuellen Sender an und direkt danach
die EPG-Vorschau von ARD, sind alle Events wieder da. Sie sind also nur temporär nicht sichtbar.
Wie gesagt, ich habe während dieser Prozedur weder den Kanal noch den Tranponder gewechselt,
sie konnten also nicht wieder neu eingelesen werden.

Wenn man lange genug wartet geht es sogar soweit, das nur noch das NOW und das Next-Event zu sehen ist.
Desweiteren bestätigen Aussagen in diversen Foren, wie "EPG's werden vergessen" meine Beobachtung.

Die Frage lautet nun, warum werden nicht immer alle eingelesenen Events angezeigt?

So nun weiterhin Viel Spaß im Urlaub.