Bootschleife nach Stromreset

  • Hallo,


    ich hatte micht schon einmal wegen diesem Problem gemeldet, damals in
    Kombination mit dem Elektro-Plugin, damals verwies man mich auf ein
    anderes Skin, da mein gewähltes veraltet war.


    Nun habe ich das Problem mit dem Plugin Start-up-to-Standby. Ich habe
    aktuell den Skin NukeFHD installiert, ist aber vollkommen egal welchen
    Skin ich gewählt habe, wenn ich das Plugin aktiviert habe, dass wenn die Box startet automatisch in den Idle-Mode geht, und es z.
    B. zu einem Stromausfall kommt, oder die Box vom Netz getrennt wird,
    läuft sie danach in einer Dauerbootschleife, bis ich hergehe und unter: /usr/share/enigma2/"skinname" den entsprechenden Ordner lösche, dann
    wird mit dem standardskin gestartet und die Box läuft wieder, wenn ich
    danach mein Wuschskin im Paketmanager deinstalliere und neu installiere, funktioniert dieses auch wieder, bis zum nächsten Stromausfall!


    Wenn ich das Standby-Plugin deaktiviere, funktioniert alles problemlos,
    nur da wir relativ oft Stromschwankungen haben, kommt es alle paar
    Wochen vor, dass die


    Box nachts angeht, somit auch mein TV um mein AVR und dann bis am morgen
    läuft, deshalb habe ich das Plugin, das mir dies verhindert.


    Irgenwas kommt beim Kaltstart durcheinander, ich kann dies auch mit
    einem neu geflashten Image rekonstruieren, das hat nichts mit meinen
    anderen Plugins zu tun.


    Nur die Kombination aus Stromreset und irgenden einem Plugin, dass die
    Box nach dem Booten in den Idle schickt, gibt es diese Probleme, egal,
    ob man diese


    Funktion im Elektro Plugin auswählt, oder das Standby-Plugin verwendet.


    Das Problem besteht schon seit ein paar Monaten, wollte es nur neu
    aufgreifen, aktuell habe ich das Daily von Newnigma2 installiert und der
    Fehler ist


    jederzeit reproduzierbar.
    Im Newnigma-Forum hat man mich hierher verwiesen, da es sich hier um einen Chrash in der Funktionalität vom DMM handelt. Ich hoffe ich bin nun hier richtig.


    Anbei den Crashlog

  • Du könntest das log auch SELBER lesen, feststellen das es in einem NN2 Skin Renderer crashed und das in deren Image Board posten.


    Deswegen geht es auch mit dem Standardskin, der diesen buggy Renderer halt nicht verwendet ...


    Einen None Kanal weil die box sofort in Standby geht auf Text zu konvertieren ohne vorher auf None abzufragen geht halt nicht gut aus.

  • Danke Gutemine,


    bei dem Crashlog blicke ich einfach nicht durch, da finde ich nichts genaues, es steht so oft crashlog hier und da, aber wonach muss ich denn da genau suchen, um es zu erkennen, woran es liegt?
    Das würde mir in Zukunft auch weiter helfen.
    Ich hatte mich mit dem Log auch bevor ich mich hier gemeldet habe im NN2 Forum gemeldet, dort hat man mich hierher verwiesen, da es anscheinend an einer Funktionalität von DMM läge,
    da diese Aussage von einem CHIEF-Developer kam, ging ich davon aus, dass er schon wissen müsste worum es geht...


    Kann ich den SkinRenderer selbst ändern, bzw. könntest du mir evtl. behilflich sein?

  • So was in der Art gehört da wohl rein, aber die sollen das gefälligst selber fixen in Ihrem Renderer auf


    /usr/lib/enigma2/python/Components/Renderer/newnigma2ChNumber.py in Zeile 65


    Und hier stand Blödsinn ... weil der Crash is in der ChannelSelection.py - aber nur weil die vom Renderer in Zeile 65 mit None aufgerufen wird was eben nicht sein sollte.

    2 Mal editiert, zuletzt von Lost in Translation ()

  • Danke Dir, habs auch gerade im anderen Board gelesen, ich hab mir meinen Log nochmal selbst angeschaut, ich versteh da nur bahnhof...


    Woran erkennst Du, dass es der Renderer ist, der crashd? Wenn ich Crash suche erhalte ich alles mögliche, aber nichts brauchbares,
    gibt´s da eine bestimmte suche?

  • Du hast Anfangs Bla Bla und am Ende Bla Bla.


    Die Interessante info mit dem Code WO es crashed und in welchger Zeile sind in der Mitte.


    Such mit dem Code Link den ich dir gepostet habe im Crashlog, dann siehst du das dort alles nötige steht ...


    T

  • womit wir wieder beim LESEN hilft wären ...

  • ich seh hier nicht das der render schuld sein soll


    ------------------------------------------------------------------
    » Chuck Norris kann Zwiebeln zum Weinen bringen «

    • Offizieller Beitrag

    naja... im Endeffekt ruft ihr da getBouquetNumOffset mit "None" auf.. weil myRoot anscheinend noch None ist... weil die ChannelSelection noch kein aktuelles bouquet gesetzt hat... warum auch immer.


    Man könnte einfach oben prüfen ob myRoot None ist und dann self.text="" setzen und return machen....

  • Ich habe Ihm das schon gestern im NN2 Board geschrieben ...


    Code
    rx = MYCHANSEL.getBouquetNumOffset(myRoot)


    Obige Zeile 65 vom Renderer crasht aber in der ChannelSelection.py Zeile 851


    Code
    def getBouquetNumOffset(self, bouquet): 
    if not config.usage.multibouquet.value: 
    return 0 
    str = bouquet.toString()


    Und zwar weil auf bouquet None übergeben wurde und er sich damit schwer tut es auf einen String zu konvertieren.


    Und nachdem DMM das wohl nicht fixen wird muesste man vor dem Aufruf im
    Renderer halt abfragen ob es überhaupt was zum abfragen gibt ... so in
    der Art:


    Code
    if myRoot is None:
    Fehlerhandling weil noch keine Bouquet also zb rx=-1
    else:
    rx = MYCHANSEL.getBouquetNumOffset(myRoot)


    Das Ganze passiert ja wenn durch das startup to standby sofort in den
    Standby gegangen wird womit eben kein Kanal aktiv ist und damit auch
    keine Bouquet root gesetzt.


    Theoretisch könnte man sich die bei None zwar aus den enigma2 settings
    vom letzen Kanal holen, aber dann wird es schon fast zu sophisticated.

  • Der Code ist ja auch ursprünglich von uns. Ich hatte das bei uns auch mal behoben. Aber mittlerweile haben wir das eh komplett anders gelöst.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource