Aufnahme speichert manchmal nur die xml-Datei

[Nico.Laus]

Ich benutze Yadi 2.1.0.3 mit Neutrino und gerade musste ich erneut miterleben, wie bei Aufnahme durch einen Timer in meine per NFS gemountete Linux-Partition nur die xml-Datei zu der Sendung gespeichert wurde.
Ich lass meinen Rechner dabei mind. 30 min vor Aufnahmestart erwachen. Manchmal funktioniert alles reibungslos und es wird sowohl die xml-Beschreibungsdatei als auch der ts-Transportstrom gespeichert. Doch in bisher nicht genauer abgegrenzten Fällen befindet sich im Aufnahmeordner nur die xml-Datei.
Nachdem mir das vorhin so passierte, konnte ich vom Rechner auch keinen Datenstrom von der dbox mehr abgreifen, erst nach einem dbox-Neustart
-> Lässt sich vielleicht durch geeignete Scripte in der dbox der nicht funktionierende Teil neustarten (welcher das auch ist)?
-> Hat jemand ähnliche Probleme?

[zexma]

Ich benutze Yadi 2.1.0.3 mit Neutrino und gerade musste ich erneut miterleben, wie bei Aufnahme durch einen Timer in meine per NFS gemountete Linux-Partition nur die xml-Datei zu der Sendung gespeichert wurde.
...
Nachdem mir das vorhin so passierte, konnte ich vom Rechner auch keinen Datenstrom von der dbox mehr abgreifen, erst nach einem dbox-Neustart
-> Lässt sich vielleicht durch geeignete Scripte in der dbox der nicht funktionierende Teil neustarten (welcher das auch ist)?
-> Hat jemand ähnliche Probleme?

Ja, die Ursache des Problems suche ich auch schon seit Monaten.
Beobachten kann man dies auch schön wenn z.B. über den Tag verteilt mehrere Aufnahmetimer programmiert sind und die Box zwischendurch NICHT runtergefahren wird. Nach spätestens der dritten oder vierten Aufnahme hilft nur noch der Neustart. (Fährt die Box im Anschluß jeder Aufnahme jeweils in den DeepStandby, tritt der Fehler nicht auf).

Das Problem tritt seit ca. Ende 2004 auf.
Wenn ich mich (aus heutiger Sicht) recht erinnere, wurde irgendein teil der "*stream*"-engines seit dieser Zeit fest in neutrino hineinkompiliert.
Außerdem kam zu der Zeit auch das ganze NFS/CIFS -- SPTS/PES -- O_sync/fdata-sync - "Gerümpel" hinzu.

Ich Mutmaße das Problem hängt damit zusammen, das im Anschluß einer vorherigen Aufnahme irgendein Prozess nicht korrekt beendet wird.
Meine bisherigen LOGs sind leider wenig aussagekräftig.

Andererseits scheint das Problem auch bekannt, da es diesbzgl. je eigens eine spezifische Fehlermeldung gibt á la: "...Aufnahme-Prozess aktiv... Neutrino Neustart hilft..."

Falls Du Lust am Testen hast, könntest Du mal ältere Images, so aus Sep/Okt/Nov '04 testen. Zu ca. dieser Zeit hatte ich diese Probleme nämlich NIE.
U.U. lässt sich das Problem dann besser einkreisen.
Ältere Images gibts hier: http://www.computer-kern.de/

[the_Desruptor]

Ich habe auch das problem. Aber 4 aufnahmen pro tag schaffe ich ohne probleme(nachdem ich die box neugestartet habe). Mir ist aber aufgefallen, dass nach ein paar tagen betrieb (Movieplayer VLC und Audioplayer inkl.) dass es fast sicher ist, dass die aufnahmen nicht funktionieren wird. evlt blockiert hier etwas.

[Cbot]

