sectionsd stopt nicht bei der Aufnahme

[MPC823]

Ich habe mir mit newmake ein Snapshot Image gebaut (Stand 08.06.2008). Beim Abspielen der Testaufnahmen hat es endlos geruckelt. Alte Aufnahmen aber nicht. Also Aufnahme Fehlerhaft.

Ich habe dann die ARD via Eutelsat und Astra Aufgezeichnet. Eutelsat Aufnahmen waren Tadellos die auf Astra fehlerhaft.

Unterscjeid ist ja das auf dem Eutelsat die EPG Infos fehlen. Also habe ich den Sectionsd mal von Hand gekillt und siehe da Aufnahmen auf dem Astra waren auch okay.

Bei den Einstellungen habe ich Sectionsd Anhalten gewählt. Im Neutrino config file /var/tuxbox/config/neutrino.conf steht da auch so drin. "recording_stopsectionsd = true" nur scheint das nicht (mehr) zu funktionieren.

Ich bin mir nun auch nicht ganz sicher ob der Sectionsd nun angehalten gestoppt oder nur schlafen gelegt werden soll mit der Einstellung.

Mit "top" in der Konsole ist der sectionsd sichtbar und schläft. Die Box ist aber auf Eutelsat (ohne EPG Daten nicht träge) und auf Astra mit EPG unsagbar träge abgesehen davon das die Aufnahme nicht abzubrechen ist. Mit viel Gedult und endlosem warten geht mal das Menü auf und wenn dann "stop" gewählt wird passiert nix.

Kann jemand das auch bestätigen

Gruss Martin

[seife]

Kernel 2.4 oder Kernel 2.6?
hw_sections an oder aus?

[MPC823]

Also Version : Linux version 2.4.36.2-dbox2 (martin@MacMini)

die Box ist eine Avia 600 und für den Ucode habe ich mal rumprobiert.

im Augenblich ist der buildin für den GTX und der vb017 für den avia600 aktiv

HW-Sections aus
Avia Watchdog aus
Enx Watchdog aus


Ein serielles Kabel muss ich erst noch anschliessen vielicht sieht man da ja etwas mehr.

Gruss Martin

[seife]

Hm. Wenn hw_sections aus ist, dann weiss ich nicht, woran es liegen könnte.
Und wenn du mit den ucodes experimentiert hast, dann hast du ja auch rebootet (ein beliebter Fehler ist, hw_sections umzuschalten, aber nicht neu zu booten) => ich weiss nicht, was es ist.

[MPC823]

[controld] VIDEO_EVENT_SIZE_CHANGED 704x576 (16:9 -> 16:9)
[LCDFONT] FTC_Face_Requester (Fix12/Regular)
[neutrino] no file /var/tuxbox/config/recording.start was found
no response from sectionsd
Record channel_id: 3c8c013e025e epg: 0, apids 0x0 mode 1
no response from sectionsd
no response from sectionsd
[stream2file]: using 40 ringbuffers
no response from sectionsd
Stop
record time: 22
[mi] saveXml: /hdd/ARD__Das_Erste___2008-06-14_150839.xml

[neutrino] no file /var/tuxbox/config/recording.end was found
[stream2file]: pthreads exit code: 1
13:09:29.270 dmxCN: waking up again - requested from .change()
SPTS, queue 0 extended.

13:09:30.610 dmxCN: going to sleep...
13:09:30.611 eit_set_update_filter, servicekey = 0x44d00016dca, current version 31

[controld] VIDEO_EVENT_SIZE_CHANGED 720x576 (16:9 -> 16:9)
[neutrino] no file /var/tuxbox/config/recording.start was found
Record channel_id: 44d00016dca epg: 44d00016dcae768, apids 0x0 mode 1
fsk:0, Genre:16, Dauer: 90

[stream2file]: using 40 ringbuffers
avia_gt_dmx: queue 0 overflow (count: 2)

avia_gt_dmx: queue 0 overflow (count: 2)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 0 overflow (count: 2)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 4 overflow (count: 1)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 0 overflow (count: 1)

avia_gt_dmx: queue 0 o

Das bringt der Log und die Aufnahme wird mit EPG nicht beendet

Gruss Martin

[MPC823]

Also ich habe mal in der neutrino.cpp die Funktion

"bool CNeutrinoApp::doGuiRecord(char * preselectedDir, bool addTimer)"

gefunden. Ich denke das müsste die eigentliche Aufnahmefunktion sein. Nur sehe ich dort nirgends einen Code der den sectionsd beendet & startet .

Kann es sein das dies normal von dem NEUTRINO_RECORDING_START_SCRIPT erledigt werden sollte ?

Gruss Martin

[Houdini]

du weiss aber schon, daß ARD auf Astra ca. 40-50% mehr Datenrate hat als auf HB!

[Tommy]

eigentlich sollte es automatisch gehen - kanns aber in den scripten mal hiermit experimentieren:

Code: Alles auswählen

/var # sectionsdcontrol
usage:  sectionsdcontrol --pause         stop sectionsd
        sectionsdcontrol --nopause       restart sectionsd
        sectionsdcontrol --state         get sectionsd runstate
        sectionsdcontrol --wepg <epgdir> write epgfiles to dir
        sectionsdcontrol --repg <epgdir> read epgfiles from dir
        sectionsdcontrol --freemem       unloads all events
        sectionsdcontrol --restart       restart sectionsd

wobei lt. seife nach einem restart/start immer neutrino neu gestartet werden sollte

[seife]

Der sectionsd wird nicht gestoppt, er wird nur in den pause-Modus versetzt.
Ich habe hier bei mir einen Patch, der sectionsd vor Aufnahmestart neu startet, aber das ist nicht ganz trivial, weil da noch an anderen Stellen Zeugs geändert werden muss, damit z.B. wenn die Aufnahme zwischendurch abbricht und neu gestartet wird, ein gültiger EPG-Titel da ist etc.

Irgendwann säuber ich den mal, dann kann er ins CVS.

[MPC823]

@Houdini
Ähm so direkt bewusst war ich mir da eben nicht.

ARD Hotbird Bitrate :Aktuell 3664, niedrigst 3456, höchste 3666. [kbit/s]
ARD Astra Bitrate :Aktuell 6898, niedrigst 5108, höchste 6904. [kbit/s]

Das ist ja aber nicht das Problem, da ich den sectionsd auch auf Astra gekillt habe und dann war die Aufnahme ja OKay. Es ist so eben einfacher gewesen ohne EPG aufzunehmen. Man sieht daraus ja auch das der secionsd nur Probleme macht wenn er "nicht schläft" bzw wenn EPG Daten kommen scheint er ja irgendwie doch nicht zu schlafen.

Evt hilft das ja auch bei der Fehlereingrenzung.

@Tommy
Das mit den scripten werde ich mal probieren aber das wäre ja ein "würkaround" da es ja normal gehen sollte. Danke für die Befehle die hatte ich schon gesucht

@Seife Das wäre natürlich nicht schlecht wenn das denne mal drin ist. Fraglich ist nur warum er sich bei mir nicht schlafen legt bzw die Aufnahme stört, obwohl er pausen soll.

Wenn man so schaut wieviel Probleme der Sectionsd macht ist es schon verwunderlich das den nicht mal schon jemand "ganz" ausversehen komplett mit allen sourcen auf dem Planet gelöscht hat


Gruss Martin

[MPC823]

Mit den Befehlen von Tommy (die ich nicht kannte) habe ich den sectionsd mal schlafen gelegt. (Thanks Tommy )

Mit Top sieht man aber das einer der Daemons (vermutlich genannt) rennt

