[160614] Neues OE2.0 Update

    @



    Reichi     Danke, die methode werde ich mir mal ansehen,


    ich hab auf den Widgets "nur" setText() aufgerufen, wenn das so problematisch ist sotte man den c++ code threadsafe machen. Ich hoffe ich habe das problem jetzt anders gelöst indem ein eTimer periodisch die Änderungen übernimmt.


    Eine Frage habe ich aber noch. wenn das starten der bin fehlschlägt rufe ich auf

    Code
    Notifications.AddNotification(MessageBox, _("Fehlermeldung") , type=MessageBox.TYPE_INFO, timeout=10)


    Ist das ebenfalls kritisch oder kann der Aufruf in dem thread verbleiben?

    • Offizieller Beitrag

    Keine mir bekannte Plattform erlaubt es GUI Element aus einem fremden Thread heraus zu nutzen, ganz egal ob es android, java oder .net ist.
    Man darf das nirgendwo. Wir haben nur den Fehler gemacht beim erlabuen von Threads nicht direkt die passenden eFatals mit einzuführen.


    Es gibt auch überhaupt keinen Grund so etwas aus einem Thread heraus zu machen.
    Threads sollten generell nur für Zeitintensive Dinge benutzt werden und nicht "für alles weil es einfacher ist" ;).


    Mit der Helfermethode ist es aber wirklich simpel das entsprechend umzusetzen.

    Naja wenn man eine unabhängige binary laufen lässt hat man ja keine wahl als das in einem thread zu machen daman den main thread ja nicht blockieren will und soll.


    Seis drum, dann das Notifications.AddNotificationim thread verbleiben oder muss ich das auch noch verschieben?

    Hallo!


    Ja, ich benutze L4L. Tatsächlich stand da auch etwas vor der Fehlermeldung, was mit L4L zu tun hatte, aber dummerweise habe ich das nicht in Verbindung gebracht...


    @Reichl


    Ich schicke dir mal den ganzen CL.


    Joerg, willst du ihn auch haben?



    EDIT: Langsam wird das Problem echt nervig. Ich kann keine 10 Sender mehr durchzappen ohne Crash. Was wäre denn eine erste Hilfe Maßnahme? Will nicht L4L runterschmeißen, wenn es nicht unbedingt nötig ist. Kann es vielleicht auch an Crossepg liegen?


    Bitte um einen schnellen Tipp!

    7020HD
    Sundtek DVB-CT
    Raspberry @ 1000/500/500/6

    Einmal editiert, zuletzt von micoba ()

    Auf dem gp Feed liegt ein update von Joerg bereit. Das teste ich gleich. Eine neue crossepg Version sehe ich allerdings nicht.

    7020HD
    Sundtek DVB-CT
    Raspberry @ 1000/500/500/6

    Zitat von Reichi

    Hi,


    leider hilft nur ein fix für das jeweilige Plugin. L4l und CrossEPG sind beide Kandidaten. Bei L4L ist Joergm grad dran es zu fixen,


    ... und der schwankt laufend zwischen Frust <> Aufgabe <> Erfolg . Das ist echt müßig. Heute hat meine 8k den Tag im Standby ohne Crash durchgestanden. Jedenfalls geht wohl nicht, aus einem DownloadCallback einen weiteren Download anzustoßen :upside_down_face: , ok das kann man gut trennen. Dann nutze ich auch iCalendar, eine py die nix mit E2 zu tun hat, die crasht nun auch im Thread, im E2-Main nicht. Problem ist halt, das die relativ langsam ist, so das E2 nun 1/h kurz "gebremst" wird, was man aber im Normalfall nicht bemerkt. Aber erstmal besser als crashen. Der Code wird durch das "Zerflücken" nun auch immer unübersichtlicher :face_with_rolling_eyes: aber egal.


    Reichi: Danke auch für das Beispiel, auch wenn ich nix von der Art und Weise der Funktionalität verstehe :grinning_squinting_face: . Aber im Moment brauche ich auch nix vom E2 im Thread. Aber generell zur Nutzung, kann man damit "nur" E2-Infos aus einem Thread abrufen und E2 blockt nicht oder blockt E2 trotzdem?

    • Offizieller Beitrag

    e2 blockt dann! Denn die Aufgabe wird im Main-Thread gerufen.
    Bei sehr iterativen Aufgaben (viele kleine schritte die einzeln schnell erledigt sind in summe aber sehr alnge laufen) kann man eventuell auch über ein "reactor.callLater" ans Ziel kommen, das erhöht aber den Verwaltungsaufwand ein ganzes Stück.


    Bei dem von dir beschriebenen Problem, wäre eine denkbar Ursache, dass du, wenn der thread "fertig" ist, vmtl. ja die Daten verarbeitest (in richtung e2). Wenn du diese Verarbeitung noch aus der "thread funktion" heraus rufst, dann führt das dazu, dass Methoden von enigma2 noch im Thread augeführt werden und löst dann natürlich ebenfalls die Assertion aus.


    Ggf. schau ich mir auch gerne mal den zugehörigen Code an und helfe dir mit etwas "konkreterem Code".

    Hier mal ne Rückmeldung von mir. Ich hatte seit dem L4L update bislang keinen crash mehr. Danke Joerg für den schnellen fix und u.a. Reichi für die Unterstützung!


    Grüße

    7020HD
    Sundtek DVB-CT
    Raspberry @ 1000/500/500/6

    enigma2 20130503 (master) -> 20130503b (master)
    -----------------------------------------------
    - hotfixed eTimer/eSocketNotifier assertion on eEPGCache::load call

    How can we win, when fools can be kings?

    nicht das ich wüsste....


    (wobei mein pluginliste doch im crashlog ist? ;o)


    multi mediathek...
    advanced channel selection...(valis epg)
    vali hd flex
    fan control


    sonnst nur standard kram ...


    gruss axxel

    Hatte gerade einen neuen Crash, scheinbar wegen EMC oder was denkt ihr?



    [Picload] decode picture... /hdd/movie/TRASH TV/TRASH TV.jpg
    [Picload] decode finished... /hdd/movie/TRASH TV/TRASH TV.jpg
    gPixmapPtr.__deref__() is deprecated please completely remove the ".__deref__()" call!
    File "/usr/lib/enigma2/python/Plugins/Extensions/EnhancedMovieCenter/MovieSelection.py", line 281, in showCoverCallback
    self["Cover"].instance.setPixmap(ptr.__deref__())
    File "/usr/lib/enigma2/python/mytest.py", line 11, in gPixmapPtr_deref
    traceback.print_stack(limit = 2)
    [Picload] decode thread ... got quit msg
    thread joined 0
    action -> PluginMovieSelectionActions EMCEXIT
    ignore request to play already running service(1)
    Looking for embedded skin
    action -> ColorActions yellow
    action -> MsgBoxActions ok
    Looking for embedded skin
    FATAL: ebase.cpp:196 ASSERTION m_tid == (pid_t)-1 :tired_face: m_tid == eThread::gettid() FAILED!
    PC: 762f70f4
    00000000 10008700 00000000 65806920
    0000376a 000055ec 00000006 00000000
    f0000000 805e0dd0 019c4730 46202928
    7c7c2031 77fdb000 3d206469 657fe6a0
    000055ec 00000006 00000000 6aa48290
    77998000 779a2158 00001000 00800000
    00000053 762f7080 00000000 00000000
    76417970 657fe708 657feec0 762fb8a8
    As a final action, i will try to dump a bit of code.
    I just hope that this won't crash.
    762f70f4: 07 00 e0 10 ff ff 03 24 3b e8 03 7c 21 20 60 00 0c 94 83 8f 21 20 64 00 03 00 00 10 00 00 82 ac (end)
    -------
    ]]>
    </enigma2crashlog>
    <pythonMD5sum>

    7020HD
    Sundtek DVB-CT
    Raspberry @ 1000/500/500/6