Beiträge von willi.neu9

    Hallo John,


    wenn das Plugin "StartupToStandby" die Box nur in den Idle Mode versetzt hilft

    dir das in Punkto Stromverbrauch fast nichts, da im Idle Mode der Main Prozessor der Box

    eingeschaltet bleibt. Der wird nur im Deep Standy Mode komplett abgeschaltet und die

    Stromaufnahme der Box sinkt auf nur noch 3 mA (direkt an der 12 Volt Buchse der Box

    gemessen).


    Für Dein Problem sehe ich die folgenden einfachen Möglichkeiten:


    1.)

    Wenn die WLAN Steckdose immer zur selben Zeit eingeschaltet wird, dann kannst

    Du Dir einfach einen in der Box bereits vorhandenen wiederholenden Umschalttimer

    programmieren der nach dem Hochfahren der Box diese wieder zurück in den Deep

    Standby Modus bringt.


    Hier ein Beispiel:



    2.)

    Wenn ein Rechner die WLAN Steckdose schaltet, dann kannst Du der Box ein Kommando

    über Telnet schicken, dass Sie nach dem Einschalten wieder herunterfährt. In der Windows

    Welt gibt es z.B "plink.exe", das zum Putty Paket gehört (https://www.putty.org/) das Du hierfür

    in einem Batchfile nutzen könntest. Wenn dies ein Lösung für Dich ist schick ich Dir ein Beispiel

    mit plink.exe.


    3.)

    Wenn Die ein Elektronik Bastler bist, dann kannst Du Dir mit nur wenigen Bauteilen eine

    Micro Controller Lösung bauen, die nach dem Einschalten der WLAN Steckdose per Infrat Rot

    ein Shutdown Kommando an die Box sendet um die nach der Stromeinschaltung wieder

    herunter zufahren Da hätte ich auch einen Lösungsansatz für Dich unter Zuhilfenahme eines

    MicroChip Micro Controllers.


    /Willi/

    Manche Settings Menüs für die Plugins wie:


    "HbbTV" aus dem Erweiterungsbereich: Multimedia oder

    "Automatic Timerlist Cleanup" aus dem Erweiterungsbereich: System

    werden nur sichtbar wenn sie aus dem Menü: "services_recordings"

    aufgerufen werden, das ich bisher allerdings in der ONE noch nicht gefunden habe.


    Bisher habe ich mir so geholfen, indem ich die Zeile z.B. in:


    /usr/lib/enigma2/python/Plugins/SystemPlugins/AutomaticTimerlistCleanup/plugin.py

    Code
    def startSetup(menuid):  
            if menuid != "services_recordings": # show setup only in system level menu
                    return []
            return [(_("Automatic Timerlist Cleanup Setup"), setup, "automatictimerlistcleanup", 46)

    in:


    Code
    def startSetup(menuid):  
            if menuid != "system": # show setup only in system level menu
                    return []
            return [(_("Automatic Timerlist Cleanup Setup"), setup, "automatictimerlistcleanup", 46)

    geändert habe. Damit waren Sie dann im "system" Menü sichtbar und auch von dort aufrufbar.


    Oder weiß jemand mit welchen FB Tastendrücken das "services_recordings" Menü aufrufbar ist?


    /Willi/

    Ich hatte inzwischen ca. 10 Dreambox ONE hier zu Testzwecken.

    Alle zeigten den Fehler, dass sie sporadisch beim Runterfahren in den Deep Standby Modus

    hängen blieben und ein Power Off / On zum Neustart benötigten.


    Das ist meines Erachtens ein SW Bug, der selten auftritt und von daher von vielen

    bisher nicht bemerkt wurde. Aber jede ONE und TWO hat ihn.


    /Willi/

    Vor ca. einem Jahr habe ich die Nanny für die ONE aber auch notwendig für die TWO gebaut,

    die die ONE neu startet wenn Sie beim Runterfahren in den Standby hängen bleibt.


    Siehe hierzu auch hier auf dem Board:

    Eine Nanny für die ONE und TWO - oder der steinige Weg zur grünen Box - oder

    Jetzt "Nanny on Board" für die ONE und TWO


    Mit der Nanny bin ich äußerst zufrieden. Bisher hat sie die Box erfolgreich das letzte Jahr am Leben

    erhalten ohne dass ich sie händisch neu booten musste.


    Jetzt dachte ich durch Aufspielen des Images: "dreambox-image-dreamone-20220224.tar.xz"

    wäre der Fehler beseitigt worden und ich könnte die Nanny in Rente schicken.


    Aber dieser Bug ist geblieben - wie ich bereits erwartet habe.


    Dies nur als kurzer Erfahrungsbericht!


    Gruß


    /Willi/

    warp760,


    falls Du das IR Einschaltproblem immer noch hast, kann ich Dir nur empfehlen:


    Besorge Dir mindestens 3-5 Boxen. Nach meiner Erfahrung (siehe Nachricht #1)

    ganz oben aus diesen Thread haben offensichtlich viele der Boxen bei erhöhter

    Umgebungstemperatur ein IR Wiedereinschaltproblem. Dabei reicht oftmals schon

    die Eigenerwärmung der Box im Normalbetrieb.


    Darum folgender Tipp:

    [Moderator] Solche, vermeintlich rechtlich unzulässigen, Vorschläge sind nicht akzeptabel![/Moderator]


    Meine FW Version: dreambox-image-dreamone-20210324.tar.xz

    Frontprozessor Version 1.12


    /Willi/

    Das der Dream Property Fix mit einem ZDF Mediathek Fix zusammenfällt ist sehr unwahrscheinlich..

    Meine Vermutung ist eher, das es zwischen dem HbbTV Dienst der Box und den Mediathelen noch

    einen Server gibt der die Anfragen der Boxen an die Mediatheken weiterleitet und das in diesem was

    gefixt wurde.


    Zum Beispiel findet sich in der Box an keiner Stelle die Mediathek Adresse: "https://www.zdf.de/"

    mit der die Box die ZDF Mediathek direkt ansteuern könnte?


    Diese Auflösung muss woanders außerhalb der Box passieren?

    Aber wo?


    /Willi/

    Es gibt für die ONE und wahrscheinlich auch für die TWO ein neues Image

    "dreambox-image-dreamone-20211025.tar.gz" mit der Begründung, dass in diesem

    primär der ZDF Mediathek Bug gefixt wurde. Zusammen mit dem Bug konnten Filme aus

    der ZDF Mediathek zwar noch angewählt aber nicht mehr gestartet werden.


    Dieser Bug wurde behoben. Erstaunlicherweise musste dafür aber das neue Image

    nicht installiert werden.


    Das heißt der Bug lag gar nicht innerhalb des Dreambox Image, sondern irgendwo

    außerhalb. Darum interessiert mich was das für ein Bug war und wie der außerhalb

    der Box gefixt werden konnte?


    Ich vermute mal an der ZDF Mediathek selbst lag es nicht.


    /Willi/

    Der Zugriff auf die ZDF Mediathek läuft wieder, ohne dass hierfür ein Image Update notwendig wurde.

    Läuft hier mit Image Experimental 2021-09-22 mit abgeschalteter automatischer Aktualisierung.

    Was mich doch wundert, da es in der ZDF Mediathek wohl keine zum Fix zeitgleiche Änderungen gab.


    Greift die Dreambox nicht direkt auf die ZDF Mediathek oder andere Mediatheken zu?

    Sondern gehen HbbTV Anfragen ersteinmal auf einen Zwischenserver der die Anfragen dann

    an die entsprechende Mediathek weiterleitet?


    Falls ja, hat dieser Server noch für Zusatzaufgaben, z.B.:Tracking???


    /Willi/

    Alphas shutdown / power down script "enigma2-system-state"


    Ich habe das modifizierte "/usr/bin/enigma2-system-state" script von alpha mal ausprobiert

    indem ich mein timer test script (siehe Nachricht #6 aus diesem Thread) mal über 2 Tage habe

    laufen lassen (insgesamt fast 1000 Power Offs / Restarts).


    Und was soll ich sagen. Die Box ist beim Shutdown nicht ein einziges mal hängen geblieben.

    Das spricht eindeutig für diese Änderung!


    Was allerdings schon beim Beobachten der Box auffiel. Das Runterfahren mit anschließen-

    dem Power Off braucht viel weniger Zeit als beim Original Script.


    Die Ursache sieht man wenn man sich die LOGS bei ungeänderten und modifizierten Script

    mal ab Shutdown Start ansieht.


    Vergleicht man beide LOGS (entnommen der USB Debug Schnittstelle der Box (siehe An-

    hänge)), dann sieht man, das ein Großteil der Prozesse nicht mehr regulär beendet wird.

    Das stört bei den meisten der Prozesse wahrscheinlich nicht, da diese beim erneuten

    Start der Box wieder sauber hochgefahren werden.


    Bei einigen ist dies wahrscheinlich schon kritischer. Nämlich bei solchen die eine Verbindung

    zur Außenwelt haben. Netzwerkprozesse z.B. wie der SMB. Hier hat der Prozess nämlich

    keine Möglichkeit mehr die Verbindung zu einem externen Server korrekt zu schließen.


    Ob das im wahren Leben tatsächlich ein Problem ist, kann ich nicht beantworten. Dafür bin

    ich zu wenig Linux Spezialist. So richtig wohl würde ich mich aber bei einer dauerhaften

    Scriptänderung nicht fühlen.


    Wenn Alpha mit den Änderungen keine nachteiligen Erfahrungen gemacht hat, spricht nichts

    dagegen sie weiter zu verwenden. Es ist auf jeden Fall eine einfache Möglichkeit diesen power

    down crash zu umgehen.


    Ich bleibe aber sicherheitshalber bei meinen Nannies.


    /Willi/


    PS: Was man aber auch sieht ist, dass einer der durch das reguläre Script beendeten Prozesse

    für den gelegentlichen Kommunikationsverlust zwischen Main - und Frontprozessor verantwortlich

    sein muss. Die Frage ist nur: Welcher?

    @max95100


    The RC20 has no learn mode. The chance to control your projector using the RC20 is really very low.

    My Tip: Buy a RC10 that has a learn mode. So you can dublicate the code from origial remote control to the RC10

    and forget the RC20.


    /Willi/

    Ich fasse die Diskusion, die in weiten Strecken sicherlich am Thema vorbeigeht, mal kurz zusammen.


    Eine andere Lösung als der Nanny den Crash Restart zu überlassen (außer man will es händisch machen)

    scheint es wohl, wenigstens zum jetzigen Zeitpunkt, nicht zu geben. Ich wage da mal eine Prognose:

    Wird es wahrscheinlich auch nie geben. (Zugegeben, der Fehler ist sicherlich schwer zu finden und liegt

    meines Erachtens auch nicht am "systemd", sondern ist ein Kommunikationsproblem zwischen Front- und

    Mainprozessor).


    Ich werde meine beiden Nannies wohl weiterhin mit Strom durchfüttern müssen.

    Das Gute: Sie sind sehr genügsam!


    Damit sehe, zumindest für mich, diesen Thread als beendet an!


    /Willi/

    Die Nanny schreitet erst dann ein wenn es nichts mehr zu retten gibt! D.h wenn der Mainprozessors nur noch

    ein Crash Log ausgibt (siehe hierzu auch das LOG aus dem Thread "Eine Nanny für die ONE und TWO").

    Wenn Du eine wirklich funktionierende SW Lösung für das Problem kennst - her damit.


    Da schicke ich gerne - wie schon geschrieben - die Nanny sofort in Rente.


    /Willi/

    Die Nanny ist mein Weg das Shutdown Problem zu lösen. Mir wäre es auch wesentlich lieber

    DP würde da einen Fix haben. Aber auch in der Dreambox ONE FW Version 2021.09.22 steckt

    der Fehler immer noch, obwohl das Problem DP seit minestens einem halben Jahr bekannt ist.


    Da zu warten ob und wann der Fehler mal beseitigt wird dauerte mir einfach zu lang.


    Wen dieser Fehler in der ONE und TWO nicht stört oder vielleicht auch gar nicht hat, kann den

    Thread ja einfach ignorieren. Für die Anderen ist es eine Möglichkeit nicht mehr selbst auf seine

    Box aufzupassen zu müssen.


    Wenn jemand eine wirklich funktionierende andere Lösung ohne Nebenwirkungen hat - her damit.

    Gerne schick ich dann die Nanny in Rente.


    /Willi/

    Wie bereits in meinem Thread "Eine Nanny für die ONE und TWO" beschrieben kann man

    sich nicht darauf verlassen, dass die ONE oder TWO erfolgreich in dem Deep Standby Mode

    herunterfährt. Man muss immer damit rechnen, dass Sie dabei hängen bleibt und crashed.


    Aus dem Crash Zustand kann man Sie dann nur noch befreien, wenn man die Stromzufuhr zur

    Box stoppt und danach wieder aktiviert.


    Da zumindest ich nicht davon ausgehe, dass dieser Bug irgendwann mal gefixt wird, hab ich

    der Box eine Nanny gebaut die den dann notwendig Neustart der Box automatisiert. Sie wird

    einfach zwischen Netzteil und Box geklemmt.


    Eine 2 Nanny nochmals auf einer Lochrasterplatine aufbauen wollte ich dann doch nicht. Darum

    gibt es jetzt ein Board für die Nanny. Bei Interesse ist sie auch für andere nun einfacher nachzubauen.


    Nähere Daten (Stromlauf, Board Daten, Fotos, Datenblätter, Firmware, Tipps zum Nachbau)

    gibt es hier:


    Nanny_On_Board_V1.00.zip


    Hier noch ein paar Fotos zur neuen Nanny:


                



    /Willi/

    alpha


    systemctl ist wahrscheinlich nicht der Schuldige. Denn die LOG Meldung "fp_power_off" kommt aus

    den Kernelmodul "/lib/modules/4.9/extra/fp/fp-dev.ko", dass auch aufgerufen wird wenn man ein

    "echo o > /proc/sysrq-trigger" ausgibt. Das ist genau das was systemctl auch erfolgreich macht,

    sonst käme die Meldung "fp_power_off" nicht vor dem Crash.

    Ich vermute mehr ein Kommunikationsproblem zwischen dem Kernelmodul und dem Frontprozessor.

    Ist aber auch von meiner Seite nur eine Spekulation, da auch schon vorher im Main System irgendwas

    passiert sein kann, was dazu führt, dass das Kernel Modul nicht mehr richtig funktioniert.


    /Willi/

    Hallo Alpha,


    nur zu meinem Verständnis:


    Code
    "system-standby")
    echo "powering off..." >> /data/log.txt
    #			systemctl --no-block poweroff
    #			systemctl --force --force poweroff
    echo o > /proc/sysrq-trigger
    ;;

    Waren bei Deinem letzten Test:


    # systemctl --no-block poweroff

    # systemctl --force --force poweroff


    auskommentiert?


    Und zur Befriedigung meiner Neugierde:


    Wie bist Du auf den Befehl gekommen:


    Code
    echo o > /proc/sysrq-trigger


    Die anderen möglichen Befehle konnte ich dann durch die Eingabe von:


    echo a > /proc/sysrq-trigger


    rausfinden. Die Ausgabe erfolgte am USB Service Ausgang der Box:


    SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m)

    nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dis intr to riggger wdt rst(x) dump-ftrace-buffer(z)


    /Willi/

    Hallo Alpha,


    Schaut man sich mal das Dreambox LOG an:


    Hier eine Kopie aus dem Thread: "Eine Nanny für die ONE und TWO":


    [ 102.882849@2] fb: osd_shutdown

    [ 102.883215@2] amvdac_drv_shutdown: shutdown module, private_flag:0x0

    [ 102.883986@0] reboot: Power down

    [ 102.884280@0] fp_power_off

    [ 102.987219@0] fp_write_cmd(33) timeout...

    [ 102.987241@0] fp: com reset...

    [ 103.007767@0] fp: command retry

    [ 120.171199@0]

    [ 120.171199@0]

    [ 120.171199@0]

    [ 120.171199@0] HARDLOCKUP____ERR.CPU[1] <irqen:0 isren1>START

    [ 120.171780@0]

    [ 120.171780@0] dump_cpu[0] irq: 3 preempt:10001 swapper/0

    [ 120.172606@0] IRQ arch_timer_handler_phys, 10000

    [ 120.173129@0] Task dump for CPU 0:

    [ 120.173520@0] swapper/0 R running task 0 0 0 0x00000000

    [ 120.174349@0] Call trace:

    [ 120.174654@0] [ffffffc0746f1c40+ 112][<ffffff800908b688>] dump_backtrace+0x0/0x250

    [ 120.175521@0] [ffffffc0746f1cb0+ 32][<ffffff800908b95c>] show_stack+0x24/0x30

    [ 120.176352@0] [ffffffc0746f1cd0+ 32][<ffffff80090dce9c>] sched_show_task+0x134/0x180

    [ 120.177251@0] [ffffffc0746f1cf0+ 32][<ffffff80090dfc48>] dump_cpu_task+0x48/0x58

    [ 120.178113@0] [ffffffc0746f1d10+ 112][<ffffff8009b6c50c>] pr_lockup_info+0x174/0x220


    Dann sieht man folgendes:


    Der Frontprozessor der Box macht das Powermanagment. Er kann dem Hauptprozessor

    die Stromzufuhr kappen und per Timer oder IR Befehl wiedergeben.


    Als welchen Gründen auch immer verliert der Hauptprozessor manchmal den Kommunikations-

    weg zum Frontprozessor:


    Siehe hier:


    [ 102.882849@2] fb: osd_shutdown

    [ 102.883215@2] amvdac_drv_shutdown: shutdown module, private_flag:0x0

    [ 102.883986@0] reboot: Power down

    [ 102.884280@0] fp_power_off

    [ 102.987219@0] fp_write_cmd(33) timeout...

    [ 102.987241@0] fp: com reset...

    [ 103.007767@0] fp: command retry


    Der Hauptprozessor sagt zum Frontprozessor: "Power_off", aber der hört's nicht!


    Erst danach erfolgt der Crash.


    Das lässt sich über Dein --forced Shutdown wahrscheinlich nicht umgehen. Das Hängelbleiben

    beim Runterfahren wird wohl bleiben.


    Schaut man sich die Dreambox LOGs mal näher an. (ich habe die mal über mehrere Monate

    gemacht), dann fällt auf, dass die Kommunikations zum Frontprozessor nicht nur beim "power_off"

    hakt sondern auch wenn eine neue Aufweckzeit in diesen geschrieben werden muss. Machmal

    klappt es durch ein Retry aber auch nicht immer.


    Das kommt zwar wirklich selten vor, aber zu 100% funktioniert die Kommunikation zwischen den

    beiden eben nicht.


    Da einige davon berichten, dass der Shutdown Fehler bei Ihnen noch nie aufgetreten ist, kann

    es auch ein HW Fehler sein.


    Ich habe inzwischen 6 Boxen vom typ ONE ausprobiert und eine TWO. Bei allen ist der Shutdown

    Fehler aufgetreten.


    Meine Nanny wird wohl auch weiterhin einen Job haben.


    /Willi/