Jack the Grabber

mist *g* Naja ok, muss ich halt danach aufstehen und Stecker ziehen, so oft Streame ich ja nicht, nur wenn ein Film mich wirklich interssiert - dumm is halt bei mehr als einem Film über Nacht oder wenn ich weg bin, aber ok, das liegt ja am CDK und nich am Tool - aber die Idee mit dem Reboot war trotzdem gut, danke

Hast Du es mit einem Reboot-Timer mal probiert? Es könnte nämlich sein, dass es funktioniert, obwohl sich deine Box verabschiedet hat. Denn der Reboot dürfte eigentlich per Telnet durchgeführt werden und Telnet ist ja vielleicht noch verfügbar.

Meine Box hat sich vorgestern (Dienstag) auch während des Streamens verabschiedet (Cramfs vom 07.07.2003) allerdings konnte JtG die Box trotzdem runterfahren.

Also probiers mal und poste dann das Ergebnis

Cu leth

typisch, Murphy's Law, jetzt schmiert er mir nichmehr ab, trotz sectionsd restart *g* Ich versuchs mal weiter...

-edit-
Heul ich schaffs einfach nicht mehr die Box zum abschmieren zu kriegen, eigentlich sollte ich mich ja freuen, aber ich weiss genau, sie wird dann abschmieren wenn ichs nich haben kann ;) Werd bei jeder Aufnahme die ich mache, danach nen 2-3min Reboot einbauen, falls sie dann wirklich mal abschmieren sollte und auch viá Telnet nichtmehr runterfährt, werd ich das sofort schreiben :)
-edit

meine hat die eigenart, dass sie nach nem "reebot" nicht stabil läuft,
nach nem "reset" läuft sie eigentlich so 2-3 tage durch ...
keine Ahnung warum, jetzt resette ich sie halt alle 2 tage

Joe

Es könnte auch sein, dass das Einfrieren am Abschalten des Record-Modus liegt. Wenn sich das Problem verifizieren lässt, kann ich ja mal zum Test einen Patch machen, mit welchem man auch optional das Schalten in den Record-Modus abschalten kann.
Der Record-Modus der Box verhindert das Umschalten auf Kanäle eines anderen Transponders während der Aufnahme.

Levi

PS: Ich vermute aber auch, dass der ReBoot noch funktionieren wird.

Ihr mit eurer um die Fehler drummrum patcherei
Tut doch solche Probleme einfach mal Kund, dann beseitigt vielleicht auch jemand die Wurzel des Übels.
Ich hab mich jetzt auf jeden Fall draufgestürzt und denke dass ich da was zustande bringe... Wird zwar auch nur ein workaround um die Buggy-Treiber, aber ich denke der ist im nhttpd besser aufgehoben, als im Streaming-Programm. Im ersten Tests sah es ganz gut aus, mach jetzt aber nochmal ne richtig lange Aufnahme.
Achja, hatte noch gar nicht erwähnt, dass es definitiv am record modus liegt, bzw. die Kommandofolge die der nhttpd beim schalten in den Record-Modus ausführt.
Hab da noch ne Anmerkung für die JTG Entwickler. Wenn man dem nhttpd sagt, dass die Box in den record modus gehen soll (.../control/setmode?record...) dann schaltet der automatisch auch den sectionsd auf standby, es ist auch möglich im selben Aufwasch das Playback anzuhalten wenn erwümscht (einfach noch nen Parameter "stopplayback=true" dahinter schreiben, trennen glaub ich mit &). Dann passiert das alles in einem Aufwasch, wir wollen den armen nhttpd ja nicht überfordern
Beim Abschalten des Record-Modus wird dann auch der sectionsd wieder aufgeweckt und das Playback gestartet.

BTW ich würde auch gerne noch diese nervigen nhttpd -Abstürze beenden. Kann mir hier jemand nen schnellen Weg schildern, wie man den nhttpd zum Absturz bringt ?

Zwen

Hi Zwen,

erstmal herzlich Willkommen im Board

Hi

Zwen hat geschrieben:Ich hab mich jetzt auf jeden Fall draufgestürzt und denke dass ich da was zustande bringe... Wird zwar auch nur ein workaround um die Buggy-Treiber, aber ich denke der ist im nhttpd besser aufgehoben, als im Streaming-Programm. Im ersten Tests sah es ganz gut aus, mach jetzt aber nochmal ne richtig lange Aufnahme.

Das hört sich doch mal richtig gut an !

Hab da noch ne Anmerkung für die JTG Entwickler. Wenn man dem nhttpd sagt, dass die Box in den record modus gehen soll (.../control/setmode?record...) dann schaltet der automatisch auch den sectionsd auf standby, es ist auch möglich im selben Aufwasch das Playback anzuhalten wenn erwümscht (einfach noch nen Parameter "stopplayback=true" dahinter schreiben, trennen glaub ich mit &). Dann passiert das alles in einem Aufwasch, wir wollen den armen nhttpd ja nicht überfordern