Auch ich habe andauernd genau dieses Problem. Leider ist die Direktaufnahme so für mich nicht wirklich nutzbar, da ich mich nie darauf verlassen kann, dass eine programmierte Aufnahme letztlich überhaupt durchgeführt wird. Klar, ich könnte jetzt jedesmal kurz vorher nen Shutdown Timer programmieren, aber das kann es ja irgendwie nicht sein.

Wäre wirklich gut, wenn sich die Entwickler dieses Problem nochmal ansehen könnten.

Nachtrag: ich habe selbst mal ein wenig geschaut. Offensichtlich scheint die Direktaufnahme ja nicht nur eine relative hohe CPU Last zu verursachen, sondern auch eine Menge Speicher zu verbrauchen (bei meinen Versuchen gerade ebend konnte ich jedesmal nach dem Starten der Aufnahme beobachten, dass etwas weniger als 5MB zusätzlicher Speicher beansprucht wurde. Nach dem Stoppen wurde dieser Speicher wieder freigegeben).
Nun gibt es ja neu die Funktion "Neutrino neustarten". Dies habe ich mal probiert, aber auch nach dem Neustart von Neutrino ist das Problem nicht behoben - klar, da wurde nun auch kein Speicher eingespart. Wenn ich jetzt aber einfach mal den sectionsd kille (der ne Menge Speicher belegt), so funktioniert die Aufnahme wieder. Daher würde ich zunächst mal laienhaft schließen, dass das Aufnahmeproblem mit fehlendem Speicher zusammenhängt. Könnte man sectionsd so verändern, dass er nicht den ganzen Speicher der Box an sich reißt?

[jmittelst]

Da man den sectionsd während der Aufnahme nicht benötigt, wird der normalerweise durch Streaming-Software abgeschaltet. Bei der Direktaufnahme kannst Du dies eigentlich sehr einfach über das recording.start-Skript einrichten.
http://forum.tuxbox-cvs.sourceforge.net ... ding+start
http://wiki.tuxbox-cvs.sourceforge.net/ ... ahme_Start
Natürlich solltest Du den sectionsd in der recoding.end wieder starten.
cu
Jens

[Z80]

Da man den sectionsd während der Aufnahme nicht benötigt, wird der normalerweise durch Streaming-Software abgeschaltet. Bei der Direktaufnahme kannst Du dies eigentlich sehr einfach über das recording.start-Skript einrichten.
http://forum.tuxbox-cvs.sourceforge.net ... ding+start
http://wiki.tuxbox-cvs.sourceforge.net/ ... ahme_Start
Natürlich solltest Du den sectionsd in der recoding.end wieder starten.
cu
Jens

neeee, den sectionsd abschießen ist driss. dann gibts wieder probleme mit dem timerd, es fehlen die EPGs der nicht aktuellen Transponder etc.

[jmittelst]

Da Du wohl kaum von dem Transponder runterzappst, wird das wohl kaum was machen. Und während einer laufenden Aufnahme durch EPGs anderer Transponder zu "blättern" kann man sich ja wohl verkneifen, oder?
Probleme mit dem timerd wird es kaum geben. Alternativ und um sicher zu gehen, kannste ja auf einen sicheren Sender in der recording.end zappen lassen, bevor Du sectionsd neu starten läßt.
Sicher ist das nur ein Workaround. Aber solange niemand was dran macht, erfolgversprechender als beten oder Voodoo.
cu
Jens

[zexma]

Das Problem ist nur, ihr geht hier davon aus es läge an mangelndem, freien Spreicher; dem ist aber nicht so (nach meiner Beobachtung).
Insofern hat Z80 hier recht: zahlreiche Nebenwirkungen zu erwarten, Wirkung mehr als ungewiss.
Statt dieses Rumgefrickels kann man die Box als Workaround dann eher immer in den Deep-Standby fahren lassen, dann klappts mit den Aufnahmen immer.

[Cbot]

Statt dieses Rumgefrickels kann man die Box als Workaround dann eher immer in den Deep-Standby fahren lassen, dann klappts mit den Aufnahmen immer.

