EPGRefresh 0.1.0

Zitat

Original von crazydogs
Aber bei init 5 && sleep 15 && enigma2.sh > /media/hdd/logsEPGBackup/debug.log 2>&1 wird doch die Datei direkt wieder überschrieben, oder?

Dann wird die Datei "/media/hdd/logsEPGBackup/debug.log" bei jedem Enigma-Start überschrieben.
Alternativ könntest du z.B.

/media/hdd/logsEPGBackup/debug.log.$(date +%Y%m%d-%H%M%S)

schreiben, dann wird jedesmal ein neues file erstellt.

EPGBackup und EPGRefresh haben aber mittlerweile nicht mehr viel miteinander zu tun.

Auch bei wird durch ändern der Zeile nach dem Ende wieder beendet

Danke, das hab ich gesucht.

Ja, aber ich weiß ja nicht was da knallt und EpgBackup loggt ja selbst und war unauffällig

Wie erwartet

Ich bin gespannt, ob du auch ein verändertes Verhalten bzgl. des Delays beim Switchen in den idle-mode feststellst, so wie mike012.

Edit:
Hat sich auf den Post von Brainbug bezogen

Zitat

Original von crazydogs
Danke, das hab ich gesucht.

Ja, aber ich weiß ja nicht was da knallt und EpgBackup loggt ja selbst und war unauffällig

EPGBackup loggt eben nur sich selbst

Zitat

Originally posted by joe128

EPGBackup loggt eben nur sich selbst

Deshalb will ich ja auch nen EPGLog machen.

Mir ist gestern aufgefallen, dass ich nach einem manuellen Refresh sich zwar optisch EPGRefresh geschlossen hat und auch die Meldung kam, dass der Refresh erfolgreich durchgeführt wurde, aber ich die Box erst wieder bedienen konnte nachdem ich nochmals EXIT gedrückt habe. Bis dahin war der Hook noch auf EPGRefresh

Jetzt vermischen wir aber die Themen:

.) Um die Ursache für den Crash zu finden, wird dir ein "EPG-Log" nicht viel bringen, wie du ja bereits festgestellt hast.
Oder reden wir da komplett aneinander vorbei?
Ist der Crash überhaupt reproduzierbar?

.) Nicht schließen von "EPGRefresh":
Rufst du dies über den Plugin-Browser auf? Das hatte ich auch schon einmal, dass dann der Plugin-Browser nicht mehr angezeigt wurde (EPGRefresh-Setup wird geschlossen). Wenn ich mich richtig errinnere, tritt das aber jetzt nicht mehr auf bzw. ist es bei den Betatests auch nur bei mir aufgetreten. Über die Extensions funktionierts auf jeden Fall.

.)
Also, mir ist aufgefallen, dass die Dreambox am Morgen eingeschaltet ist obwohl ich sie definitiv abends in den Standby geschickt habe (ist mehrfach aufgetaucht). Da ich oft abends Updates in die DMM einspiele, aber nicht reboote konnte ich auch sagen, dass die Box nachts gebootet hat (die Updates laufen ja erst durch Reboot ins Produktivsystem ein). Einen Crashlog gab es nicht.

Da nachts eigentlich nur EPGRefresh läuft habe ich damit etwas rumgespielt und kann den Fehler reproduzieren. Wenn die Box eine Zeit gelaufen ist (>5h) und der Refresh startet bootet die Box manchmal unvermittelt neu ohne einen GS oder Crashlog. Es erscheint ohne Pause der Bootbildschirm. Ich vermute, dass dies auch nachts passiert und schreibe z.Z. ein Enigmalog in der Hoffnung, dass ich einen solchen "Absturz" mitloggen kann. Dieses verhalten hatten wir uns auch schonmal bei einem der ersten Beta mal angesehen.
Sobald ich da einen Log habe kann ich mehr sagen und es mal anhängen.

.)
Das 2. habe ich einfach nur mal erwähnt, weil ja im Moment auch drüber diskutiert wird, dass EPGR auf dem letzten Sender stehen bleibt.
Ich hatte da EPGR via Erweiterungsmenu aufgerufen und dann über die Menu-Taste dann ein EPGRefresh angestossen.
Ich habe die aktuelle Version vom Feed drauf

Zitat

Original von crazydogs
.)
Also, mir ist aufgefallen, dass die Dreambox am Morgen eingeschaltet ist obwohl ich sie definitiv abends in den Standby geschickt habe (ist mehrfach aufgetaucht). Da ich oft abends Updates in die DMM einspiele, aber nicht reboote konnte ich auch sagen, dass die Box nachts gebootet hat (die Updates laufen ja erst durch Reboot ins Produktivsystem ein). Einen Crashlog gab es nicht.

Da nachts eigentlich nur EPGRefresh läuft habe ich damit etwas rumgespielt und kann den Fehler reproduzieren. Wenn die Box eine Zeit gelaufen ist (>5h) und der Refresh startet bootet die Box manchmal unvermittelt neu ohne einen GS oder Crashlog. Es erscheint ohne Pause der Bootbildschirm. Ich vermute, dass dies auch nachts passiert und schreibe z.Z. ein Enigmalog in der Hoffnung, dass ich einen solchen "Absturz" mitloggen kann. Dieses verhalten hatten wir uns auch schonmal bei einem der ersten Beta mal angesehen.
Sobald ich da einen Log habe kann ich mehr sagen und es mal anhängen.

Ok, die Einstellung "Nach EPG Aktualisierung herunterfahren" steht auf "Nein"?
Dann warten wir mal den Log ab, und schauen weiter