Mem: 28052K used, 2832K free, 0K shrd, 308K buff, 11536K cached
Load average: 1.49 1.12 0.51
PID PPID USER STAT VSZ %MEM COMMAND
155 1 root S 64568 209% sectionsd
156 155 root S 64568 209% sectionsd
158 156 root S 64568 209% sectionsd
159 156 root R 64568 209% sectionsd
160 156 root S 64568 209% sectionsd
161 156 root S 64568 209% sectionsd
162 156 root S 64568 209% sectionsd
163 156 root S 64568 209% sectionsd
164 156 root S 64568 209% sectionsd
193 138 root S 51472 167% neutrino -f -u

Weiss jetz nicht ob das so sein darf.

Was auch noch zu beobachten ist das nun die Aufnahme auf ARD Asta (mit EPG) arbeitet fehlerfrei . ->aufnehmen geht nun und beendet werden kann die Aufnahme nun auch ohne das die Box zäh wird.

Das hieße ja das die Aufnahme den sectionsd wohl nicht sauber "schlafen" legt.

Gruss Martin

[seife]

Mit den Befehlen von Tommy

mit welchem denn genau?

(die ich nicht kannte) habe ich den sectionsd mal schlafen gelegt. (Thanks Tommy )

Mit Top sieht man aber das einer der Daemons (vermutlich genannt) rennt

Mem: 28052K used, 2832K free, 0K shrd, 308K buff, 11536K cached
Load average: 1.49 1.12 0.51
PID PPID USER STAT VSZ %MEM COMMAND
155 1 root S 64568 209% sectionsd
156 155 root S 64568 209% sectionsd
158 156 root S 64568 209% sectionsd
159 156 root R 64568 209% sectionsd
160 156 root S 64568 209% sectionsd
161 156 root S 64568 209% sectionsd
162 156 root S 64568 209% sectionsd
163 156 root S 64568 209% sectionsd
164 156 root S 64568 209% sectionsd
193 138 root S 51472 167% neutrino -f -u

Weiss jetz nicht ob das so sein darf.

ja, das darf schon sein. Der sectionsd läuft ja noch (antwortet z.B. auf Anfragen der GUI), er liest nur kein EPG mehr neu ein.

Zumindest dann, wenn du ihn mit "--pause" angehalten hast.

[MPC823]

Mit "sectionsdcontrol --pause" scheint es zu funktionieren.


Gruss Martin

[seife]

Na gut. Das müsste neutrino auch machen, wenn du "Sectionsd anhalten" angemacht hast.

Du kannst ja mal während der Aufnahme mal mit "sectionsdcontrol --state" prüfen, ob das gemacht wird.
Schalte auch mal "sectionsd anhalten" aus, evtl. ist ja die Logik nur falschrum

[Tommy]

Mit den Befehlen von Tommy (die ich nicht kannte) habe ich den sectionsd mal schlafen gelegt. (Thanks Tommy )

Sind nich meine Befehle - wenn Du sectionsdcontrol an der Konsole ohne Parameter startest spuckt er die aus (wie jedes ordentliche Linux Programm)

[MPC823]

@Tommy, stimmt habe es gleich probiert .


Ich habe nun mal folgendes gemacht.

Zwei scripte angelegt in das entsprechende Verzeichnis.
recording.start mit sectionsdcontrol --pause und recording.end mit sectionsdcontrol --nopause

Nehme ich nun auf werden die scripte ausgeführt aber die Aufnahme ist immer noch Essig.

Rufe ich vor der Aufnahme das recording.start script auf und nehme dann auf (ich weiss dann wird das script nochmals aufgerufen machtb aber nix) dann geht es immer noch nicht.

Ein fehlerfreie Aufnahme bekomme ich nur wenn ich den Aufruf "sectionscontrol --pause" vor der Aufnahme in der Konsole mache.

Selbst der schlafende Daemon schein einem den doppelten Aufruf krumm zu nehmen und behindert die Aufnahme.

Ich würde sagen das weisst auf ein timing Problem hin das die Aufnahme beginnt bevor der sectiond auch wirklich schläft bzw einen Befehl --pause verarbeitet hat.

Alos irgendwo ist da mächtig ein "käfer" drinne

Nachtrag :

Also nun habe ich auf einmal wieder Fehler bei der Aufnahme mit EPG Daten auch wenn ich den sectionsd vorher schlafen lege in der Konsole oder per script. War wohl Zufall das es einmal ging.

Was aber definitiv reproduzierbar ist, ohne sectionsd funktioniert die Aufnahme auch auf Astra
Wenn ich den sectionsd in der Konsole schlafen schicke Aufnehme und beende danach den status nochmal abfrage läuft er wieder was darauf hinweisst das die Aufnahme beim beenden den Sectionsd wieder aufweckt.


Gruss Martin

[misama73]

wobei lt. seife nach einem restart/start immer neutrino neu gestartet werden sollte

Wie kann man eigentlich Neutrino via script neustarten?

Edit:

Ich hab es jetzt mit der FB-Emulation hinbekommen.

Code: Alles auswählen

wget -q -Y off -O - 'http://localhost/control/rcem?KEY_SETUP'
wget -q -Y off -O - 'http://localhost/control/rcem?KEY_7'
wget -q -Y off -O - 'http://localhost/control/rcem?KEY_3'

Ist zwar "von hinten durch die Brust ins Auge", aber es funktioniert.



MfG Michael

[MPC823]

in der /var/etc/init.d/start_neutrino

steht die Zeile

"until neutrino -f -u ; do"

und ich denke mit "neutrino -f -u" wird die GUI gestartet. Wenn nicht bitte berichtigen.


Gruss Martin

[bellum]

Das bringt der Log und die Aufnahme wird mit EPG nicht beendet

Ich weiß nicht ob es damit etwas zu tun hat, aber mit dem neuen sectionsd bekomme ich bei einer Aufnahme folgende Meldungen im Log (man achte auf die Timestamps) und hatte schon öfters das Problem, dass die Aufnahme nicht beendet wird und ewig weiterläuft.

Code: Alles auswählen

19:17:28.610 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:28.640 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:28.670 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:28.710 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:28.740 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:28.770 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:28.812 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:28.840 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:28.870 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:28.900 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:28.930 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:28.960 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:28.990 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:29.020 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:29.050 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:29.080 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:29.110 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:29.151 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:29.180 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:29.220 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:29.250 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:29.287 EIT Update Filter: Activate cnThread
changeDMX: for 0x4e ignored! because of real_pauseCounter> 0
19:17:29.325 EIT Update Filter: Activate cnThread
[.. geht dann die ganze Zeit so weiter ..]

Rahmenbedingungen:

• recording_stopsectionsd=true
  Kernel 2.4
  Aufnahme auf NFS

Nur mal so als Feedback...

... und seife Danke für Deine tolle Arbeit!

Gruß bellum

[seife]

Hm... Muss ich mir mal anschauen. Da könnte was sein.

[seife]

Probiert mal das:

Code: Alles auswählen

Index: dmx.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/daemons/sectionsd/dmx.cpp,v
retrieving revision 1.36
diff -u -p -r1.36 dmx.cpp
--- dmx.cpp     15 Jun 2008 10:44:27 -0000      1.36
+++ dmx.cpp     15 Jun 2008 20:42:36 -0000
@@ -854,12 +854,14 @@ int DMX::setCurrentService(int new_curre
                return 1;
        }

+#if 0
        if (real_pauseCounter > 0)
        {
                /*d*/printf("currentDMX: for 0x%x ignored! because of real_pauseCounter> 0\n", new_current_service);
                unlock();
                return 0;       // not running (e.g. streaming)
        }
+#endif
        closefd();

        int rc = immediate_start();

im immediate_start() wird nochmal geprüft, ob real_pauseCounter > 0 ist (und falls dem so ist,dann wird einfach gar nichts gemacht), es sollte also trotzdem funktionieren.
Achtet auch auf irgendwelche Nebenwirkungen, ich schau es mir auch nochmal an.
Den "sectionsd pausiert und dann kommt ein EIT update rein"-Fall hatte ich nicht bedacht

