softhddevice mit High Level OSD

  • Das wird immer seltsamer...


    Jetzt kommt:


    Code
    .....
    Mar 26 13:44:58 [vdr] [4673] [softhddev]SetPlayMode: 1_
    Mar 26 13:44:58 [vdr] [4673] [softhddev]stopping Ogl Thread svdrp DETA
    Mar 26 13:44:58 [vdr] [4673] [softhddev]stopping OpenGL Worker Thread
    Mar 26 13:44:58 [vdr] [5451] [softhddev]Cleaning up OpenGL stuff
    Mar 26 13:44:58 [kernel] oglThread[5451]: segfault at 0 ip           (null) sp 00007f39657f9df8 error 14 in vdr[400000+1d6000]
    Mar 26 13:44:58 [lircd-0.9.0] removed client
    Mar 26 13:44:58 [root] Focus: 1
    Mar 26 13:44:58 [G2V gg_switchhook.sh] /_config/bin/gg_switchhook.sh -switch ActWin <(1058, 1888) 0(Gg_launcher)>
    Mar 26 13:44:59 [root] VDR wurde beendet - RC: 0


    Habe aber nichts verändert.


    Backtrace


    3PO: wie genau startest du den VDR bzw. SHD?


    Eigentlich nicht außergewöhnlich.


    SHD starte ich mit folgenden Parametern:



    [...] Warum detachst du SHD per SVDRP nachdem es gestartet ist? ...


    Tue ich doch garnicht, zumindest mal nicht bewusst.

  • Moin,


    3PO: kannst du mal testen, anstelle von suspended (mit -s) detached (-D) zu starten? Daran könnte es ggf. liegen...müsste ich auch bei Zeit mal testen.


    Ciao Louis

  • im Git ist nun eine Version, die das Problem mit dem Ändern der Fenstergröße fixt. Wurde die Fenstergröße geändert, hat das OSD ja nicht mehr funktioniert. Getestet habe ich das ganze mit openbox und wmctrl. Damit sollte das yaVDR PIP auch funktionieren.


    Yessesyes - geht während und auch nach dem Pip, so soll es sein.


    Heute ist wieder Weihnachten und Ostern zusammen, vielen Dank ;)


    Christian

    Images

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • Yessesyes - geht während und auch nach dem Pip, so soll es sein.


    :tup Danke für die Rückmeldung ;)


    Ciao Louis

  • 3PO: kannst du bitte nochmal mit der aktuellen Git Version testen? Ich vermute du benutzt eine neuere FT Lib als ich, und die reagiert ein bisschen empfindlich, wenn die Deinitialisierung ohne vorherige Initialisierung stattfindet. Wäre doch gelacht, wenn wir den Mist nicht auch bei dir zum laufen kriegen ;)


    Ansonsten (falls es immer noch Probleme gibt) auch mal komplett ohne detach / suspend Startparameter testen.


    Ciao Louis

  • Es funktioniert leider immer noch nicht. :(


    Wenn ich softhddevice so starte,


    Code
    PLUGIN_PARAMETERS="-a pcm.stereo -p hw:2,8 -w use-possible-defect-frames"


    dann startet der VDR nicht mehr.




    Backtrace

  • Mit der aktuellen Version hatte ich gerade einen Crash beim Umschalten, anbei der backtrace.

    Files

    Gruß
    Frodo

  • Auch ein crash beim umschalten, aber backtrace ist nicht in Ordnung, da stirbt etwas wofür ich keinen debug symbol habe oder so etwas (hat jemand einen Rat dafür?).
    (hab vorhin vdr-softhddevice und vdr-skindesigner aktuallisiert)


    softhddevice (0.6.1rc1-GIT4fa4f66) + commits 48fbfa9f...fd3db0bc.diff

    Code
    https://github.com/louisbraun/softhddevice-openglosd/compare/48fbfa9f...fd3db0bc.diff


    skindesigner (0.9.5): Skin Designer


    backtrace:

    Code
    https://pastee.org/9cdx5
  • Ich weiß, was ich jedoch nicht weiß ist wie soll ich damit eine richtige backtrace erstellen. Bis jetzt war es immer ok, entweder ist das etwas tieferes, was den ganzen libc zerstört und dafür habe ich keine debug symbols oder es ist etwas ganz anderes. Bin für jede Hilfe aber dankbar, um ein richtige backtrace zu erstellen, und damit das softhddevice-opengl Plugin zu fixen, falls es der Übeltäter ist.

    Edited once, last by crow ().

  • Richtig reproduzieren kann ich den Crash nicht, passiert beim Sender umschalten. Bis jetzt ist es drei mal aufgetreten, und jedes mal war backtrace derselbe.

  • Hallo zusammen,


    mit Erlaubnis von Louis darf ich den Thread in gewisser Weise "hijacken" ;)
    Ich habe hier die Commits von Louis auf den Branch von johns ge-cherry-picked und einen Commit draufgesetzt, der glGetError() nach jedem GL Befehl einführt.
    Da ich das ganze als Vorbereitung für die gles Funktionalität gemacht habe und hier keinen i386 mit softhddevice zum Testen habe, wollte ich fragen, ob diesen Branch mal jemand ausprobieren und schauen könnte, dass damit kein Bug einwandert ...
    Es würde mir dann auch helfen, wenn jemand den gles branch auf dem i386 probiert, um sicherzustellen, dass ich auch hier nichts kaputt gemacht habe ;)


    Mein eigentliches Ziel, ein softhddevice mit OpenGL/ES Unterstützung, ist grundsätzlich erreicht, obwohl noch ein paar Sachen zu fixen sind. Wenn da Interesse besteht, mache ich einen neuen [WIP]Thread dazu auf und beschreibe, wie man das zum Laufen kriegt. Evtl. finden sich ein paar Tester...


    Danke und Gruß
    Andreas

  • Hallo Andreas

    Mein eigentliches Ziel, ein softhddevice mit OpenGL/ES Unterstützung, ist grundsätzlich erreicht, obwohl noch ein paar Sachen zu fixen sind. Wenn da Interesse besteht, mache ich einen neuen [WIP]Thread dazu auf und beschreibe, wie man das zum Laufen kriegt. Evtl. finden sich ein paar Tester...

    Klingt, als ob es schon bald eine plattformübergreifende Implementation eines beschleunigten High-Level-OSDs gibt. :tup


    Damit stellt sich für mich nun ernsthaft die Frage, ob es nicht sinnvoll wäre, die Arbeit ein eigenständiges Plugin zu stecken. Die Verknüpfung von Ausgabedevice und OSD ist in meinen Augen nicht mehr zwingend, da es inzwischen sowohl für die Videoausgabe wie auch für das OSD auf allen Plattformen mehrere unabhängige Wege gibt. Ein OpenGL/ES-OSD-Plugin würde dann swohl auf einem Raspberry Pi, einer Wetek-Play oder einem Desktop (?) laufen und könnte zentral gepflegt werden. Das nur mal so als Idee. ;)


    Gruss
    Thomas

  • Klingt, als ob es schon bald eine plattformübergreifende Implementation eines beschleunigten High-Level-OSDs gibt. :tup


    Damit stellt sich für mich nun ernsthaft die Frage, ob es nicht sinnvoll wäre, die Arbeit ein eigenständiges Plugin zu stecken. Die Verknüpfung von Ausgabedevice und OSD ist in meinen Augen nicht mehr zwingend, da es inzwischen sowohl für die Videoausgabe wie auch für das OSD auf allen Plattformen mehrere unabhängige Wege gibt. Ein OpenGL/ES-OSD-Plugin würde dann swohl auf einem Raspberry Pi, einer Wetek-Play oder einem Desktop (?) laufen und könnte zentral gepflegt werden. Das nur mal so als Idee. ;)


    Ich habe das noch nicht weiter gedacht... Ich habe nur dem libvdpau backend für die Allwinner Devices ein gles interop feature spendiert, das ja für nvidia auf gl-Basis existiert und von louis' HighLevel OSD- softhddevice genutzt wird. Dann musste nur das softhddevice von gl auf gles angepasst werden... Ein zentrales OSD-Plugin wäre möglicherweise sinnvoll, obwohl ich über Vor- und Nachteile noch nicht nachgedacht habe. Aber "denkenswert" ist das bestimmt ;)


    Gruß
    Andreas

  • Hi,


    die Idee von Thomas finde ich gut...ich hätte auch kein Problem damit, die "Verantwortung" für den OpenGL Teil abzutreten ;) Wenn sich jemand dazu bereit erklärt, das ganze in ein eigenes Plugin auszulagern...nur zu!


    Ciao Louis

  • Ihr könnt ja schon mal die Vorarbeiten machen und den Ausgabeplugins über einen Parameter beibringen, keinen OsdProvider zu erstellen, wenn sie aktiviert werden.
    Am besten alle mit dem gleichen, z.B. --no-osd oder so.


    Dann wäre das Bauen eines OSD-Plugins nur noch eine Fingerübung... :)


    Lars.

  • Ihr könnt ja schon mal die Vorarbeiten machen und den Ausgabeplugins über einen Parameter beibringen, keinen OsdProvider zu erstellen, wenn sie aktiviert werden.


    Meinst du sowas:


    ;)


    Gruss
    Thomas

  • ich hätte auch kein Problem damit, die "Verantwortung" für den OpenGL Teil abzutreten Wenn sich jemand dazu bereit erklärt, das ganze in ein eigenes Plugin auszulagern...nur zu!


    In Sachen OpenGL kenne ich mich zu wenig aus und aktuell bin ich mit dem Umbau von rpihddevice gut ausgelastet. Aber ich übernehme gerne die Raspi-spezifischen Anpassungen und helfe natürlich mit beim Testen!


    Gruss
    Thomas

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!