Guter Tipp !
Wenn Du schonmal hier bist , gibt es auch ne Möglichkeit den Status des Playbacks/sectionsd abzufragen, ähnlich wie beim Recordmodus ?
Wenn nicht, wäre das realisierbar ?

BTW ich würde auch gerne noch diese nervigen nhttpd -Abstürze beenden.Kann mir hier jemand nen schnellen Weg schildern, wie man den nhttpd zum Absturz bringt ?

Leider keinen direkten nachvollziehbaren Weg. Oft treten Abstürze beim Zuschalten des Playbacks/sectionsd auf.
Was in letzter Zeit aber viel häufiger auftritt, dass der zapit wegbricht. Zumindest meint der nhttpd beim Neustart, das die /tmp/zapit.sock nicht mehr da ist. Ich gehe mal davon aus, dass es auf dieser Ebene auch keinen Weg gibt, das irgendwie zu reparieren ? Einfach per Telnet den zapit neu starten bringts irgendwie nicht Dieser Fehler tritt aber erst bei der API3 auf. Bei der API die im Februar/März aktuell war hab ich das noch nie gehabt.

Levi

Levithan hat geschrieben: Ich glaub ich muss weg
Ist mir jetzt nichts bekannt, kann aber grad net in den code schauen, werd ich morgen mal machen...
Allerdings ist es auch nicht tragisch das start/stop sowohl für playback als auch für sectionsd-scanning provisorisch zu machen, will sagen ein start auf nen gestarteten sectionsd macht nichts, u.s.w.
Wenn du allerdings nen Status anzeigen willst, bringt dir das natürlich nichts.

Nix da, hiergeblieben
Ich habe den Eindruck, dass das Zuschalten des Playbacks/sectionsd wenn dieser bereits gestartet ist, doch nicht so unproblematisch ist. Es war/ist sehr auffällig, dass gerade in diesen Fällen öfters der nhttpd im Anschluss nicht mehr verfügbar ist. Das kann aber auch nur Zufall sein, Du kennst dich in den Source besser aus

*Argh* Zapit ! Diese Baustelle hab ich bis jetzt gemieden

Hehe, dass ist aber imho die größte Schwachstelle im HEAD.

Allerdings das mit dem /tmp/zapit.sock liegt idR nicht daran, dass die zapit weg ist, sondern, dass sie im "Standby-Mode" ist. Da nimmt sie dann keine Befehle mehr entgegen, mit Ausnahme des Befehls der sie aus dem Standby aufweckt. Der mp3- und der movieplayer z.B. schalten zapit während der Ausführung in den Standby. AUfwecken per http geht glaub ich im Moment noch nicht - per Kommandozeile macht das ein "pzapit -lsb". (pzapit -esb schickt sie in den Standby, lsb=leave stand by, esb=enter stand by).

Na goil. Dass ist doch mal ein brauchbarer Hinweis. Allerdings müsste mir ein ps -aux |grep zapit einen laufenden Daemon anzeigen, auch wenn er im Standby ist, oder ? Ich habe das mit dem 1.6.10 vom 22.07.2003 mal getestet, nachdem der nhttpd den fehlenden Socket angemeckert hatte. Da war nischt mehr Aber das teste ich auf jeden Fall nochmal.

Levi

Hoppla, da hat wohl jemand den zitat und edit Button verwechselt ...

Also die status abfragen hab ich mal reingemacht:
http://dbox/control/zapto?statusplayback -> 1/0
http://dbox/control/zapto?statussectionsd -> 1/0

Die Ursache für den crash ist das startplayback() das der nhttpd macht wenn man den record mode abschaltet. Das hat er immer gemacht auch wenn man playback vorher gar nicht gestoppt hatte (hab ich mal) geändert.
Ich denke aber dieser crash tritt nur auf, wenn man das playback startet und das streamen noch akiv ist, d.h. warte doch einfach mal ein bischen nachdem du das streamen abbrichst, bist du das record=stop absetzt (1 sec. sollte reichen). Ich denke die Box hat das streamen noch nicht beendet, wenn das recordstop Kommando gesendet wird.
Und dann schlägt halt der Treiber-Bug zu...
Das wird wohl der selbe sein, der auch die Box crasht wenn man beim Streamen zapt, vielleicht kann ich ja obi nochmal lieb bitten, dass er den raus macht...

Zwen

vielleicht kann ich ja obi nochmal lieb bitten, dass er den raus macht...

wie geht das bei Obi...'lieb bitten' ? Waere geil wenn er Deine Bitten erhoert

cu,
peter

Zwen hat geschrieben:Hoppla, da hat wohl jemand den zitat und edit Button verwechselt ...

Huch...Ähmm...

Also die status abfragen hab ich mal reingemacht:
http://dbox/control/zapto?statusplayback -> 1/0
http://dbox/control/zapto?statussectionsd -> 1/0

Super, Danke !!

Die Ursache für den crash ist das startplayback() das der nhttpd macht wenn man den record mode abschaltet. Das hat er immer gemacht auch wenn man playback vorher gar nicht gestoppt hatte (hab ich mal) geändert.

