Segfault in VDR, Menu, Ursache unbekannt

    Hallo,


    beim Spielen mit dem VDR bekomme ich immer wieder einen segfault. Seltsamerweise immer an derselben Stelle, allerdings dürfte es da kein Problem geben:

    Meine ganz dunkle Vermutung ist, daß das Menu entweder nicht (mehr?) existiert oder der Speicherbereich dahinter irgendwie überschrieben wird.

    Merkwürdig ist auch, daß überhaupt kein Menu im eigentlichen Sinne offen ist, sondern es nur ein eigenes cOsdObject gibt.


    Mit valgrind bin ich nicht weiter gekommen. Es gibt Warnungen im Skindesigner, aber zum eigentlichen Problem konnte ich mich noch nicht hinarbeiten, weil das alles unglaublich träge ist.


    Gibt es irgendwelche Ideen, wie die Ursache ermitteln werden kann?

    Was heißt "beim Spielen"? Drückst du wild herum oder machst du immer was Bestimmtes?


    Segfaults kann ich in all den Jahren an einer Hand abzählen.

    Wenn ich schnell Kanäle weiterschalte, bleiben bei mir manchmal Sender hängen bzw. das Umschalten dauert dann ewig oder passiert nicht (Bild schwarz).

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

    Fast reproduzierbar ist das mit dem folgenden Use-Case:

    - vdr-plugin-web

    - HbbTV Seite aufrufen (Privatsender)

    - Video abspielen

    - in der Seite dann nächstes Video auswählen.


    Ich muss nochmal genauer schauen, ob das cOsdObject abgebaut und neu aufgebaut wird oder ob es weiterverwendet wird.

    Segfaults im Plugin selbst kann ich managen. Aber im VDR und dann auch noch an einer solchen Stelle? Mir fehlt einfach eine Idee, wie ich an die Ursache kommen kann.

    Ich würde zuerst schauen, ob im webOsdPage in vdr-plugin-web alles richtig ist. Menu() liefert ja nicht NULL zurück, hat aber dann das Problem auf ->NeedsFastResponse() zuzugreifen...

    Ich habe mal NeedsFastResponse() explizit hinzugefügt - ohne Erfolg.

    Aber mir ist aufgefallen, daß das Problem beim Videowechsel auftaucht, wenn nicht zwischendurch das reguläre Web-OSD eingeblendet wird, sondern maximal die VideoControls.

    Ich denke, ich muss den Player/Control/WebOSD noch mal überarbeiten.


    Sat.1 scheint auch nur bei einem bestimmten Sonnenstand zu funktionieren. Gestern noch alles grün und heute sehe ich Werbung in einer Endlosschleife und zwischendurch nur ein ganz kurzes Stück von dem eigentlichen gwünschten Video. Da ist auch noch etwas sehr seltsam. Und ein Tracker ist wieder auf der Blocklist gelandet.

    #define DELETE_MENU ((IsInfoMenu &= (Menu == NULL)), delete Menu, Menu = NULL)


    ist nicht thread-save.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Ich bin da schon weiter gekommen. Das Hauptproblem war, daß das cOsdObject aus der MainMenuAction auch gleichzeitig der cControl ist, der dem cPlayer untergeschoben wird.

    Dabei habe ich versucht, die Objekte geschickt zu verwalten und zu managen und übersehen, daß VDR selbst auch noch die Objekte abbaut, nur leider nicht immer sofort.


    Das habe ich jetzt umgebaut, bin dann aber in einer Race-Condition mit dem Konstruktor/Destruktor gelandet.

    In der Seite selbst kann man bei Ansicht eines Videos direkt ein anders Video zur Ansicht anwählen.

    Dann passiert folgendes:

    - Video wird gestoppt, VDR bekommt die Nachricht, der Player soll detached werden.

    - Das neue Video wird gestartet, VDR bekommt die Nachricht, ein anderer Player wird eingerichtet

    Und jetzt das Problem. Das Detach und die Dekonstruktion findet leider erst nach dem Start des neuen Player statt. Und damit sind die Objekte und der interne Status etwas strubbelig.


    Die aktuelle Lösung besteht jetzt darin, im StopVideo des Browsers eine zeitlang zu warten um die Javascript-Ausführung zu bremsen und den Start des neuen Videos zu verzögern. Damit erhält VDR etwas Zeit, den Player tatsächlich vom Device zu detachen und den internen Zustand sauber zu halten.

    Das funktioniert ziemlich gut und bisher habe ich keine Ausfälle bemerkt.


    Nur gefällt mir eine fixe Wartezeit nicht und da bin ich gerade dran. Die echte Schwierigkeit besteht darin, daß der cefbrowser aus mehreren Prozessen besteht und damit die Klassen/Methoden (Quellcode) zwar optisch zusammenhängen, aber in verschiedenen Prozessen eben nicht alle Membervariablen gleich sind und IPC stattfinden muss.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden