Posts by alpha

    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.

    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 :thumbup:

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

    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/.....

    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.

    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 ^^

    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 :D

    wow, in RecordTimer hatte ich auch schon geschaut... aber muss == 1 wohl uebersehen haben.

    Wobei ich hier aber auch irgendwo gelesen hatte, dass wenn 2 Timer nacheinander laufen, dass dann nach dem 2. Timer die Box nicht in den DeepStandby geht, wenn die Box für den 1. Timer hochgefahren wurde.

    dieses problem tritt imho bei afteraction = standby auf. wir reden hier aber ueber afteraction = auto.


    Das wollen zumindest diejenigen nicht, die ihre Box immer im Idle haben wollen und nur manuell in den (Deep)Standby schicken ;)

    wenn die box immer im idle ist, dann startet die aufnahme ja aus dem idle und bleibt nach der aufnahme im idle.


    "Box in den Idle schalten und nach Aufnahmeende in den DeepStandby gehen"

    "Box für Aufnahme in den Idle Mode schalten" waere da besser, da es von der afteraction abhaengt, ob die box danach in den standby mode geht oder nicht.


    Aber das sind doch schon mal sinnvolle ansaetze... danke Sven H

    man koennte auch einfach die stelle suchen, die die box nicht bei timerende in den standby schickt, wenn es nicht das erste idle ist. also wenn die box manuell in den idle mode geschaltet worden ist und nicht aus dem standby in den idle ging.

    hab mal ein paar greps gemacht, aber konnte die stelle auf anhieb nicht finden :(

    da mir keiner hilft :P , habe ich ein bisschen weitergewurstelt...

    das doSeekRelative soll ja am fileende zur position 1s vor ende springen (wenn ich den code richtig verstanden habe). das scheint auch meistens zu funktionieren, aber anscheinend nicht immer. ich vermute, dass bei einer laufenden aufnahme, das ende nicht immer richtig bestimmt wird und es dann zu komischen effekten kommt.

    ich habe jetzt mal nach jeder seek op eine 1s blockade eingebaut, bevor die naechste seek operation ausgefuehrt wird.

    das scheint die sache zu verbessern, aber ob der wuergaround 100%ig funktioniert muss sich erst noch erweisen.....

    vom aufruf her hat man ja den eindruck, dass seek funktionen wie z.b. doSeekRelative synchron ausgeführt werden, d.h. die funktion returned, wenn der sprung durchgefuehrt ist.

    dem ist aber nach meiner beobachtung nicht so. wenn direkt nach dem aufruf ein getPosition macht, dann wird die position vor dem seek zurueckgegeben.

    das waere ja alles nicht so schlimm, aber wenn man beim abspielen einer laufenden aufnahme ans ende springt, dann verheddert sich ab und zu das seek und ein rueckwaertssprung mit doSeekRelative(-xyz) funktioniert nicht mehr. doSeek(pos) gehen dann auch nicht.

    meine frage: gibt es eine moeglichkeit, abzufragen wann ein seek ausgefuehrt worden ist? ein callback oder so scheint es ja nicht zu geben.

    danke.