Genau. Besonders auffällig war das, wenn man über den Streamingserver aufnimmt. Dort wird der Recordmodus ja automatisch gesetzt. Wenn ich dann aber nach der Aufnahme per Hand wieder das Playback starten wollte, obwohl das Neutrino ja bereits selbst getan hat, war sehr oft totale Wurst in der Box..
Das gleiche Problem hatte ich, wenn ich nach einem Playback off den sectionsd wieder starten wollte. Ging oft in die Hose. War das eigentlich schon immer so, dass ein Playback on den sectionsd auch wieder startet ?

Ich denke aber dieser crash tritt nur auf, wenn man das playback startet und das streamen noch akiv ist, d.h. warte doch einfach mal ein bischen nachdem du das streamen abbrichst, bist du das record=stop absetzt (1 sec. sollte reichen). Ich denke die Box hat das streamen noch nicht beendet, wenn das recordstop Kommando gesendet wird.
Und dann schlägt halt der Treiber-Bug zu...

Hehe, den kenn ich Früher gabs dann eigentlich nur einen ReSync, jetzt geht die Box schlafen

Das wird wohl der selbe sein, der auch die Box crasht wenn man beim Streamen zapt, vielleicht kann ich ja obi nochmal lieb bitten, dass er den raus macht...

Gute Idee. Prognose wanted, werden die Treiber der API3 jemals Bugfrei sein Warum gab es eigentlich so oft einen Wechsel der API ?

Danke nochmal für die Abfrage und Deine Tipps !

Levithan hat geschrieben:War das eigentlich schon immer so, dass ein Playback on den sectionsd auch wieder startet ?

Ja scheint schon immer so gewesen zu sein...

Prognose wanted, werden die Treiber der API3 jemals Bugfrei sein Warum gab es eigentlich so oft einen Wechsel der API ?

Bugfrei, ich glaube nie
Da fehlt einfach die men power, besonders im Treiber-Bereich.
Warum API3 ? Also das liegt wohl etwas an der Zielsetzung/Motivation die hinter dem Projekt steht. Bei vielen steht einfach nicht die Stabilität der Software im Vordegrund , sondern der wissenschaftliche/technische Aspekt, bzw. das "am Ball beleiben", was neue Standards in der Entwicklung betrifft. API3 ist nun mal LinuxTV Standard, d.h. das dann alle Software die auf api3 aufbaut, auch beliebig auf anderer Hardware läuft (z.B. PC mit DVB-Karte), bzw das alle Software, die die API3 benutzt auch auf der dbox läuft...
Das mögen vielleicht manche nicht verstehen, aber schliesslich ist das alles freiwillig und kostenlos und da darf IMHO dann jeder selbst entscheiden.

So, und auserdem hab ich heut noch 2 Bugs des nhttpd geflickt und ich wage zu behaupten, dass der jetzt nicht mehr abstürzt
Wer überzeugt mich vom Gegenteil ?

Zwen

Zwen hat geschrieben:Ihr mit eurer um die Fehler drummrum patcherei
Tut doch solche Probleme einfach mal Kund, dann beseitigt vielleicht auch jemand die Wurzel des Übels.

Hi Zwen

Du darfst uns das nicht übel nehmen, wir kommen aus der Windows-Welt :D:D

Gag

Zwen hat geschrieben: Bugfrei, ich glaube nie
Da fehlt einfach die men power, besonders im Treiber-Bereich.
Warum API3 ? Also das liegt wohl etwas an der Zielsetzung/Motivation die hinter dem Projekt steht. Bei vielen steht einfach nicht die Stabilität der Software im Vordegrund , sondern der wissenschaftliche/technische Aspekt, bzw. das "am Ball beleiben", was neue Standards in der Entwicklung betrifft. API3 ist nun mal LinuxTV Standard, d.h. das dann alle Software die auf api3 aufbaut, auch beliebig auf anderer Hardware läuft (z.B. PC mit DVB-Karte), bzw das alle Software, die die API3 benutzt auch auf der dbox läuft...

Dann bleibt also nur zu hoffen, dass die API3 recht lange LinuxTV Standard bleibt

Die HEADS der letzten Woche machen aber mittlerweile einen sehr guten Eindruck. Und der Elan bei Euch scheint mit dem Movieplayer auch wieder zurückgekehrt zu sein

So, und auserdem hab ich heut noch 2 Bugs des nhttpd geflickt und ich wage zu behaupten, dass der jetzt nicht mehr abstürzt
Wer überzeugt mich vom Gegenteil ?

Das sind doch gute Neuigkeiten Dann werde ich den heutigen Shot mal installieren..
Übrigens, die Meldung über den fehlenden /tmp/zapit.sock liegt nicht imho am Standby des zapits. Ich habe den mal per Hand in den Standby geschickt und dann den nhttpd neugestartet. Der nhttpd hat sich garnicht mehr eingekriegt. Die Fehlermeldung habe ich nciht mehr im Schädel, war aber imho irgendwas mit "broken pipe"...

Levi

Zwen[/quote]