StartupToStandby mit erweiterter Funktion - StartupToIdle für DreamOS

  • dre

    So mache ich es ja schon.


    Die Box geht in den Standby und ein Checkfile wird gelöscht.

    Ist es beim Start noch da, war es kein sauberes Herunterfahren.


    Das Problem ist ja herauszufinden, ob nach dem sauberen Herunterfahren ein Stromausfall ist (also im Standby/DeepStandby).

    In diesen Zustand ist die Box ja sauber heruntergefahren und hat auch das Checkfile gelöscht und hätte auch den Wert auf True gesetzt.

    Man bräuchte im Standby (DeepStandby) einen flüchtigen Wert, der nur nach Stromausfall verlorengeht, so wie der Inhalt des rtc-Files im OE2.6.


    Spaeleus

    Thank you, i had already wondered why it is not translated :winking_face:

    Gruß Sven (aka Dreamy)


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

    Einmal editiert, zuletzt von Sven H ()

  • Idle und Betrieb ist kein Problem.

    Das ist logisch schon umgesetzt.


    Das Problem ist nur der Stromausfall im DeepStandby unter OE2.5.

    Wenn man die standby.chk beim Schalten in den DeepStandby erstellt, ist diese beim Start ja immer noch da, auch wenn es im DeepStandby einen Stromausfall gibt. Also kann man das nicht erkennen.


    Oder hab ich deinen Vorschlag nicht verstanden ? :winking_face:

    Gruß Sven (aka Dreamy)


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

  • Ich habe da noch einen Denkfehler. Ich habe den Beitrag wieder gelöscht weil ich zu vorschnell in die Tasten haute


    Irgend etwas klingelt da bei mir, aber vielleicht irre ich mich auch

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

  • Ja, man bräuchte einen flüchtigen Speicher, der sich nur nach Stromausfall löscht.

    /tmp löscht sich ja schon beim Schalten in den standby bzw. beim reboot, so dass man das dafür nicht nehmen kann.


    Aber im DeepStandby ist ja nur noch der FrontProzessor aktiv.

    Also müsste man dort etwas temporär ablegen können, was dann erst nach einem Stromausfall weg wäre.

    Aber dafür habe ich noch keine Lösung gefunden.


    Edit:

    Vielleicht gibt es ja auch ein File in /sys oder /proc, was nach Stromausfall einen anderen Wert hat, als bei einem reboot ??

    Gruß Sven (aka Dreamy)


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

    Einmal editiert, zuletzt von Sven H ()

  • Sven H

    Hat den Titel des Themas von „StartupToStandby mit erweiterter Funktion“ zu „StartupToStandby mit erweiterter Funktion - StartupToIdle für DreamOS“ geändert.
  • Hier mal ein erster Versuch eines Installationspaketes für das neue Plugin "StartupToIdle" für DreamOS :winking_face:

    Bei der Installation sollte das bereits installierte StartupToStandby automatisch ersetzt werden.

    (dadurch sollte es bei einem DP-Update kein Problem mehr geben, dass die angepassten Files im StartupToStandby-Ordner wieder mit der Original-Version überschrieben werden)


    Edit:

    Diese Version sollte auch wieder im OE2.5 funktionieren (allerdings wird dort ein Stromausfall im Standby nicht erkannt).

  • Hehe,

    jetzt ist es mir wieder eingefallen, wie man das prüfen kann


    es wird ja im Betrieb ständig in das proc file system geschrieben, d.h. auch die Dateiattribute wie ctime werden ständig aktualisiert. Vielleicht kann man das zunutze machen, dass die OE2.5 Boxen keine hardware clock haben.

    Wenn man die Box in den deepstandby schickt (auch mit shutdown -h now) bleibt die ctime im proc file system erhalten. D.h. die letzte Änderungszeit bleibt erhalten und wird erst überschrieben, wenn sich die Box die aktuelle Zeit wieder vom Zeitserver oder Transponder geholt hat und wieder ins proc file system geschrieben wurde.


    Bei einem reboot oder GUI Neustart oder stromlosen zustand wird die ctime des Odners auf Unixzeit zurückgesetzt


    Warum auch beim reboot kann ich nicht sagen.



    Ich hab mir dann den folgenden command in meine rc.local eingebaut, um die ctime von /proc/stb/fp beim bootup in ein temp file zu schreiben

    ls -ald --time-style long-iso /proc/stb/fp > /tmp/proc_stb_fp


    nach dem Aufwecken aus dem (deep)standby sieht das so aus - die letzte change time bleibt also erhalten

    nach Standby über die GUI oder das Web-IF, oder nach

    shtudown -h now

    systemctl poweroff


    Code
    root@dm900:~# cat /tmp/proc_stb_fp 
    dr-xr-xr-x 2 root root 0 2022-01-22 15:05 /proc/stb/fp
    root@dm900:~# 


    Nach einem bewussten stromlos machen oder einem Stromausfall und bei einem reboot/Neustart wird die ctime zurückgesetzt und es wird die Uhr auf die Unixzeit gesetzt: 01.01.1970 00:00 UTC


    d.h. nach dem Start aus einem stromlosen Zustand oder reboot sieht das so aus

    Code
    root@dm900:~# cat /tmp/proc_stb_fp 
    dr-xr-xr-x 2 root root 0 1970-01-01 01:00 /proc/stb/fp
    root@dm900:~# 


    d.h. das Datum 01.01.1970 ist ein Indikator für einen stromlosen Vorzustand - warum auch immer dieser eingetreten ist.

    Wenn das ctime Jahr von /proc/stb/fp 1970 ist UND das reboot.chk file vorhanden ist, war es ein geplanter Neustart

    Wenn das ctime Jahr von /proc/stb/fp 1970 ist UND das standby.chk file vorhanden ist, hatte die Box im standy einen Stromausfall

    Wenn das ctime Jahr von /proc/stb/fp nicht 1970 ist UND das standby.chk file vorhanden ist, hatte die Box im standy keinen Stromausfall
    usw.

    Ob das für das Plugin nutzbar ist kann ich nicht sagen. Hängt wohl davon ab wie schnell sich die Box über eine Zeitserver oder der Transponderzeit die aktuelle Zeit holt und die ctime des Beispielordners im proc filesystem aktualisiert wird.

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

    3 Mal editiert, zuletzt von Fred Bogus Trumper ()

  • Danke für den Denkanstoß. :thumbs_up:


    Muss ich Abend mal schauen, ob der Pluginstart da schnell genug erfolgt, oder ob die ctime im /proc/stb/fp dann schon wieder korrekt ist.


    Wenn das nicht geht, muss ich mir das mal mir der rc.local anschauen. Vielleicht kann man darüber ja ein statusfile anlegen lassen, was das Plugin dann beim Start ausliest.

    Aber mit sowas hab ich mich bisher noch gar nicht befasst :winking_face:

    Da hätte ich dann bestimmt noch weitere Fragen.

    Gruß Sven (aka Dreamy)


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

  • das funktioniert auch bzw. kann man mit der rc.local viel machen - ich habe da einiges eingebaut, dass im Linux Unterbau greift


    wenn die Zeit über die Transponderzeit geholt wird hast du vermutlich genügend Zeit. Wenn die Zeit über einen Zeitserver gesynct wird, kann ich nicht sagen ob sich das ausgeht


    ich hole mir die aktuelle Zeit beim bootup mit rdate über die rc.local, die ctime habe ich in der rc.local vorher ausgelesen. d.h. wenn die rc.local ausgeführt wird hat die Box vermutlich in keinem Fall die aktuelle Zeit.


    Über die Settings kannst zumindest rausfinden ob die Transponderzeit aktiviert ist oder nicht

    Code
    root@dm7080:/# grep -i TransponderTime /etc/enigma2/settings
    config.misc.useTransponderTime=false
    root@dm7080:/# 


    Bin mir aber jetzt nicht 100% sicher ob das auch im Originalimage greift, nutze ein alternatives OE2.5 Image


    alternativ könntest du ein eigenes systemd service basteln, nicht jeder hat das rc-local.service aktiviert

    IHMO ist das service by default deaktiviert und die rc.local muss auch manuell erstellt werden


    mir fällt gerade ein, die Zeit MUSS irgendwo gespeichert werden bzw. weiterlaufen. Woher weiss die Box sonst ohne Hardware Clock wann sie wg. eines Timer Events im Standby aufwachen muss?


    Das erklärt vielleicht auch, warum bei reboot die ctime nicht behalten wird: weil nicht notwendig


    Ich such mal im sys ...

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

    5 Mal editiert, zuletzt von Fred Bogus Trumper () aus folgendem Grund: Ein Beitrag von Fred Bogus Trumper mit diesem Beitrag zusammengefügt.

  • Ich bin vielleicht einen Schritt weiter:

    es wird ja nicht nur die ctime der Dateien im proc filesystem behalten sondern auch deren Inhalte wenn die Box aus dem deepstandby hochfährt


    z.B. /proc/net/dev

    hier werden rx, tx und pakete der Netzwerkschnittstellen geschrieben

    nach einem reboot oder stromlosen Zustand wird der Zähler auf 0 gesetzt


    über einen command in der rc.local beim bootup ausgelesen, da sieht man schön, dass eth0 0 bytes bzw. pakete empfangen oder gesendet hat

    Code
    Inter-|   Receive                                                |  Transmit
     face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
        lo:     140       2    0    0    0     0          0         0      140       2    0    0    0     0       0          0
      eth0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0


    die Werte gehen dann natürlich sofort hoch, wenn das Netzwerk aktiv wird



    aus dem deepstandby sieht es dann z.B. so aus


    Code
    Inter-|   Receive                                                |  Transmit
     face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
        lo:    4409      53    0    0    0     0          0         0     4409      53    0    0    0     0       0          0
      eth0: 14578254   10818    0   12    0     0          0         0   196263    2446    0    0    0     0       0          0


    die rx/tx Werte eignen sich vermutlich nicht zum Rechnen, weil die Zähler irgendwann wieder bei 0 beginnen soweit ich weiß


    jetzt müsste man nur noch ein file im proc file system finden, indem etwas hochgezählt wird mit dem man Arbeiten kann und bei ein reboot auf 0 gesetzt wird und aus dem deepstandby den Inhalt behält


    dann könnte man im python die Datei auslesen und aus dem Wert ersehen ob es ein reboot oder boot aus dem deep standby war - dann kann das auslesen vor dem enigma2 Start im OS komplett wegfallen


    etwa nach dem Prinzip:

    wenn die paketanzahl der schnittstelle lo größer als 100 ist kommt die Box aus dem Deepstandby, wenn der Wert kleiner als 100 ist, war es ein Reboot wenn die Datei standby.chk nicht existiert oder die Box war stromlos wenn die Datei standby.chk existiert

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

    Einmal editiert, zuletzt von Fred Bogus Trumper ()

  • Danke Fred :thumbs_up:


    Ich glaube, das mit der ctime könnte was werden :winking_face:


    Kannst du bei deiner dm900 mal schauen, was für eine ctime bei dir "/etc" nach stromlos hat ?

    Und dann gegenprüfen, was ctime bei einem normalen Start aus dem DeepStandby und was bei einem GUI-Neustart hat.


    Auf meiner dm900 ist die ctime von "/etc" nach stromlos immer von 1970.

    Nach normalen Start aus dem DeepStandby, Reboot oder GUI-Neustart ist da immer die aktuelle Zeit.


    Ist dann nur die Frage, wie das bei den anderen OE2.5-Boxen ist ???

    Gruß Sven (aka Dreamy)


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

  • zu welchem Zeitpunkt liest du ctime von /etc aus?

    Das kann ich leider nicht bestätigen, der Ordner /etc hat hier immer eine aktuelle Zeit, also nie das Jahr 1970 - egal ob nach reboot, aus standby oder nach stromlosen Zustand - immer über die rc.local automatisch beim boot ausgelesen, sogar mehrmals nach reboot und stromlosem Zustand


    Wie es aussieht, bleibt die letzte ctime von /etc erhalten, wird aber dann irgendwann beim bootup überschrieben


    nach /tmp/etc wurde die ctime von /etc über die rc.local geschrieben, der 2. command etwas später manuell. Beides nach stromlosen Zustand ausgeführt


    Code
    root@dm900:~# cat /tmp/etc 
    drwxr-xr-x 57 root root 4096 2022-01-22 22:49 /etc
    root@dm900:~# ls -ald --time-style=long-iso /etc
    drwxr-xr-x 57 root root 4096 2022-01-22 23:10 /etc
    root@dm900:~# 


    Aber meine Box ist sicher nicht die Referenz. Dazu habe ich schon viel zu viel im Linux Unterbau herumgeschraubt und hole mir die aktuelle Zeit sehr früh von einem Zeitserver und mein Image ist am Software stand vom 30.5.2019 ...


    das proc filesysstem wird beim booten dynamisch erzeugt und ist scheinbar nach reboot oder stromlosen Zustand weg - aber nicht, wenn die Box vom frontprozessor gestartet wird


    ich habe mir in der Zwischenzeit ein systemd service gebaut, dass beim bootup vor dem Netzwerkstart die Paketanzahl des inferface lo aus /proc/net/dev ausliest. Das hat bisher zumindest jeden boot aus dem standby erkannt. Wenn lo packages < 5 wurde sie entweder neu gestartet oder war stromlos, wenn größer kommt sie aus dem standby


    die ctime von /proc/stb/fp müsste auch reichen, wenn sie nicht zu früh nach dem start aktualisiert wird

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

  • Ich habe das nach dem kompletten Start der Box über telnet ausgelesen:

    Code
    root@dm920:/# cd / && ls -la | grep etc
    drwxr-xr-x  47 root root 4096 Jan  1  1970 etc
    
    oder:
    
    root@dm920:/# ls -ald --time-style=long-iso /etc
    drwxr-xr-x 47 root root 4096 1970-01-01 01:00 /etc

    Und wie sieht das bei dir mit "/dev" aus ?

    Code
    root@dm920b:/# cd / && ls -la | grep dev
    drwxr-xr-x  16 root root 3300 Jan  1  1970 dev

    Da habe ich sowohl auf der 920 als auch auf der One das Datum von 1970, wenn die Box nach stromlos startet.

    Das bleibt dann auch so bis zum nächsten Reboot.

    Gruß Sven (aka Dreamy)


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

  • /dev hat immer 1970-01-01 - auch nach stundenlangem Betrieb


    enigma2 schreibt ständig nach /proc/stb/fp - deshalb ändert sich die ctime laufend - das ist bei /dev nicht so.


    die ctime von /proc/stb/fp wird beim reboot oder stromlos machen auf 1.1.1970 zurückgesetzt weil das proc filesystem neu erstellt wird und dann beim 1. Schreibvorgang durch enigma2 ausgelöst wieder aktualisiert wird. Vermutlich wird die ctime nicht verändert, wenn die Zeit beim Schreibvorgang vor der cdtime liegt. Nachdem booten aus dem deepstandby entspricht die ctime der Zeit des letzten Schreibvorganges vor dem shutdown, ist also nicht von 1970, solange die Box vor dem shutdown sich mind 1x die aktuelle Zeit geholt hat.


    man könnte auch die ctime von /proc/net/dev verwenden, weil in die Datei ständig aktualisiert wird. Auch bei traffic über das loopback interface (lo) - also auch dann, wenn die box nicht im Netzwerk hängt

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

    2 Mal editiert, zuletzt von Fred Bogus Trumper ()

  • immer ??

    Nur nach stromlos-Start oder auch nach normalem reboot ?


    Bei mir hat "/dev" nur nach stromlos 1970.

    Mache ich danach einen Reboot hat "/dev" dann die aktuelle Zeit.


    Vielleicht arbeiten meine Boxen auch komplett anders :winking_face:


    Und /proc/stb/fp hat bei mir beim Pluginstart immer die aktuelle Zeit.

    Auch beim Start nach stromlos.

    Vermutlich ist der Zeitpunkt des Pluginstarts zu spät dafür.

    Gruß Sven (aka Dreamy)


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

    6 Mal editiert, zuletzt von Sven H ()

  • Teddy01

    Danke für die Rückmeldung :thumbs_up:

    Auf der One/Two (OE2.6) funktioniert es auch schon prima (inkl. der Erkennung einer Stromunterbrechung im DeepStandby).


    Leider funktioniert diese Stromunterbrechungserkennung im DeepStandby nicht unter OE2.5, weshalb wir da noch auf der Suche nach einer passenden Lösung sind :winking_face:

    Gruß Sven (aka Dreamy)


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

    Einmal editiert, zuletzt von Sven H ()

  • Hab in Post #1 mal eine Version 1.1 zusätzlich zum Test hochgeladen.


    Änderungen in Version 1.1:

    - jetzt mit Stromunterbrechungserkennung auf der dm9x0 (auf der dm820 und dm7080 sollte es auch in Version 1.0 schon funktioniert haben)

    - auf der Info-Taste im Setup kann man sich den letzten Plugin-Startlog anzeigen lassen (ggf. zur Fehleranalyse)

    - neue Setup-Option zum Festlegen der Start-Option beim manuellen Restart (active (default), idle, last state)

    - neue Setup-Optionen zur Debug-Ausgabe (Ausgabe in der Console und Erstellen eines Startlogs in /tmp)


    changelog in version 1.1:

    - support to check for power cut on dm9x0 (on dm820 and dm7080 should it works already in version 1.0)

    - on info-key in setup you can show the last pluginstartlog (for error analyse)

    - new setup-option to set the startoption on manual restart (active (default), idle, last state)

    - new setup-options for debug output (output in console and create startlog in /tmp)

    Gruß Sven (aka Dreamy)


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

  • Just tested on my 920.

    Simulated power failure with active box:

    Simulated power failure with box in idle mode:

    Great work! :thumbs_up:

    DM 920UHD - DM Two - DM One - DM 7020HD-v2 - DM 7020HD