[vermutlich gelöst] "Fehler" im Elektro-Plugin im Zusammenhang mit AfterEvent = Auto im Recordtimer

  • Hier gab es eine berechtigte "Fehlermeldung" zum Elektro-Plugin:

    https://www.i-have-a-dreambox.…ostid=2235455#post2235455


    Die Box wird wegen eines Recordtimers z.B. um 16:43 geweckt (die Aufnahme endet um 17:20 und ist bei "AfterEvent" auf "Auto" gestellt).

    Wenn nun die Aufwecktime für das Elektro-Plugin (17:00) innerhalb dieser Aufnahmezeit liegt, wird die Box bei Aufnahmeende trotzdem wieder in den DeepStandby geschickt, obwohl ja die Box inzwischen durch das Elektro-Plugin gestartet worden wäre und somit um 17:20 im Idle-Mode sein sollte.


    Ich hab mir das ganze mal angeschaut und 2 Möglichkeiten gefunden, wo ich aber nicht genau abschätzen kann, was da die Außenwirkungen wären :thinking_face:


    Es gibt im Elektro-Plugin eine Stelle, wo laufende Aufnahmen geprüft werden (das passiert zu jeder vollen Minute).

    Wenn man da jetzt eine Zusatzprüfung reinnimmt, ob die aktuelle Zeit mit der Aufweckzeit des Elektro identisch ist.

    Wenn ja, könnte dann darüber das AfterEvent für die laufenden Timer beeinflusst werden.


    Nun gäbe da wie gesagt 2. Möglihkeiten:

    1. man ändert das AfterEvent der gerade laufenden Timer auf "AFTEREVENT.NONE" oder

    2. man ändert __wasTimerWakeup aus der Navigation.py in "False"


    Bei der 1. Möglichkeit könnte rein theoretisch ein 2. Record-Timer (Start: 17:10 - also nach der Elektro-Start-Zeit), der nach dem 1. Recordtimer (16:43) startet, bei seinem Ende wieder das force_auto_shutdown auslösen, weil bei diesem 2. Timer zur Elektro-Aufweckzeit das AfterEvent nicht geändert wurde.


    Die 2. Möglichkeit beeinflusst das Setzen von force_auto_shutdown (ist verantwortlich für den DeepStandby nach TimerEnde) über die Funktion NavigationInstance.instance.wasTimerWakeup(), was dann nicht mehr zum auto_shutdown nach Timerende führen würde.


    Jetzt die Frage an die Experten, welche Variante würdet ihr empfehlen ?

    Hätte die 2. Möglichkeit irgendwelche ungewollte Nebenwirkungen ?

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Sven H

    Hat den Titel des Themas von „"Fehler" im Elektro-Plugin“ zu „"Fehler" im Elektro-Plugin im Zusammenhang mit AfterEvent = Auto im Recordtimer“ geändert.
  • Vermutlich würde es schon reichen, den Wert in config.misc.standbyCounter.value im Elektro-Plugin zu erhöhen, wenn die aktuelle Zeit der Elektro-Aufweckzeit entspricht.

    Denn alle anderen Werte aus den Bedingungen für das force_auto_shutdown (bei Afterevent = Auto) ändern sich nach einem Einschalten (aus dem Idle) und erneutem Setzen in den Idle-Mode nicht. nur dieser StandbyCounter.


    Der Wert ==1 aus dem StandbyCounter scheint wohl auch nur in der RecordTimer.py eine Rolle zu spielen, so dass das manuelle erhöhen dieses Wertes kein Problem sein dürfte :winking_face:

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

    Einmal editiert, zuletzt von Sven H ()

  • hmm, grundsätzlich klappt das schon mal , wenn ich den config.misc.standbyCounter.value so erhöhe :winking_face:

    Allerdings werden dann sämtliche Actions bei Änderungen des config-Wertes aufgerufen, die mit config.misc.standbyCounter.addNotifier(Action, …) eingebunden sind.


    Kann man das Notifier für einen config-Wert kurzzeitig deaktivieren ?

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Auch wenn das hier noch ein Monolog zu sein scheint, mach ich dennoch mal weiter :grinning_face_with_smiling_eyes:


    Um das Ausführen der ganzen Funktionen aus dem config.misc.standbyCounter.addNotifier beim Erhöhen des Config-Wertes zu verhindern, hab ich jetzt 2 Quick&Dirty-Lösungen gefunden :winking_face:


    1. den letzten gespeicherten Vergleichswert in den notifiers vor dem Erhöhen des Config-Wertes ebenfalls erhöhen:

    (dann wird das notifier beim Ändern des Config-Wertes nicht ausgeführt)

    Code
    new_value = config.misc.standbyCounter.value + 1
    for (func, val) in sorted(config.misc.standbyCounter._ConfigElement__notifiers.iteritems()):
         config.misc.standbyCounter._ConfigElement__notifiers[func] = (val[0], val[1], str(new_value), val[3])
    config.misc.standbyCounter.value = new_value

    2. die notifiers vor dem Erhöhen des Config-Wertes entfernen und dann wieder zurücksetzen:
    (die haben dann zwar wieder den alten Vergleichswert im notifier, was aber beim nächsten set to Idle nicht zu stören scheint)

    Code
    new_value = config.misc.standbyCounter.value + 1
    # to disable all notifiers
    notifiers = config.misc.standbyCounter._ConfigElement__notifiers
    config.misc.standbyCounter.clearNotifiers() 
    config.misc.standbyCounter.value = new_value
    # reset the saved notifiers 
    config.misc.standbyCounter._ConfigElement__notifiers = notifiers


    Nun ist die Frage, welche Variante würde ihr empfehlen ?

    Ich denke, dass beide nicht ganz sauber sind :winking_face:

    Aber irgendwie muss man das Problem mit dem falschen DeepStandby beim Record-Ende ja lösen können.


    Wie gesagt, man könnte auch noch das __wasTimerWakeup auf "False" setzen, wobei ich nicht ganz abschätzen kann, was das dann wieder für Folgen haben könnte.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Das einzige, was einigermassen sauber tönt, ist das afterevent aller timer, die zeitlich vor der definierten Bootup-Zeit starten und zur Bootup-Zeit noch laufen zu modifizieren. Das kannst du sogar schon beim Herunterfahren der Box durch Elektro erledigen, dann modifizierst du nämlich nicht einen laufenden Timer.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • Ok :thumbs_up:

    Da muss ich nochmal etwas drüber nachdenken, wobei mir dabei gerade einfällt, dass ich ja noch testen wollte, wie die Bedingungen für das force_auto_shutdown sind, wenn ein Timer nach der Aufweckzeit gestartet wird.


    Denn das scheint ja zu funktionieren.

    Mal sehen, was da anders ist.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Ich glaub, ich hab's gefunden :winking_face:


    Der Wert in config.misc.isNextRecordTimerAfterEventActionAuto.value ist offensichtlich nur beim Wakeup über einen RecordTimer auf True.

    (dieser Config-Wert ist auch ein Wert, der das force_auto_shutdown beeinflusst)

    Wenn man diesen Wert bei Erreichen der Elektro-Wakeuptime auf False setzt, passt es :winking_face:


    Beim erneuten DeepStandby/GUI-Neustart wird dieser Config-Wert dann über die mytest.py wieder passend neu geschrieben, so dass die vorübergehende Änderung da wohl keine Auswirkung hat :winking_face:


    Wer die Anpassung mal auf die Schnelle (13min) testen will (ohne langes Abwarten des nächsten Elektro-Starts), kann dieser Anleitung folgen:

    1. im Elektro-Setup die Startzeit des aktuellen Wochentages und Profiles neu festlegen (aktuelle Zeit + 10min)

    2. Timer anlegen (Timerstartzeit = aktuelle Zeit + 7min, Timerendezeit = Timerstartzeit + 6min)

    3. GUI-Neustart machen (sonst wird irgendwie die neue Elektro-Startzeit nicht sofort gesetzt)

    4. nachdem die Box nach dem GUI-Neustart wieder an ist, Box in den DeepStandby schicken

    5. Warten bis Box kurz vor Aufnahme-Start startet

    6. Box im Idle-Mode belassen und warten, was nach dem Aufnahme-Ende passiert.

    7. im Elektro-Setup die Startzeit des aktuellen Wochentages und Profiles wieder korrigieren


    Mit der angepassten plugin.py sollte die Box nach Aufnahme-Ende im Idle-Mode bleiben.

    Mit der bisherigen Original-Version der plugin.py sollte die Box in den DeepStandby gehen, was eben fehlerhaft ist.


    Edit:

    Anhang gelöscht - aktuelle Anlage in Post #8

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

    3 Mal editiert, zuletzt von Sven H ()

  • Sven H

    Hat den Titel des Themas von „"Fehler" im Elektro-Plugin im Zusammenhang mit AfterEvent = Auto im Recordtimer“ zu „[vermutlich gelöst] "Fehler" im Elektro-Plugin im Zusammenhang mit AfterEvent = Auto im Recordtimer“ geändert.
  • Ich hab das nochmal etwas optimiert :winking_face:


    Jetzt wird bei der Prüfung, ob die Elektro-Wakeuptime bereits erreicht ist, auch der sonst üblicherweise verwendete plugininterne ShutDownGrenzwert (20min) berücksichtigt.

    Das verhindert z.B., dass ein Timer, der 1min vor Erreichen der Elektro-Wakeuptime endet, die Box unnötig in den DeepStandby schickt, da sie dann durch das Elektro ja gleich wieder aufgeweckt wird.

    Damit wird also in einem Zeitfenster von 20min vor der Elektro-Wakeuptime ein unnötiges Herunterfahren der Box verhindert.

    Das wird bei der Prüfung zu noch anstehenden RecordTimer-Aufnahmen auch schon so behandelt.

  • Ich hab da noch ein (zumindest für mich) merkwürdiges Verhalten festgestellt :winking_face:


    Die Box soll lt. Einstellung um 01.00 Uhr abschalten, sofern sie im Idle-Mode ist.

    Ich habe aber noch bis 01.10 Uhr einen Film geschaut und danach noch ein Plugin installiert, worauf ein GUI-Neustart durchgeführt wurde.

    Nach dem Start habe ich die Box dann wenig später in den Idle-Mode geschickt, aber das Elektro hat die Box dann nicht in den DeepStandby versetzt, obwohl ja die SleepTime von 01.00 Uhr schon überschritten war :thinking_face:

    Das macht das Elektro bei einem manuellen Start nach der Sleeptime erst bei Erreichen der nächsten SleepTime (also am nächsten Tag um 01.00 Uhr).

    Somit wäre die Box bis zur nächsten Aufwachzeit auch im Idle-Verblieben, wo ich sie lieber automatisiert im DeepStandby hätte.


    Nach Analyse des Ganzen habe ich dafür nun eine zusätzliche Setup-Option "check for sleep directly after manual boot" integriert :winking_face:

    Default steht auf "no", was dem bisherigen Verhalten entspricht, so dass es keine ungewollte Funktionsänderung gibt.

    Damit kann man das Elektro veranlassen, die Box auch nach einem manuellen Start nach der aktuellen Sleeptime aus dem Idle-Mode in den DeepStandby zu schicken (sofern alle Einstellungen/Checks das dann zulassen).