Fehler bei wiederholenden Timer im oe1.6

    Hi TheDOC,


    gesten Abend gab es einen crash. Ob dieser in Zusammenhang mit dem Timer-Fehler steht, weiß ich jedoch nicht. Hoffentlich findest du jetzt die Ursache. Danke.




    lg


    Anne

    Einmal editiert, zuletzt von TheDOC ()

    Nope, ist ein anderer Crash, nicht Timer-bezogen. :frowning_face:

    Hallo TheDOC,


    nun hat es ziemlich lange gedauert aber jetzt ist so ein Fehler wieder aufgetreten.


    3:58 (da wacht meine Box aus dem Deep-Standby auf) wurde versucht, eine Zeit in die Timeliste zu schreiben, die nicht durch 60 teilbar ist. Ich habe die Dateien angehängt. Kannst Du den Fehler jetzt finden? Das wäre prima!


    Danke.




    Gruß


    Anne

    Das Problem trat bei einem Timer Donnerstags, 22:14 Uhr auf. Dieser fehlt aber in der angehängten timers.xml. Wo ist der denn hin? :smiling_face:

    Hi,
    also ich habe an der Timerliste nichts gemacht. Ich habe am Freitag Abend (08.10.) gesehen, dass es eine crash-log gibt. Die habe ich mir gesichert und die Timerliste ebenfalls. In der Liste selbst waren keine seltsamen Einträge. Da habe ich mich schon gewundert. Ich habe jedoch nicht bemerkt, dass Einträge völlig fehlen! Nur gut, dass Du mich darauf aufmerksam gemacht hast.
    Im Anhang die Timer.xml vom 05.10. Da stehen die beiden verschwundenen Einträge noch drin:
    "Lost" jeden Do 22:14 bis 23:21
    und
    "Lost" jeden Do 23:14 bis 00:16 (Fr)
    Beide wöchentlichen Timer sind in der Timerliste nach dem crash (08.10.) einfach verschwunden. Wo sind die hin???
    Gruß
    Anne
    PS: Ist eigentlich ganz lustig, dass ausgerechnet "Lost" weg ist :smiling_face:

    Nein, das bezog sich auf Lost. :winking_face:


    An deinem Problem rätsel ich noch. Habe im Moment aber keine Idee, was es sein könnte.


    Also durch irgendwas bekamst du die gleiche Start- und Endzeit für die Lost-Aufnahme in die timer.xml geschrieben dann. Das Problem trat nämlich beim Laden selbiger auf und hat dadurch wahrscheinlich mit deinem ursprünglichen Problem nichts zu tun (welcher aber ja anscheinend nicht mehr aufgetreten ist bisher). :frowning_face:

    Ach der Lost-Jacob. Da stand ich wohl etwas auf der Leitung...
    .


    Ich habe ja von der ganzen Sache keine Ahnung aber in der crash-log stand doch was davon drin, dass ein Eintrag gefunden wurde, der nicht durch 60 teilbar ist. Mit der von Dir modifizierten RecordTimer.py wurde doch bewusst dieser Absturz hervorgerufen. Also kam der crash bevor die Lost-Einträge wieder zurück in die TimerListe geschrieben wurden und so waren die dann "verschwunden"?
    Jedenfalls ist sowas bisher noch nie aufgetreten sondern erst mit der speziellen RecordTimer.py. Ich denke, wenn ich später wieder die originale Datei nehme, tritt das nicht mehr auf.
    In der crash steht auch was von "ignore timer conflict" (kurz vor dem Eintrag mit der gleichen Start und Endzeit). Muss da nicht schon vorher was schief gelaufen sein, denn einen TimerKonflikt hätte es doch nicht geben dürfen. Und möglicherweise ist das Setzen der Anfangs- und Endzeit auf 22:14 das Resultat eines Fehlers der zuvor aufgetreten ist und diesen TimerKonflikt verursacht hat?
    Alles nicht so einfach...
    lg
    Anne

    Ich habe gestern noch ein wenig probiert, vielleicht hilft es bei der Lösung weiter...
    .
    Ich hatte nach dem crash letzte Woche (also die Dateien die ich schon geschickt habe) das mitloggen wieder abgeschaltet und die originale RecordTimer.py wieder draufgespielt. Zunächst lief alles prima, bis gestern abend wieder ein TimerEintrag mit Länge 0 zu finden war.
    begin="1287174480" end="1287174481" ("heute-show" in timers2010-10-13a.xml)
    Ich habe den Eintrag direkt an der Dreambox auf die richtige Endzeit gesetzt und das Mitloggen wieder eingeschaltet:
    begin="1287174480" end="1287179100" (timers2010-10-13c.xml).
    Dann habe ich Deine modifizierte RecordTimer.py installiert und sofort gab es einen crash (crash_1287007565.xml). Von den ursprünglich 21 TimerEinträgen waren über die Hälfte weg. Also das Verschwinden von Timern muss mit der abgeänderten RecordTimer.py und nachfolgendem crash zusammenhängen.
    Wenn ich die crash-Datei richtig verstehe, sollte als letzte Aktion die völlig richtige Anfangszeit ("Navy CIS")
    [TIMER] setting begin from: 1287363180 Mon Oct 18 02:53:00 2010
    verändert werden (wieso? der 18.Okt. kommt doch erst noch).
    Und beim Addieren von einer Woche kommt seltsamerweise nicht die gleiche Uhrzeit raus, sondern
    [TIMER] to:1287957964 Mon Oct 25 00:06:04 2010
    also nicht 02:53 Uhr, sondern 00:06 Uhr und 4 Sekunden.
    Diese falsche Zeit wurde richtigerweise erkannt und der crash ausgelöst.
    .
    Also wieso wollte die Box bei einem wöchentlichen Timer, der noch nicht vorbei war, eine Woche addieren? Und wieso kommt dann eine falsche Zeit raus?
    Hilft das oder wird es immer verwirrender???
    lg
    Anne

    anne78: Kannst du mir mal deine /etc/enigma2/settings Datei zukommen lassen? Was für Tuner stecken in deiner Box?


    Ich habe deine timers.xml seit einiger Zeit auf einer Testbox hier und ich bekomme den Fehler leider nicht reproduziert...

    Hallo


    Den Efekt habe ich auch, ich nehme jeden Tag eine Sendung von Montag bis Freitag auf, ich habe die Sendung mit dem Wiederholenden Timer Programmiert, manchmal werden alle aufgenommen manchmal fehlt eine Sendung.


    Jetzt habe ich für jeden Tag einen Wiederholenden Timer programmiert, also pro Tag einen, (habe jetzt 5 Timereinträge für die Sendung im Verzeichnis) jetzt gehts, es werden alle Sendungen Aufgenommen.


    Ich habe eine DM500HD Box mit aktueller DM Software


    gruß


    Michael

    DM500HD, DM7000S

    Hallo TheDOC,


    im Anhang die settings, ich habe 2 Sat-Tuner drin.


    Gestern abend (Sonntag, 31.10.) gab es wieder diesen Fehler. Die Lindenstraße wurde korrekt aufgenommen, beim Errechnen der Daten für die nächste Woche ist jedoch nicht das richtige Ergebnis rausgekommen (sh. screenshot.jpg -> letzter Eintrag ganz unten).


    Ich habe direkt mit der Box über "Einstellungen sichern" ein backup gemacht und die timers.xml (auch im Anhang) mitgeschickt. Obwohl das enigma2settingsbackup.tar.gz von 20:17 Uhr ist, ist die darin enthaltene timers.xml von 01:32 Uhr. Das liegt noch vor der Aufnahmezeit, da sind also alle Einträge noch richtig. Ich hatte gedacht, dass die Timerliste immer gleich nach einer Aufnahme aktualisiert wird, anscheinend ist das nicht der Fall. Ich kann heute abend die Liste nochmal sichern und sie dann morgen schicken...


    Die timers.xml wird anscheinend auch immer neu geschrieben, wenn die Box aus dem Deep-Standby aufwacht (elektro-plugin). Anscheinend hatte meine Box in der Nacht die Zeit jedoch "vergessen" und das Datum dann auf den 01.01.2000 gesetzt (sh. Bild.jpg). Die Fehleinträge sind auch in der timers.xml zu finden (<log code="0" time="946684...). Da die Startzeiten der Timer dann trotzdem richtig sind (also Oktober 2010), nehme ich an, dass dieser Efekkt nichts mit den seltsamen Timerzeiten zu tun hat.
    .


    lg
    Anne">

    Ist evtl. ein anderes Problem, aber bei mir läuft irgendwie immer, wenn Sommerzeit-Umstellung ist, die Timerkonflikt-Kontrolle amok. Da werden Sendungen als überlappend angezeigt, die es nicht sind, da werden Sender nicht in der Kanalliste gefunden, obwohl ich die Sendung eben vom EPG aus programmiert habe. Und wenn es denn mal klappt, ist die End-Zeit um eine Stunde früher (kann dann gar vor der Anfangszeit liegen - muss man 1Std länger einstellen).
    Ich habe dann um einen neuen Timer zu setzen, alle anderen deaktivieren müssen und durfte die dann in der timers.xml per Hand wieder aktivieren. Die Aufnahmen gingen dann korrekt.

    DM 800 HD PVR DVB-S2 OoZooN OE1.6-2011-05-09-experimental, Samsung UE40B6000

    TheDOC,


    im Anhang die timers2010-11-01a.xml (18:55). Der Eintrag "Lindenstraße" ist jetzt richtigerweise an letzter Stelle zu finden. Jedoch ist eine Woche zuviel auf das Anfangsdatum addiert worden (da hätte der 7.Nov. stehen müssen und nicht der 14.Nov.).


    Der nächste wöchentliche Timer der gestern abend lief, war "Kreutzer". Ich habe nach der Aufnahme die Timerliste kontrolliert (23 Uhr, sh. screenshot-2010-11-01.jpg), der Eintrag ist auf die (vor)letzte Stelle gerückt (an letzter Stelle steht ja der falsche 14.Nov.-Eintrag). Soweit so gut. Als ich mir jedoch die Daten der letzten Einträge angesehen habe, war ich doch überrascht. Denn auf "Kreutzer" wurde keine Woche addiert, obwohl die Aufnahme gelaufen ist und der Eintrag an das Listenende gestellt worden ist. Somit sind die letzten 3 Timer:
    Mentalist 8.Nov
    Kreutzer 1.Nov. ???
    Lindenstraße 14.Nov.
    Diese Reihenfolge hätte doch nur gestimmt, wenn Kreutzer+1Woche-> 8.Nov. stehen würde.


    Die zugehörige timers2010-11-01b.xml (also auch 23 Uhr gesichert) stimmt mit der am TV angezeigten nicht überein, hier ist Kreutzer noch an 1. Position zu finden (also als ob die Aufnahme noch nicht gelaufen wäre).


    Gruß
    Anne

    Diesmal hat es einen täglichen Timer erwischt (screenshot-2010-11-24.jpg und timers2010-11-24a.xml). Die Anfangszeit wurde nicht korrekt ermittelt, da hätte der darauf folgende Tag 19:27 stehen müssen. Habe ich manuell korrigiert (timers2010-11-24b.xml).


    Kann das Problem keiner lösen?



    Gruß


    Anne