Aufruf einer Funktion über einen eTimer versickert irgendwo

  • Hallo


    Im PzyMail hatte ich festgestellt, dass die automatische Aktualisierung im Hintergrund öfter mal "ausgestiegen" ist.
    Bei der Analyse bin ich dann darauf gestoßen, dass eine Funktion sich über einen eTimer mit 1 Sekunde Verzögerung selbst wieder aufruft.
    (der eTimer wird dabei lt. Codeerläuterung genutzt, um einen Spinner zu vermeiden)


    Unter bisher nicht reproduzierbaren Situation läuft der Funktionsaufruf über den eTimer ins Leere.
    Das heißt, die Funktion wird nicht mehr aufgerufen, obwohl der eTimer dazu gestartet wurde.
    (keine nachfolgende print-Ausgabe zum Start der Function)


    Welche Möglichkeiten hat man hier, um herauszufinden, was mit dem eTimer-Aufruf passiert ist ?
    Rufe ich die Function dagegen direkt auf (also mit self.eigeneFunction(), eben ohne eTimer), funktioniert das Ganze.
    (ist nur die Frage, ob es dann wirklich Probleme mit dem Spinner geben könnte, die ich aber auf der 920 noch nicht feststellen konnte)


    Ist es evtl. ein Problem, wenn der timeout.connect zu oft neu festgelegt wird?
    Stirbt dann vielleicht irgendwas weg oder welche Ursache kann es geben, dass der eTimer irgendwo versandet?


    Beispielcode:

    Gruß Sven (aka Dreamy)


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

    Einmal editiert, zuletzt von Sven H ()

  • Vorweg, ich bin Laie absolutes Greenhorn!


    Der Timer wurde auch gestoppt weiter oben im Code?
    Ich mache das so:


    Code
    self.cb_timer.startLongTimer(1, True) #1 sec. delay to avoid spinner
  • Ja, ich hatte sogar vor dem Start testweise alle Variablen auf None gesetzt und den eTimer ganz neu gesetzt.
    Aber das mit dem "..., True" hab ich nicht probiert.
    Könnte ich ja mal versuchen :winking_face:

    Gruß Sven (aka Dreamy)


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

  • Es reicht imho connect einmal zu machen. Ich hab jetzt den Code nicht angeschaut, aber es wird ja vermutlich eine Server abgefragt. Da kann es eigentlich nur zu einem Spinner kommen, wenn das nicht asynchron gemacht wird. Der nächste Timer sollte auch nur gestartet werden, wenn der alte beenedet ist (resp. das was danach ausgeführt wird).

    Gruss
    Dre


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

  • Ja, in der Function wird unterschieden, ob die Funktion sich nochmal selber aufruft, oder ob der andere Folgecode ausgeführt wird.
    Bei letzterem wird der Timer vorher gestoppt.
    Auch das connect wird dabei glaub ich auf None gesetzt, weshalb es dann in der Function beim nächsten Refresh wieder neu gesetzt wird.


    Aber kann es sein, dass durch das ständige neusetzen des Connects der Timer irgendwann stirbt?

    Gruß Sven (aka Dreamy)


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

    • Offizieller Beitrag

    Erstmal ein Vorschlag:

    Python
    if not self.cb_timer_conn:
    	self.cb_timer_conn = self.cb_timer.timeout.connect(self.eigeneFunction)


    Im Prinzip sollte ein neuer connect kein Problem sein, ich würde gerade (ohne den code ansatzweise zu kenne) eher Vermuten dass die connection irgendwo gelöst wird BEVOR der timer tats. aubläuft oder aber der timer gestoppt.
    Recht viel andere Möglichkeiten kann ich mir eigentlich kaum vorstellen.

    mfg ,
    Reichi

  • Im Code gibt es lediglich in dieser Function den eTimer.
    Anderswo gibt es keine Codezeilen, die den eTimer betreffen.


    Hier nochmal mit ein paar mehr Zeilen (aber immer noch gekürzt wegen der Übersichtlichkeit):


    in self.cb() erfolgt im Autopoller die Hintergrundaktualisierung (z.B. alle 5min - je nach Setting)
    Dort wird auch der Pop3_Server jedesmal neu initialisiert und somit der eTimer neu gesetzt.


    Es könnte vielleicht sein, dass die Klasse "Pop3_Server" aus irgendeinem Grund stirbt und damit auch der eTimer.
    Komisch wäre aber, dass das ausgerechnet immer nach Start des eTimers passieren sollte.
    Hab schon jede Menge prints eingebaut, konnte aber noch keine störende Stelle finden.
    Ich hatte auch schon vor dem Neusetzen des Timer-connects den Timer selbst neu gesetzt, aber das hat auch nicht geholfen.


    Wie gesagt, rufe ich die Function direkt ohne den eTimer auf, gibt es keine Probleme.
    Also kann die Klasse selbst auch nicht das Problem sein.


    Gibt es eine passende Codezeile, mit der man den Status eines eTimers abfragen könnte?
    Also was aus dem Timer geworden ist ??
    Da die Function ja nicht mehr aufgerufen wird, dürfte der Timer ja auch nicht gestoppt oder gelöscht werden.

    Gruß Sven (aka Dreamy)


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

  • nach vielen Tests mit noch mehr prints hab ich das Problem nun gefunden :winking_face:
    War gar nicht so einfach bei dem doch recht komplexen Code.


    Es wird tatsächlich doch an anderer Stelle die Klasse (globale Variable), in der auch der Timer läuft, in einem weiteren Timer auf None gesetzt.
    Wenn die Timer zeitlich ungünstig zusammenfielen, kam es zum Problem (daher passierte es nicht immer).


    Hab mir da jetzt was eingebaut, dass die Variable nur auf None gesetzt wird, wenn der Timer innerhalb der Variable nicht gerade läuft.
    Bis jetzt klappt das :winking_face:


    Da ich mir das Plugin geringfügig angepasst hatte (neuer InfoScreen nur mit Mail-Symbol auf dem TV-Display ohne LCD-Screen bei neuen Mails, der die weitere Boxbedienung nicht stört), kann ich nichtmal genau sagen, ob das Problem im Original-PzyMail-Plugin-Code auch auftreten würde :winking_face:

    Gruß Sven (aka Dreamy)


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

  • Eigentlich muss generell sichergestellt sein, dass während der Code bei timeout ausgeführt wird, kein neuer gestartet wird und auch nichts auf None gesetzt wird.

    Gruss
    Dre


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

  • Theoretisch ist das schon klar :winking_face:


    Aber stell das mal sicher in einem so komplexen fremden Code, wo man gar nicht genau weiß, was wo so genau gemacht wird :upside_down_face:
    Da bedarf es schon einer ziemlich zeitintensiven Codeanalyse.


    So langsam bin ich das ja gewohnt - hab mich ja auch in das komplexe PTS eingearbeitet :thumbs_up:

    Gruß Sven (aka Dreamy)


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

  • Hi Sven.
    Magst du deine veränderte Version zur Verfügung stellen. Ich habe hauptsächlich wegen der auftretenden Spinner das alte imap-Plugin versucht zu verändern (danke nochmal für die Hilfe) - benutzte aber eigentlich vorher immer pzymail.

  • Naja, bezüglich der Mailabruf-Funktionen hab ich da nichts angepasst.
    Ich hab hier nur einen Account und da hab ich gelegentlich (also eher selten) auch kurze Spinner, wenn im Hintergrund das Mailkonto abgefragt wird.


    Ich hatte nur ein paar Dinge für mich dazugebeastelt:
    - neue Mails in anderer Farbe darstellen (skin: fromNewTextColor, subjectNewTextColor, timeNewTextColor)
    - Infofenster nur bei neuen und ungelesenen Mails anzeigen - nur bei IMAP (falls Mails schon am Handy gelesen)
    - neues Infofenster im Hintergrund (ohne Einschränkung der weiteren Boxbedienung)
    - Focus beim Öffnen des Plugins automatisch in die Mailliste setzen
    - Löschen von Mails in den Papierkorb (bei IMAP)
    ...


    Wie gesagt, bezüglich Spinner wird dir die Version nichts bringen.

    Gruß Sven (aka Dreamy)


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

  • Im EmailClient habe ich im Betrieb keine Spinner bemerkt auch nicht in der Konsole mit init4/enigma2, aber hier auch nicht den Aufruf der Konten über das Plugin.


    Bei Pzymail hatte ich beim Abruf immer wieder mal Spinner und auch mal länger wenn die Verbindung nicht zustande kam. Dies sah man dann auch im Log.
    Sofern ich mich erinnern kann, kam da immer "display Spinner".