Zitat

.)
Das 2. habe ich einfach nur mal erwähnt, weil ja im Moment auch drüber diskutiert wird, dass EPGR auf dem letzten Sender stehen bleibt.
Ich hatte da EPGR via Erweiterungsmenu aufgerufen und dann über die Menu-Taste dann ein EPGRefresh angestossen.
Ich habe die aktuelle Version vom Feed drauf

Wie gesagt das Verhalten habe ich nur, wenn die Aktualiserung über den Plugin-Browser (also Menü --> Erweiterungen, nicht extensions die bei manchen Boxen über blue-taste erreichbar sind) gestartet wurde. Bei Gelegenheit schaue ich mal, woran das liegen kann.

.

.

Zitat

Original von Mike012
[quote]Original von Mike012
[quote]Original von joe128
Die Einstellung "Verzögerung sofern nicht im Standby" hat m.E. nur Auswirkung wenn man innerhalb der Timespan ist, in der automatisch aktualisiert werden soll, aber die box nicht im idle ist.
Wenn du dir das im Code ansiehst, wird dies (fast) alles mit der epgrefreshtimer-Klasse bewerkstelligt. Die genannte Einstellung wird einfach zur aktuellen Zeit addiert. Vom EPGRefresh-Code her sollte also die Bedingung in der MainAdapter-Methode keine Auswirkung auf das Verhalten fürs (wieder-)starten haben.

Zum Testen schlage ich auch vor, dass die "valid" - Timespan eingeschränkt wird (deine Einstellungen sind ja anscheinend 0:00-0:00), sodass du besser beurteilen kannst, ob die 10 minuten eingehalten werden.
Also zum beispiel:
.) einstellen auf 1100
.) starten um 1055
.) im log kontrollieren ob der refresh starten wollte, dies aber nicht getan hat, da nicht im idle
.) in idle schicken und überprüfen ob dann nach der "delay"-Einstellung gestartet wird.

Alles anzeigen

Die Einstellung 0:00-0:00 habe ich weil die Box zu unterschiedlichen Zeiten "an" ist (Schichtarbeit ), und sie sobald die Box in den Idle Modus geschaltet wird anfängt zu aktualisieren.

Also wenn ich 11 Uhr einstelle und 5 min. davor manuell starte, fängt es sofort an zu aktualisieren. Manuell über Menü gestartet (Funktion/Aktualisieren).

Es wäre ja interessant wenn ein anderer mit der geänderten MainPictureAdapter.py das Verhalten "Verzögerung sofern nicht im Standby" mal überprüfen könnte.

Ein manuelles Aktualisieren bringt für den Fehlerfall nichts. Ich glaube da habe ich mein Testszenario falsch erklärt

Also wenn es jetzt 1855 ist, dann würde ich die Startzeit auf 1900 Uhr stellen, speichern und neu starten. Das durchstarten sollte sich vor 1900 ausgehen, dann bis 1900 warten (vorausgesetzt die box fährt normal hoch, also nicht in idle oder sonstiges). Im enigma-Log sollte dann ein refresh-Versuch stehen, der aber abgebrochen wurde, da man nicht im standby war. Dann in den standby schicken (Zeitpunkt merken: angenommen 1903) und kontrollieren, ob nun bis 1913 gewartet wird (dem gemerkten Zeitpunkt + 10 Min) bis wieder ein epgrefresh gestartet wird.

Alles Klar, Danke!

Das werde ich Morgen mal machen und dann bescheid geben und auch das logfile mit anhängen.

Test mit geänderten MainPictureAdapter.py !

- Startzeitpunkt auf 17:40Uhr gestellt
- 17:45 Uhr in Idle Modus geschaltet
- beginn des Refresh um 17:50 Uhr (Verzögerung war auf 10min. eingestellt)

Also statt 17:55 Uhr anzufangen, wurde von 17:40 ausgegangen.

Test mit der original MainPictureAdapter.py !

- Startzeitpunkt auf 19:25 Uhr gestellt
- 19:30 Uhr in Idle Modus geschaltet
- beginn des Refresh um 19:35 Uhr (Verzögerung war auf 10min. eingestellt)

Also statt 19:40 Uhr anzufangen, wurde von 19:25 ausgegangen.

Das selbe Verhalten wie mit der geänderten MainPictureAdapter.py!

Vielleicht hilft dir das ja weiter.

Ok, das bedeutet dass die Änderung in der mainpictureAdapter.py keine Auswirkung auf den Refresh-Zeitpunkt hat (wie vermutet). Das war ja der Auslöser für unsere Test-Versuche, aber wir hatten da anscheinend eine falsche Erwartungshaltung.
Es war anscheinend immer so geplant, dass einfach das Checken ob man im Idle ist im eingestellten Intervall passiert, und sobald die Box nicht mehr "in use" ist, wird eben der Refresh gestartet.
Also ich denke "Works as designed"

.

Das hatte mich jetzt auch ein wenig überrascht.
Denn mit meiner 0:00 bis 0:00 Einstellung wurde ja einmal sofort aktualisiert (geänderte MainPictureAdapter.py) und mit der original MainPictureAdapter.py wurde die Verzögerung abgewartet.

Ist es denn vielleicht möglich es "einzubauen" das nachdem in den Idle Modus geschaltet wird, die Verzögerung erst beginnt?

Möglich ist viel, ich stelle mir aber die Frage welchen Mehrwert das hätte.
Die Einstellung wurde vermutlich nur deswegen implementiert, damit nicht umgeschalten wird, wenn man den Sender noch ansieht.