Dreambox bei Aufnamhe ins Standby schalten

  • Code
    ja, es gibt halt viele variablen und kombinationen... 

    naja, vielleicht ist es doch viel einfacher... denn auf die timer_after_action kommt es in diesem fall gar nicht an.

    wenn man in den standby schaltet, will man ja dass in den standby geschaltet wird unabhaengig davon welche timer_after_action ausgewaehlt war.

    d.h. man muss dem idle mode eine variable standby_after_timer = true mitgeben und dann im idle mode checken, ob alle timer complete sind.

    fertig :grinning_squinting_face:

  • Ich frage mich nur, wie man die Meldung stehen lassen soll, wenn man auf der Power-Taste immer den DeepStandby liegen hat ???

    Wenn ich auf Power den Idle habe und manuell im Menü den DeepStandby ausführen will, kann ich bei der Meldung einfach Power drücken und die Box geht in den Idle, wo dann nach Ende der Aufnahme die Box dann vermutlich runterfährt.


    Aber wie schalte ich die Box in den Idle mit offener Meldung, wenn ich auf Power den DeepStandby habe ?

    Ich habe auf Power den Idle und Power lang den DeepStandby - wenn ich während einer Aufnahme die Box in den DeepStandby schicken möchte, weil ich z.B. ins Bett gehe aber noch Aufnahmen laufen, dann drücke ich die lange auf die Powertaste, das Hinweisfenster erscheint und ich lasse es stehen, nach der Aufnahme fährt die Box dann runter. Wenn man natürlich aus dem Idle die Box nach der Aufnahme herunterfahren lassen möchte, dann ist das so nicht möglich ohne den Timer zu ändern.

    Aber diese Anforderung habe ich nicht, das ist auch der Grund wieso ich kein CEC nutze, weil ich dann nicht "gezwungen" bin die Box in den Idle zu schalten um den Fernseher abschalten zu lassen.

  • MacDisein

    Ah, wenn man auf Power lang den DeepStandby und auf Power kurz den Idle legt, geht das natürlich :winking_face:

    Ich bin davon ausgegangen, dass ein User, der die Box per Power immer in den DeepStandby ausschaltet, dann auch diesen Mode auf Power kurz hat.


    alpha

    Das Handling beim Schalten in den DeepStandby müsste dann aber auch noch angepasst werden, so dass die Box bei laufender Aufnahme nicht direkt in den DeepStandby geht, sondern erstmal ohne diese Rückfrage in den Idle.

    Das veränderte Verhalten könnte man ja wie schon gesagt über eine neue Einstellung steuern, ob die Box nach Aufnahmenende im Idle dann automatisch in den Standby wechselt.


    Aber wer weiß, ob es da nicht noch weitere Dinge zu berücksichtigen gibt, an die wir jetzt noch gar nicht dachten.


    Diese RecordTimer-Sachen sind doch schon recht komplex.

    Gruß Sven (aka Dreamy)


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

  • Ich bin davon ausgegangen, dass ein User, der die Box per Power immer in den DeepStandby ausschaltet, dann auch diesen Mode auf Power kurz hat.

    ja, so habe ich das.

    so dass die Box bei laufender Aufnahme nicht direkt in den DeepStandby geht, sondern erstmal ohne diese Rückfrage in den Idle.

    genau.

    Aber wer weiß, ob es da nicht noch weitere Dinge zu berücksichtigen gibt, an die wir jetzt noch gar nicht dachten.

    die gefahr besteht immer :grinning_face_with_smiling_eyes:

  • Ich habe die Power Taste schon immer so konfiguriert, mir erscheint das logisch - kurzer Druck und die Box geht in den Ruhemodus, langer Druck und die Box fährt runter.

    Aber daran sieht man wie vielfältig die Konfigurationen bei den unterschiedlichen Usern sind, das ist halt der Fluch der Konfigurierbarkeit - die Möglichkeiten hat man bei einem Baumarktreceiver oder einem LG TV nicht.
    Da lassen sich die möglichen Workflows einfacher abbilden.

  • denke, dass die aenderungen in screens/standby.py in den klassen tryquitmainloop und standby gemacht werden koennen.

    in tryquitmainloop wird der shutdown mit quitmainloop gemacht. hier braucht man ein if davor, das das quitmainloop nur macht wenn keine aufnahmen laufen und ansonsten standby aufruft.

    und in standby braucht man einen check, ob aufnahmen laufen (den man aus tryquitmainloop uebernehmen koennte) und wenn keine (mehr) laufen, dann quitmainloop aufruft.

  • alpha

    Ich hab mir das mal mit relativ überschaubaren Änderungen angepasst (4 Files geändert) :winking_face:


    Also eine zusätzliche Option im System-Setup "Shutdown after record on idle" (default = no)

    Wenn diese Option deaktiviert ist, verhält sich die Box wie im aktuellen Image.


    Wird die Option aktiviert und man versetzt die Box bei laufender Aufnahme in den (Deep)Standby, dann kommt nicht mehr die Frage zum Beenden der Aufnahme, sondern die Box geht direkt in den Idle und fährt erst nach Ende der Aufnahme automatisch in den (Deep)Standby.


    Für welche Box bräuchtest du das ?

    Dann könnte ich dir die 4 Files angepasst zur Verfügung stellen :winking_face:


    \usr\lib\python\RecordTimer.py

    \usr\lib\python\Screens\Standby.py

    \usr\lib\python\Components\UsageConfig.py

    \usr\share\enigma2\setup.xml


    Edit:

    Ich hab jetzt einfach mal beide Anpassungen (für OE2.5 und OE2.6) als Anlage hochgeladen.

    Die Files gemäß Ordnerstruktur aus der Zip auf die Box kopieren und die vorhandenen Dateien ersetzen.

    (die vorhandenen Files von der Box vor dem Überschreiben besser sichern)

    Dann GUI-Neustart machen und im Anpassen-Setup die Option "Shutdown after record on idle" in der Rubrik "Benutzerfreundlichkeit" aktivieren und ausprobieren :winking_face:

  • der code sieht soweit gut aus... werde ihn spaeter mal testen. (uebrigens: du brauchst keine unterschiedlichen versionen fuer oe2.5 und oe2.6 zu machen. das print(...) mit klammern funktioniert auch auf oe2.5).

    was jetzt allerdings noch hinzukommt ist die pruefung der tasks des taskmanagers. die wuerden naemlich einfach abgebrochen, wenn keine aufnahmen laufen. deswegen waere ich eigentlich dafuer, die recordtimer.py unveraendert zu lassen und die pruefung, ob timer oder tasks laufen in der klasse standby zu machen.


    p.s. fuer die, die das zip file testen wollen... in den datei-pfaden fehlt ein enigma2 bei /usr/lib/enigma2/python/.....

    Einmal editiert, zuletzt von alpha ()

  • 1. die RecordTimer prüft doch beim Ende eines Timers mit Afterevent.DeepStandby auch jetzt schon keine Tasks, oder ?

    Was passiert denn da mit offenen Tasks?


    2. Die unterschiedlichen Versionen haben nichts mit dem print() zu tun, sondern weil die Files in den OE’s eben nicht identisch sind.


    Kannst ja mal schauen, ob du da was passendes hinbekommst.

    Meine Ideen sind erstmal ausgeschöpft :winking_face:

    Blöd ist halt immer, dass man bei solchen grundlegenden Änderungen einer bestehenden Logik selten alles unter einen Hut bekommt und der Code dann nur unnötig kompliziert wird.

    Gruß Sven (aka Dreamy)


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

  • habe mal einen test gemacht mit 2 aufnahmen hintereinander mit abstand 1 minute dazwischen.

    funktioniert wie es soll: box bleibt nach der ersten aufnahme im standby und schaltet sich nach der zweiten aus.

    klasse :thumbs_up:

    jetzt teste ich noch die sache mit den tasks...

  • Wenn du keine Aufnahmen hast, dann sollte die Meldung zu offenen Tasks beim Schalten in den DeepStandby wie bisher kommen.


    Und wenn beim Schalten in den DeepStandby Aufnahmen und Tasks laufen, geht die Box ja in den Idle, wo die Tasks dann beendet werden.


    Wenn allerdings nach Ende der Aufnahme die Box im RecordTimer aus dem Idle heruntergefahren wird, werden Tasks nicht geprüft. Das war da auch noch nie drin.


    Weiß gerade gar nicht, ob das Elektro-Plugin im Idle vor dem Herunterfahren auf Tasks prüft ??

    Gruß Sven (aka Dreamy)


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

  • Wenn du keine Aufnahmen hast, dann sollte die Meldung zu offenen Tasks beim Schalten in den DeepStandby wie bisher kommen.

    ja, aber imho sollten task genauso wie timer behandelt werden.

    Wenn allerdings nach Ende der Aufnahme die Box im RecordTimer aus dem Idle heruntergefahren wird, werden Tasks nicht geprüft. Das war da auch noch nie drin.

    ja, das pruefen der tasks hat bisher auch nicht einwandfrei funktioniert, wenn man die meldung stehen gelassen hat.


    Weiß gerade gar nicht, ob das Elektro-Plugin im Idle vor dem Herunterfahren auf Tasks prüft ??

    ich habe bisher das elektro-plugin noch nie gebraucht... von daher waere das fuer mich keine loesung.


    ich denke, deine implementation funktioniert super fuer diejenigen, die nur eine loesung fuer die timer brauchen.

    da ich in meinem moviecockpit file operationen als tasks implementiert habe und z.b. nach aufnahmeende die aufnahme von einer internen kleinen ssd auf eine grosse usb-disk move, brauche ich beides... aber das sollte sich nach deiner vorarbeit leicht in der klasse standby mit einem periodischen timer, der checkt, ob noch tasks laufen oder nicht, implementieren lassen.

  • Hat der Task nicht auch ein Event, wo er das Ende mitteilt?


    Dann könnte ja dort das Herunterfahren im Idle genauso angestoßen werden wie im RecordTimer-Ende.


    Hab mich mit den Tasks noch gar nicht befasst.

    Gruß Sven (aka Dreamy)


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

  • Hab mir die Sache mit dem JobManager mal angeschaut.

    Man könnte im JobManager noch eine Prüfung einbauen, ob nach Ende des letzten Jobs noch Aufnahmen laufen/bald anstehen und wenn nicht, dann herunterfahren, soweit die neue Option zum Herunterfahren im Idle aktiviert ist.


    Dann müsste man aber noch die Option in "shutsown after record/job on idle" umbenennen :smiling_face:

    Auch müsste noch der Code zum Aufrufen des Idle beim Schalten in den DeepStandby um die Job-Prüfung erweitert werden.


    Soll ich das mal für dich versuchen? (für OE2.5 oder OE2.6?)

    Man könnte auch noch ein Event generieren für die Sache mit der offenen MessageBox bei Jobs, aber wenn das mit dem Idle funktioniert, bräuchtest du das ja nicht mehr :winking_face:

    Gruß Sven (aka Dreamy)


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

  • wuerde jobs und timer lieber getrennt lassen. hab mal angefangen die pruefung, ob noch jobs oder timer laufen in die klasse standby einzubauen... die hatte ich eh schon in tryquitmainloop eingebaut und move sie jetzt nach standby. sollte eigentlich funktionieren. die aenderung in recordtimer faellt dann wieder weg.

  • in der TryQuitMainLoop musst du ja nur das hier anpassen:

    (nach dem and muss eine umschließende Klammer für die or-Varianten kommen, das müsste in der ersten Version noch ein Fehler sein)

    Code
            if reason:
                if retvalue == 1:
                    if config.usage.shutdown_after_record_onidle.value and (jobs or recordings or (next_rec_time > 0 and (next_rec_time - time()) < 360)):

    Dann müsstest du im JobManager nur das def kick() ergänzen:

    (da muss man das Standby nicht anpassen und alles ohne zusätzlichen Timer)

    (das quitMainloop muss da natürlich noch gesondert importiert werden - from enigma import quitMainloop)

    Gruß Sven (aka Dreamy)


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

    2 Mal editiert, zuletzt von Sven H ()

  • wenn aber die aufnahme vor der task endet, dann bricht der shutdown die task ab, oder?

    deswegen will ich an einer stelle checken, dass keine aufnahmen und tasks mehr laufen, wenn quitmainloop aufgerufen wird.

  • Das war aber schon immer so (zumindest, wenn der Timer mit afterEvent=DeepStandby lief) :winking_face:

    Also kein neues Problem.


    Da müsste man wohl im RecordTimer beim Aufnahmeende auch noch die Jobs prüfen, so wie man nach dem letzten Job dort auch die Records prüft :winking_face:

    Gruß Sven (aka Dreamy)


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