Posts by willi.neu9

    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/

    Hallo alpha,


    bin mal gespannt auf Deine Langzeiterfahrung mit deinem Patch.

    Schöner wäre natürlich ein offizieller Bugfix von DP.

    Nach der Meldung des Shutdown crashs an DP vor ca. einem 1/2 Jahre, habe ich nur die Rückmeldung

    erhalten, dass diese an die Entwickler weitergeleitet wurde. Passiert ist aber nichts. Der Bug ist auch

    noch in der neusten FW Version der ONE und TWO enthalten.


    Wenn Du willst, kannst Du Deinen Fix ja mal unter Realbedingungen weiter testen:


    Das anhängende Script: "timers.py" das man auf der ONE laufen lassen kann und das eine "etc/enigma2/timers.xml"

    erstellt, löst einen wiederkehren Programmwechsel und Neustart der Box per Timer aus.


    Diese timers.py muss man aber in Punkto "ServiceRef" evt. anpassen.


    timer.py erwartet, dass man in


    /usr/lib/enigma2/python/mytest.py


    die Timer Hochlaufzeit verkürzt.


    Wenn man dies nicht will kann man in timer.py das Delay2 auf 270 Sekunden vergrößern.

    Hat dann aber weniger Tests / Zeiteinheit.


    Bin mal gespannt auf die Ergebnisse. Vielleicht kann ich ja dann bereits wieder auf die Nanny verzichten!

    Wäre natürlich Schade um die viele Arbeit die ich mit Ihr hatte!


    /Willi/

    Die Dreambox ONE oder TWO bei nicht Gebrauch in den Standby Modus zu setzten bringt in Punkto Stromverbrauch fast nichts.

    Dieser verringert sich dabei lediglich um ca. 10% (gemessen direkt an der Box). Da ist der Deep Standby Modus bei dem der

    Hauptprozessor inklusive USB Peripehrie komplett abgeschaltet wird schon wesentlich effizienter. Hier beträgt die Strom-

    ersparnis schon mehr als 99%. Die Stromaufnahme sinkt von ca. 600 mA bei 12 Volt auf etwa 3 mA.


    Leider kann man sich nicht darauf verlassen, dass ein Deep Standby bei der ONE oder TWO immer funktioniert. Egal ob dieser per

    Fernbedienung oder per Timer ausgelöst wurde. Bei gefühlt jedem 50 Shutdown bleibt die Box bei runterfahren (wie auch DP bereits

    vor ca. einem halben Jahr mitgeteilt) hängen.


    Bug inzwischen durch DP gefixt? -> NO!! (Seufz)


    Ein LOG genommen vom USB-Service Ausgang der Box zeigt den Grund:


    [ 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


    Um Die Box aus dem Crash Zustand zu befreien hilft nur noch: Strom abschalten, für ca. 3 Sekunden zu warten und danach die Box

    wieder einzuschalten.


    Da ich nicht davon ausgehe, dass dieser Fehler jemals gefixt wird, und ich auch nicht auf Dauer die Nanny für die Box sein möchte,

    habe ich der ONE eine Nanny gebaut, (wäre für die TWO übrigens auch nötig) die auf die Box aufpasst.


    Diese wird einfach zwischen Netzteil und Box gesteckt und unterbricht bei Bedarf die Stromzufuhr zur Box für ca. 3 Sekunden und

    startet damit die Box automatisch neu. Nach ca. 30 Sekunden schickt sie per IR das Abschaltkommando zur Box um diese wie ge-

    wünscht dann doch noch runterzufahren.


    Sie funktioniert dabei wie folgt:


    Beim Runterfahren blinkt die LED im Ein/Aus Taster der Box mit ca. 0,93 Hz so lange bis diese abgeschaltet ist. Bleibt der Abschalt-

    vorgang hängen blinkt die LED bis zur Stromtrennung kontinuierlich weiter.


    Dieses Blinken lässt auch die Stromaufnahme der Box zyklisch schwanken. Mit einem 0,93 Hz Filter in der Nanny wird die Strom-

    schwankung ausgefiltert und dem A/D Wandler eines Microcontrollers in der Nanny zugeführt. Dieser schaut sich das Blinken für ca.

    1 Minute lang an. Danach startet er den Zyklus:


    Stromzufuhr zur Box für 3 Sekunden trennen.

    IR Kommando: Runterfahren nach 30 Sekunden Wartezeit senden.


    Das ist schon sein ganzer Job.


    Wen die Nanny interessiert: Nähere Infos (Stromlauf / Firmware / Fotos) gibt es hier:


    nanny_1.00.zip


    Hier noch ein paar Bilder:


            


    /Willi/

    Hallo pclin,


    was wohl geht ist im Mountmanager im "Freigaben Editor" die Freigabeoptionen zu erweitern.

    Was funktioniert hat ist hier die cifs Version 3.0 mit aufzunehmen. Was auch ausgeführt wird.

    Wahrscheinlich kannst Du auch Deine anderen Mount Optionen mit hier eintragen und somit

    den "legalen" Mount Weg gehen (nicht am enigma vorbei).


    Damit Du nicht soviel Eingaben über die virtuelle Tastatur hast, kannst Du diese auch direkt

    in "/etc/enigma2/automounts.xml" eintragen. Nach der Änderungen von "automounts.xml"

    must Du Deine Freigaben aus: "/etc/fstab" löschen, bevor Du ein reboot durchführst.

    Die werden durch das Automount wieder eingetragen. Falls Du das nicht machst steht

    in "/etc/fstab" nach dem Reboot eine Mischung aus alten und neuen Einträgen.


    Automount ergänzt auch die Backup Verzeichnis Auswahl. Da findest Du dann auch alle Deine

    Mounts fürs Backup wieder.



    /Willi/