gelegentlicher Crashloop im AutoResolution auf der DreamOne nach Boxstart

  • Hallo


    Ich habe gelegentlich (alle paar Wochen) beim Start der Box aus dem DeepStandby einen Dauer-GS, weil im AutoResolution keine config.av.videorate-Werte verfügbar sind.

    Da kommt es dann in Zeile 284 (rate = config.av.videorate[mode].value) zu einem GS, weil config.av.videorate keinen Inhalt hat.

    mode wird dabei mit "" an setMode übergeben.

    Da half dann immer nur den Kippschalter an der Box zu nutzen.

    Beim GS hat config.av.videorate folgenden Inhalt:

    {}


    Im Normalfall hat config.av.videorate sowas als Inhalt:

    Code
    {'1080i': <Components.config.ConfigSelection object at 0x7f5fce7090>,
    '1080p': <Components.config.ConfigSelection object at 0x7f5fcd8fd0>,
    '2160p': <Components.config.ConfigSelection object at 0x7f5fcd8f50>,
    '480i': <Components.config.ConfigSelection object at 0x7f5fce7310>,
    '480p': <Components.config.ConfigSelection object at 0x7f5fce7290>,
    '576i': <Components.config.ConfigSelection object at 0x7f5fce7210>,
    '576p': <Components.config.ConfigSelection object at 0x7f5fce7190>,
    '720p': <Components.config.ConfigSelection object at 0x7f5fce7110>}

    Hab mir erstmal geholfen, indem ich die Zeile 284 mit einem try/except abfange und rate auf "" setze:

    Code
                try:
                    rate = config.av.videorate[mode].value
                except:
                    rate = ""

    Nach dem except im Fehlerfall liegen dann intern folgende Werte vor:

    mode: '', port: 'HDMI', rate: ''


    Wenn alles normal läuft, sind es diese Werte:

    mode: '1080p', port: 'HDMI', rate: 'multi'


    Gibt es da eine Idee, warum config.av.videorate in den seltenen Fällen beim Boxstart nicht befüllt wird ??

    Gruß Sven (aka Dreamy)


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

  • Wenn ich mich richtig erinnere, dann werden die Werte ausgelesen. Das könnte dann ein Timing-Problem sein

    Gruss
    Dre


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

  • Hab jetzt das hier in der DisplayHardware.py gefunden ;)

    Vermutlich ist der seltene Fall im Kommentartext beschrieben. ;)

    Da kann man dann wohl nichts machen, nur eben den Code um die Zeile 284 im AutoResolution anpassen.

    Als Idee dann vielleicht so ? (Zeile 284-286)

    Gruß Sven (aka Dreamy)


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

  • Hmm, da bin ich ehrlich gesagt überfragt, da ich die ganzen Abläufe zum Setzen der config.av-Values aktuell nicht überschaue ;)

    Keine Ahnung, ob man das später nochmal anschieben kann, wenn die Werte gesetzt wurden ??

    Gruß Sven (aka Dreamy)


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

  • Das wird z.B. jedes Mal aufgerufen, wenn sich die Framerate ändert:

    Code
    self._contentFramerateChangedSigConn = self._displayManager.contentFramerateChanged.connect(self.contentFramerateChanged)


    im Plugin könnte man in setMode eine Anpassung vornehmen:

    und in __init__() noch sowas:

    Code
    self._displayManager = eDisplayManager.getInstance()

    Keine Ahnung, ob das so klappt, aber so würde ich das mal versuchen.

    Gruss
    Dre


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

  • Ich glaube, das wird doch nicht klappen ;)


    Wenn es das Problem gibt, wird mode="" an setMode() übergeben.

    Wenn ich dann über das hdmiChanged.connect wieder setMode() mit dem übergebenen mode="" aufrufe, lande ich wohl in einer Schleife, weil "" nie Inhalt von config.av.videorate ist.


    setMode() müsste dann ja mit einem echten mode-Wert aufgerufen werden, damit es dort weitergeht.

    Gruß Sven (aka Dreamy)


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

  • zu setMode kommst du ja gar nicht, wenn mode nicht im dict ist. Da hab ich ja ein return drin

    Gruss
    Dre


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

  • Man ist ja schon in setMode vom AutoRes, welches mit mode = "" aufgerufen wurde.

    Und wenn mode nicht im dict ist, willst du das setMode erneut mit mode="" bei hdmiChanged aufrufen:

    Code
    if not mode in config.av.videorate.keys():
        # set trigger for hdmiChanged and return
        self._hdmiChangedSigConn = self._displayManager.hdmiChanged.connect(boundFunction(self.setMode, mode))
        return

    Gruß Sven (aka Dreamy)


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

  • Ja, aber das wird nur aufgerufen, wenn der Core meldet: hey, etwas hat sich geändert. Wenn dann mode immer noch nicht gültig ist, dann wird wieder gewartet. Es wäre definitiv noch besser, in __init__ self._hdmiChangedSigCon = None einzufügen. Und dann im obigen Code zuerst abfragen, ob self._hdmiChangedSigCon None ist und nur dann den Trigger setzen.

    Gruss
    Dre


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

  • Ich glaub, du hast mich falsch verstanden ;)

    Ein Aufruf von self.setMode(mode="") über das hdmiChanged.connect ist sinnfrei, weil ein mode "" niemals im dict enthalten sein wird und man daher über diese Variante immer im return landen würde.

    Dann kann man sich den Aufruf auch sparen ;)


    Das Ganze würde nur Sinn machen, wenn mode einen gültigen Wert hätte, der noch nicht im Dict enthalten ist.

    Hier wird aber im Problemfall "" als mode übergeben, der niemals im dict enthalten sein wird.


    Man kann das setMode() im AutoRes dann einfach mit rate = "" durchlaufen lassen, weil das spätere DisplayHardware.instance.setMode dort bei rate="" eh nicht ausgeführt wird

    Code
        def setMode(self, port_value, mode_value, rate_value):
            if not port_value or not mode_value or not rate_value:
                print("can't set new display mode (port, mode, rate) => ", port_value, mode_value, rate_value)
                return
            ...

    Spätestens wenn es relevante Änderungen im iPlayableService-Event gibt, wird das setMode im AutoRes neu aufgerufen, wo dann mittlerweile vermutlich auch passende Werte in config.av.videorate enthalten sind ;)

    Gruß Sven (aka Dreamy)


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

  • Ich habe ein gleiches merkwürdiges Phänomen mit meiner Two

    wenn sie aus dem Standby ( nicht Idle Mode ) bootet, dann geht sie in eine Bootschleife, wenn kein aktives Gerät am HDMI Ausgang angeschlossen ist, bzw wenn kein HDMI Kabel eingesteckt ist, das ist ein Problem bei Timeraufnahmen aus dem (Deep)Standby - da habe ich nur hundert Crashlogs auf Platte

    der crashlog zeigt ein Python Problem mit autoresolution

    also hab ich ein nacktes experimental Image ohne Settings eingespielt, dann bootet sie normal

    wenn ich jetzt auf dieses jungfräuliche Image autoresolution vom Feed installiere, dann geht sie wieder in die Bootschleife


    Ich habe versucht die exception einzufügen


    try: rate = config.av.videorate[mode].value
    except: rate = ""


    dann bootet die Box normal, wenn am HDMI nichts angeschlossen ist, aber autoresolution geht nicht mehr und der Pluginmanager meldet einen Fehler, wenn man ihn aufruft

  • Welcher Fehler kommt denn, wenn du den PluginManager öffnest?


    Ich habe hier meinen obigen Fix analog deines Versuches in Nutzung und damit kein Problem.


    Möglicherweise hast du in der Änderung einen Code-Fehler drin oder falsche Einrückung …

    Gruß Sven (aka Dreamy)


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