Installation eines VDR+Plugins nativ auf CoreELEC Boxen

  • Ich habe einen neuen Versuch mit Github Workflows gestartet. Der Build bricht nach über 4 Stunden mit exakt dem gleichen Fehler ab :(

    Eine Suche nach der Ursache war bisher erfolglos, aber es gibt/gab ähnliche Probleme mit CEGLContextUtils und anderen Methoden. Es scheint - unbestätigt - irgendwas mit dem Header egl_platform.h zu tun zu haben: Zu alt, zu neu, anders. Unterschiede zwischen den libMali, fbdev, khronos,... Versionen.

    Nur worin sich euer und der Github Container sich von meinen beiden Systemen unterscheidet ist noch unklar. Die Erwartung wäre gewesem. daß alle Sourcen identisch sind und damit auch der Build. Das der Header vom Host gelesen wird, kann ich mir eigentlich nicht vorstellen.


    So genau weiß ich noch gar nicht, wie ich dahinter kommen kann und auch nicht, wie eine Lösung aussieht.

  • Okay. Ich habe mal geschaut, wo es die eglplatform.h überall gibt. Unter anderem in der libglvnd. In den VDR Packages nutze ich eine veränderte Form des Packages glu. Das Original glu hat eine Abhängigkeit zu mesa, das aber nicht kompiliert. Soweit ich mich erinnere, hängt das an libdrm. Aber egal.

    In meiner verwendeten glu habe ich die Abhängigkeit von mesa auf libglvnd und opengl-meson geändert. Dadurch wird libglvnd mit in den Build gezogen, das eigentlich nur für mesa und Xf86 gebaut würde.


    Mein Verdacht ist nun, daß genau diese Abhängigkeit bei euch Probleme macht.


    Deshalb wäre es wirklich interessant zu wissen, ob der Build ohne VDR (siehe oben) funktioniert. Falls es funktioniert, dann hätte ich einen Ansatz um das Problem lösen zu können - hoffentlich.

  • Soooo. Kodi und VDR bauen auf Github. Und damit hoffentlich auch bei allen anderen.


    Allerdings reicht der Speicherplatz im Github Container nicht für die Images und der Build bricht beim Image bauen ab.

    Mal schauen, wie ich das Speicherlayout noch ändern kann, so daß auch die Images erzeugt werden. Das hätte den Vorteil, daß ich auch endlich Binaries mit einem Release automatisch erzeugen lassen kann.


    Das Testen ist etwas mühselig, da der finale Build wohl ca. 5,5 Stunden braucht.

  • Hallo Zabrimus,

    habe alles gebaut bekommen und auf einer x96mini box installiert.


    RAM-Speicher: 1GB
    ROM-Speicher: 8GB
    Chipset: Amlogic S905W Quad-Core ARM Cortex


    Installiert habe ich das "CoreELEC-Amlogic-ng.arm-19.5-Matrix_devel_20220502084341-Generic.img" War das richtig ?


    Soweit hat wohl alles funktioniert - aber leider startet der VDR nicht.

    Sieht so aus als wenn das softhdodroid Plugin ein Problem hat.


    CoreELEC (community): 19.5-Matrix_devel_20220502084341 (Amlogic-ng.arm)

    -sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

    # ./start_vdr.sh

    killall: splash-image: no process killed

    vdr: /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1: undefined symbol: glBlitFramebuffer



    Was könnte das Problem sein (Außer vielleicht ich selbst :wand)

    Außerdem gibt es eine Art syslog auf dem System? habe nichts gefunden.

  • Außerdem gibt es eine Art syslog auf dem System? habe nichts gefunden.

    Das Log erreichst du mit journalctl -e.

    Installiert habe ich das "CoreELEC-Amlogic-ng.arm-19.5-Matrix_devel_20220502084341-Generic.img" War das richtig ?

    Generic? War da nicht etwas mit der richtigen dtb? Oder auch hier. Läuft denn Kodi überhaupt?

    killall: splash-image: no process killed

    Das irritiert mich, weil der Splash-Screen eigentlich als erstes gestartet wird.

  • Ja, die richtige dtb.bin ist offensichtlich installiert und Kodi läuft auch einwandfrei. Erst beim umschalten über das Kodi Menue auf den VDR wird's dunkel - kein OSD - nichts.


    wenn ich dann über ssh die start_vdr.sh ausführe kommt folgende Meldung in der Konsole:


    killall: splash-image: no process killed

    vdr: /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1: undefined symbol: glBlitFramebuffer


    Ich schaue mir morgen mal das log mit jornalctl -e an und melde mich dann nochmal.

  • Am Wochenende habe ich zwar eine Menge gebastelt aber nicht in den offiziellen Branches. Ich habe gerade nochmal die Version

    CoreELEC-Amlogic-ng.arm-19.5-Matrix_devel_20220502074916.tar installiert, die nahezu identisch mit deiner sein müsste.

    Allerdings boote ich erst mit VDR. Hast du das install.sh in /usr/local/bin ausgeführt? Den autostart eingerichtet?

    Aber das erkärt nicht das undefined symbol.


    Kannst du mal einldd /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1 machen um zu sehen, welche Libs evt. nicht gefunden werden?

    Was gibt denn ls -la /var/lib/libMali.so aus? Das müsste ein Link auf /usr/lib/libMali.<irgendwas>.so sein. Bei mir ist es /usr/lib/libMali.dvalin.so.


    Und wie sieht es mit ls -la /usr/lib/*GL* aus? Das müssten alles Links auf libMali.so sein.

    Hmm. glBlitFramebuffer klingt nach etwas in libMali. Die wird per LD_PRELOAD im start script geladen.

  • Hi,


    ich lese hier eher nur interessehalber mit, geht das denn überhaupt mit dem AMLOGIC S905W SOC von machtnix?


    im Ursprungsthread von Dieter wurde ja gewarnt vor evtl. auftretenden Problemen mit S905X4, X2, X, W und L,..

    dh explizit wurde nur der S905X3 und der S922X empfohlen,


    viele Grüsse pbg4

    vdr1:Produktivsystem: Zotac Box mit Atom 525/ION 2.Generation yaVDR 0.6.1 und satip plugin, mit digibit r1/minsatip
    vdr2:Zotac CI-320 vdr für ARD radio transponder und VDR Aufnahmen server yaVDR 0.6.1,.. und weiterer minisatip-server + Hauppauge WinTV-Quad HD,
    vdr3: testsystem: Shuttle NC02U mit Skylake und Softhddevice VAAPI/HEVC für DVB-T2, Ubuntu Zesty, VDR von Hand auf Basis yaVDR,..
    vdr4: testsystem: Acer Laptop ES11-132 mit Braswell und Softhddevice VAAPI/HEVC für DVB-T2, Ubuntu Zesty, VDR von Hand auf Basis yaVDR,..

  • Alles nochmal neu gebaut - Leider gleicher Fehler


    vdr: /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1: undefined symbol: glBlitFramebuffer



    CoreELEC:~ # ldd /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1


    CoreELEC:~ # ls -la /var/lib/libMali.so

    Code
    lrwxrwxrwx    1 root     root            24 Aug  6  2021 /var/lib/libMali.so -> /usr/lib/libMali.m450.so


    CoreELEC:~ # ls -la /usr/lib/*GL*


    Dann hat wohl pbg4 Recht mit seiner Vermutung, dass der AMLOGIC S905W SOC vom softhdondroid plugin nicht unterstützt wird :(


    Gruß

  • Hmm. Es ist alles da, wo es hingehört. Ein Build-Problem scheint nicht vorzuliegen.

    Vielleicht solltest du dich an jojo61 wenden oder im softhdodroid Thread nachfragen, ob mali450 unterstützt wird.

    Es könnte ein GLES2/GLES3 Problem sein, aber da bin ich überfragt.

  • Du kannst mit nm -D libMali.so | grep glBlitFramebufferprüfen, ob das symbol vorhanden ist, ich denke aber nicht.

    Die proprietäre libmali.so für Mali450 unterstützt nur striktes GLES2.0 und da ist glBlitFramebuffer nicht im Standard, das ist der Nachteil, wenn man es mit closed source zu tun hat...

    Du könntest dir Mesa mit dem lima Treiber für das S905W selber bauen bzw. ein aktuelles, fertiges Mesa nutzen. Soweit ich weiß, bietet Mesa auch bei GLES2.0 glBlitFramebuffer an - ob das dann schon reicht, weiß ich nicht.

    Alternativ könnte man openglosd so umbauen, dass es GLES2.0 Standards nutzt. Das habe ich damals in meinem fork gemacht.


    Gruß

    Andreas

  • Ich habe nun mal versucht das glBlitFrameBuffer raus zunehmen. Aber dann funktioniert irgendwie das Alphablending nicht mehr richtig. Bei jeder aktualisierung

    des OSD wird dann der Hintergrund dunkler bis er schwarz ist. Das könnte daran liegen das ich hier DMA nutze und der Framebuffer ein DRM Format hat.

    Dann stimmt wohl das Alpha handling in meinem Shader nicht mehr.

  • jojo61 Hast du deinen Code irgendwo liegen?

  • Das ganze liegt auf git: https://github.com/jojo/vdr-plugin-softhdodroid


    Die Änderung die ich zum testen gebaut hatte ist wie folgt (innerhalb des if 0):


  • Vielleicht fehlt dir das clear hier?

  • Nein das ändert leider auch nichts. Ich könnte das DMA rausnehmen, dann braucht es kein Blit, aber das möchte ich eigentlich nicht.


    Da es ja mit glBlit funktioniert sollte der Inputbuffer ja ok sein. Nur der Outputbuffer ist ja ein DRM Buffer. Warum da aber das Alpha nicht sauber funktioniert ist mir unklar.

  • Der Inputbuffer passt ja wahrscheinlich. Das Clear oben löscht den Outputbuffer, bevor der Inputbuffer als texture drauf gerendert wird.

  • Das Clear funktioniert aber wohl auf dem DRM Buffer nicht. Ich könnte das DMA bei der CPU ja weglassen, nur dann ist trotzdem das glBlit noch vorhanden (auch wenn es nicht genutzt wird). Um das weg zu bekommen müsste ich dann wieder einen Compiler #if drum herum bauen und das will ich nicht. Damit müsste man das dann für die CPU extra bauen.


    Kann man eine dummy funktion irgendwie einbauen die bei vorhandener Funktion in einer LIB überschrieben wird ?

  • Nur kurz zur Info. Ich habe ein neues Release erstellt. Darin ist einiges aufgeräumt worden, Updates für verschiedene Plugins und ein paar Fixes. Die Version ist 0.2.0.


    Ich hatte geplant, per Github Workflow automatisch ein Upload der Images zu machen, aber da ist noch ein Fehler in der Workflow-Definition. Und mit Github komme ich langsam an die Grenze von 6 Stunden per Lauf. Ich fürchte, da muss ich wieder umdenken.

    Deshalb sind alle Images (19.4 Stable, 19.5, 20) alle manuell hochgeladen worden und auf Github verfügbar. Ich hoffe, das senkt die Einstiegshürde etwas.

Jetzt mitmachen!

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