Naja, das ist in meinen Augen auch ein ziemliches Gefrickel
Scheinbar ist es echt so, dass da irgendjemand mal der ganzen Sache auf den Grund gehen muss um diesen Fehler "schlicht und einfach" aus dem Code zu entfernen. Alles andere hat auf Dauer wohl wenig Sinn...

[Astra19.2E]

Hallo an alle!

Habe hier schon eine Weile mitgelesen und bin auf diesen Thread gestoßen.

Das oben beschriebene Problem habe ich mit meiner Nokia dbox2 ebenfalls.

Das benutze Image ist von "DietmarW" vom 23.06.2005.

Auch ich bin sehr an einer Lösung dieses Problems interessiert.

Kann mir evnt. jemand sagen, ob es dazu schon Buxfixes gibt?


Gruß,
Astra19.2E

EDIT:

Achso, eine kleine Anmerkung noch: Wenn ich eine Aufnahme über einen Timer schalte, und die Aufnahme-Zeit bereits beendet ist (Er hat den Sender nicht aufgenommen sondern nur die XML-Datei geschrieben), ist der Sender von dem ich aufgenommen habe schwarz, d.h. es werden zwar die EPG-Informationen gezeigt aber es kommt weder Ton noch Bild (Sowohl auf dem Fernseher als auch mit JackTheGrabber).

Alle anderen Kanäle gehen einwandfrei.

Dieses Problem lässt sich nur und ausschliesslich über einen Kaltstart der Box beheben, dann ist der Sender wieder da.

[Cbot]

Achso, eine kleine Anmerkung noch: Wenn ich eine Aufnahme über einen Timer schalte, und die Aufnahme-Zeit bereits beendet ist (Er hat den Sender nicht aufgenommen sondern nur die XML-Datei geschrieben), ist der Sender von dem ich aufgenommen habe schwarz, d.h. es werden zwar die EPG-Informationen gezeigt aber es kommt weder Ton noch Bild (Sowohl auf dem Fernseher als auch mit JackTheGrabber).

Ganz genau diesen Effekt habe ich ebenfalls. Ich habe schon mehrfach in diesem Forum zu diesem Thema gepostet, aber leider habe ich da von den Entwicklern nie eine Reaktion bekommen bzw. leider scheint sich da niemand drum zu kümmern. Ich frage mich: tritt der Fehler denn bei anderen nicht auf? Für mich ist dieser Fehler momentan DIE Schwachstelle schlechthin. Falls niemand die Lösung weiß, wäre es doch aber zumindest schonmal ein Fortschritt, wenn irgendjemand den Fehler identifizieren könnte.

[Gorcon]

Irgendwie verstehe ich das aber nicht.
Warum fährt die Box denn bei euch nach der Aufnahme nicht wieder runter, bei mir tut sie das immer und dann klappt auch jede Aufnahme.
Nur wenn ich zwei Aufnahmen unmitelbar hintereinander mache dann fährt sie natürlich nicht runter.

Gruß Gorcon

[Cbot]

Naja, das ist doch nun wirklich keine praktikable Lösung. Bei Timeraufnahmen irgendwo mitten in der Nacht lasse ich es mir ja noch gefallen vorher einen Shutdown Timer zu setzen. Aber wenn ich einfach so durchs Programm schalte und eine interessante Sendung entdecke, will ich auch einfach mal die Aufnahme starten könnten. In vielen Fällen tritt dann genau in diesem Moment der Fehler auf (insbesondere dann, wenn die Box schon länger läuft). Vor allem muss ich jedesmal nach dem Start der Aufnahme zum Computer rennen und gucken, ob denn auch die .ts Datei geschrieben wird.
Und prinzipiell nach jeder Aufnahme die Box "sicherheitshalber" herunter zu fahren um hoffen zu können, dass die nächste Aufnahme dann funktioniert, finde ich auch irgendwie nicht besonders zufriedenstellend.