[MPC823]

Mal nur ne Frage ,

warum wird nicht einfach eine Ungültige EPG PID genommen wenn der Sectionsd pausieren soll oder von dort wo die Daten kommen einfach die Daten nach dev.null geschrieben ? Quasi eine Simmulation dessen, wie wenn man auf Hotbird ohne EPG daten ist.

Ich Frage nur um was zu lernen und mir ist klar das viele Wege nach Rom führen.


Martin

[seife]

Solange der sectionsd pausiert, sollte er einfach gar keine Daten lesen.
Ich hatte allerdings vergessen, dass der CN-Thread, der auf's EIT-update lauscht, auch dann aktiviert werden kann (man könnte das beim Pausieren ausschalten, das ist aber relativ umständlich).

Das Problem, das wir hier hatten, wenn ich bellums Log richtig deute ist, dass er reaktiviert wird (vom EIT update), aber weil der DMX pausiert ist diese Condition nicht zurücksetzen kann.
Mein Patch lässt ihn nun eine "Umdrehung" weiterlaufen, da aber scanning=0 ist, legt er sich gleich wieder schlafen. Das sollte das Problem beheben.

Vermutlich lässt sich das Problem ganz einfach demonstrieren, in dem man auf DeluxeMusic (die senden mit jedem neuen Lied ein EIT update) schaltet und dann den sectionsd pausiert. Das kann ich aber erst am Wochenende probieren.

[MPC823]

Also da mir das ganze keine Ruhe lässt warum weshalb und wieso es auch für mich schwierieg ist wie man "intelligent" den Fehler eingrenzen kann damit ein DEV vielleicht etwas dagegen tun kann habe ich mir mal zum vergleich ein aktuelles JTG Image gezogen .

Aufgespielt habe ich es im auf einer Box mit AVIA500 (SAT) . Nun da war dann die Aufnahme auf allen möglichen Sendern absolut problemlos. Die ganze Box war auch deutlich agiler in der Bedienung. Die FB reagierte sofort.

Dann habe ich um Fehlerquellen auszuschliessen mein Sanpshot aufgespielt und siehe da es funktioniert ebenso problemlos. Die Box ist auch flott und Aufnahmen gelingen ohne Probleme.

Nun der einzige Unterschied ist nun der AVIA. Könnte es sein das die Konstellation AVIA600<->IDE Probleme verursacht ? Anders wäre es auf den ersten Blick nicht zu erklären. Da es beim Abschalten des sectionsd auf Box mit AVIA600 geht könnte es doch ein Treiberproblem sein ???


Villeicht könnten mir die DEV's mit Tipps wie man den Fehler weiter eingrenzen kann, auf die Sprünge helfen. Spassmachen tut es aber so und so

Gruss Martin

[wolgade]

Nun der einzige Unterschied ist nun der AVIA. Könnte es sein das die Konstellation AVIA600<->IDE Probleme verursacht ? Anders wäre es auf den ersten Blick nicht zu erklären. Da es beim Abschalten des sectionsd auf Box mit AVIA600 geht könnte es doch ein Treiberproblem sein ???

Hoppla, da war mal was. Kurz nach Erscheinen des IDE-Interface gab es mal die These, daß AVIA600 Boxen mehr Ärger machen als solche mit AVIA500. Das Problem zeigte sich nur bei der ARD und äußerte sich im Log mit "avia_gt_dmx: queue 0 overflow ". Ich hab den Thread mal gesucht und festgestellt, daß es deiner war: http://tuxbox-forum.dreambox-fan.de/for ... 31&t=42768

Aber eigentlich ergibt das keinen Sinn. Die Fehlermeldung kommt vom Demux, also vom GTX. Es könnte höchstens sein, daß AVIA500/600 unterschiedlich fleißig sind beim Abholen der Daten aus dem Demux-RAM.