Installation eines VDR+Plugins nativ auf CoreELEC Boxen

  • Wenn das kompilieren genauso schnell ginge wie du neue Plugins reinlegst.. :) Über Nacht den Git stand von gestern Abend kompiliert, lief jedenfalls gut durch, werden dann jetzt nochmal pullen mit cecremote und nochmal kompilieren bevor es auf die box geht.


    Hättest du vielleicht noch die Möglichkeit auch das menuorg plugin hinzuzufügen?


    Vielen Dank nochmal, ich berichte dann nachher nochmal über erfolg/nicht-erfolg, wobei ich mittlerweile vom ersten ausgehe :)


    EDIT: hatte jetzt nur ein git pull gemacht ohne vorher alles zu löschen, da kommt beim VDR Start


    vdr: libcec.so.6: cannot open shared object file: No such file or directory


    ich versuche es nochmal mit alles löschen und neu pullen und komplett neu kompilieren

    VDR1+2: OctopusNet - Minisatip - X96 max plus 2

    Einmal editiert, zuletzt von reini-at ()

  • vdr: libcec.so.6: cannot open shared object file: No such file or directory


    ich versuche es nochmal mit alles löschen und neu pullen und komplett neu kompilieren

    Das klingt eher danach, als ob libcec irgendwie abhanden kommt. Ich hätte jetzt erwartet, daß der Build durchgeht.

    Ich nutze an der Stelle das Package von CoreELEC selbst, da die die Lib ja auch integriert haben. Muss ich schauen.


    Edit: Ich fass es nicht...

    Code
    ls -la build.CoreELEC-Amlogic-ng.arm-19-image-19-VDR/install_pkg/libcec-6.0.2/usr/lib
    lrwxrwxrwx 1 rh rh     11 27. Apr 16:20 libcec.so -> libcec.so.6
    lrwxrwxrwx 1 rh rh     20 27. Apr 16:20 libcec.so.6 -> /var/lib/libcec.so.6
    -rw-r--r-- 1 rh rh 361428 27. Apr 16:20 libcec.so.6.0.2

    /var/lib/libcec.so.6 gibt es bei mir gar nicht. Das müsste dann ja ein Link sein auf... libcec.so.6.0.2?

    Oder soll das irgendwie auf magische Weise beim Boot erzeugt werden? Ich kenne den Umweg über /var/lib nur für die libMali.

    Ich muss weiter gucken...


    Edit 2:

    Code
    # Remove the sysmlink and redirect to /var/lib so that we can change libcec versions at run time

    Hmm. Die Frage wäre, will jemand libcec überhaupt austauschen? Ist das notwendig?

    Es gibt 2 Möglichkeiten: Den Link wieder reparieren oder die libcec in /var/lib bereitstellen oder zumindest einen Link setzen.

    Ich bin da jetzt ziemlich unschlüssig und brauche einen Rat ;)


    Wenn das kompilieren genauso schnell ginge wie du neue Plugins reinlegst..

    Reine Übung. Wenn keine neuen Libs benötigt werden, geht das eigentlich recht schnell.

    2 Mal editiert, zuletzt von Zabrimus () aus folgendem Grund: libcec Problem erkannt...

  • also sagen wir mal so, die libcec von CoreELEC reicht denke ich? Wenn du mir sagen könntest wo ich den symlink anlegen soll, kann ich das schnell testen, die Box läuft gerade noch mit dieser version..

  • Hättest du vielleicht noch die Möglichkeit auch das menuorg plugin hinzuzufügen?

    Ich fürchte, ich muss menuorg erst einmal auf Eis legen. Die Abhängigkeiten bekomme ich in den gewünschten Versionen nicht kompiliert. Ich hatte es zwar mal geschafft, neuere Versionen von glib/glibmm/sigc++/libxml++/... zu kompilieren, aber dann will menuorg selber nicht mehr und müsste erstmal portiert werden.

    Aktuell hänge ich noch ziemlich am Anfang mit glib. CoreELEC hat auch schon eine höhere Version von glib und alles beisst sich da.

  • Hallo Zabrimus,leider kann ich im VDR kein Deutsch (Auswahl nur English) einstellen.

    Hast Du ne Idee?


    Danke für Deine Mühe.


    Gruß

    kla.b

    VDR 1 : yavdr ansible focal, Asus M3N-HDMI, AMD x240, 2x TT3200,1x Sundtek DVB-C, 6 TB HDD

    VDR 2 : yavdr ansible focal, ASRock J5005, DVBSky S952 Dual

    VDR 3 : reelVDR, IBM Thinkcenter, HDe, am Beamer Sony AW15

  • Hi Kla.b


    in der Readme steht:

    Zitat

    Switch OSD languange

    To be able to switch the OSD languange you have to

    • install Kodi addon: locale
    • configure Kodi addon locale and choose your desired language
    • create/modify file /storage/.profile with (in my case it's german):
      export LANG="de_DE.UTF-8"
      export LC_ALL="de_DE.UTF-8
    • reboot

    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

  • Hallo Markus,

    danke. Wer lesen kann :)


    Gruß

    kla.b

    VDR 1 : yavdr ansible focal, Asus M3N-HDMI, AMD x240, 2x TT3200,1x Sundtek DVB-C, 6 TB HDD

    VDR 2 : yavdr ansible focal, ASRock J5005, DVBSky S952 Dual

    VDR 3 : reelVDR, IBM Thinkcenter, HDe, am Beamer Sony AW15

  • Hi Zabrimus,


    Der VDR beinhaltet die Patches:

    (..)

    vdr-2.4.6-dynamite.patch

    vdr-plugin-easyvdr.patch



    Du musst dich für eines der beiden Plugins entscheiden, da sich die Patches beißen.

  • Der VDR beinhaltet die Patches:

    (..)

    vdr-2.4.6-dynamite.patch

    vdr-plugin-easyvdr.patch

    Du meinst nicht die Patches selbst sind das Problem, sondern der Start beider Plugins gleichzeitig? Der Patch von easyvdr sieht ziemlich minimal-invasiv aus, sofern das Plugin nicht läuft.

    Das muss ich ausprobieren. Produktiv würde ich eher nicht alle Plugins hleichzeitig starten wollen, dies dient eher zum Test.

  • Der easyvdr Patch macht nicht viel. Mit voller Absicht iminmal inversiv; solange das Plugin nic ht geladen ist, ist die Funktion 1:1 wie ungepatcht.


    Aber der dynamite Patch verändert VDR viel zu stark und am Ziel vorbei.


    Beide Plugins versuchen zur Laufzeit DVB devices nachzuladen, nur verhält sich dynamite sehr inkompatibel und belegt alle.

    Das gibt nur Ärger, falls jemand auf die Idee kommt die gleiche Funktion in easyvdr zu nutzen, ohne zu wissen, dass diese

    Funktion durch den dynamite Patch in die Asche geht. Nimm einfach eines der Plugins aus dem Rennen.

  • Der easyvdr Patch macht nicht viel. Mit voller Absicht iminmal inversiv; solange das Plugin nic ht geladen ist, ist die Funktion 1:1 wie ungepatcht.

    Aber der dynamite Patch verändert VDR viel zu stark und am Ziel vorbei.

    Ich habe das build-local.sh  angepasst und überlasse es jetzt dem Builder, welches Plugin samt Patch verwendet werden soll. Per Default ist keines der beiden aktiv.


    build-local.sh hat die 3 zusätzlichen Parameter:

    Code
    -d  : Enable vdr-plugin-dynamite. Default is disabled.
    -e  : Enable vdr-plugin-easyvdr. Default is disabled.
    -z  : Enable zapcockpit. Default is disabled.

    Damit kann man den VDR jetzt bequem ohne jeglichen Patch bauen.


    Als Zusatznutzen (zumindest für mich) kann ich alle Branches und Builds in einem einzigen Kommando ausführen lassen. Was aber nur dazu dient, die build.* Verzeichnisse neu aufbauen zu lassen, falls etwas sehr strubbelig geworden ist. Und das auch eher über Nacht oder wenn ich den Rechner gerade stundenlang nicht brauche.

  • Versuch mal

    cd /var/lib && ln -s /usr/lib/libcec.so.6.0.2 libcec.so.6

    das resultiert leider in ein segfaul:

    ./start_vdr.sh: line 35: 4654 Segmentation fault sh -c "LD_PRELOAD=/usr/lib/libMali.so LD_LIBRARY_PATH=$LIB_DIR:$LIB_DIR/vdr:$LD_LIBRARY_PATH ${BIN_DIR}/$arg"


    woher auch immer das kommt :/

  • das resultiert leider in ein segfaul:

    ./start_vdr.sh: line 35: 4654 Segmentation fault sh -c "LD_PRELOAD=/usr/lib/libMali.so LD_LIBRARY_PATH=$LIB_DIR:$LIB_DIR/vdr:$LD_LIBRARY_PATH ${BIN_DIR}/$arg"

    Hmm. Bei mir klappt das.

    Naja. Das Plugin ist nicht konfiguriert, aber zumindest scheint es zu starten und etwas zu machen zu versuchen.


    Kannst du mal per journalctl -xeschauen, ob es Hinweise auf die Ursache gibt? Debuggen ist da eher schwierig.

  • danke, da hätte ich auch draufkommen können...... das war sehr billig:


    [cecremote] Can not open file /storage/.config/vdropt/plugins/cecremote/cecremote.xml for getting line number

    kaum legt man dort das richtige file hin geht es auch :)


    EDIT: der symlink für die libcec.so.6 scheint kein neustart zu überleben bei mir, habe es mal in die autostart.sh eingefügt.

    VDR1+2: OctopusNet - Minisatip - X96 max plus 2

    Einmal editiert, zuletzt von reini-at ()

  • EDIT: der symlink für die libcec.so.6 scheint kein neustart zu überleben bei mir, habe es mal in die autostart.sh eingefügt.

    Genau das ist mir gerade auch aufgefallen, als ich die letzten Aufräumarbeiten starten wollte. Sehr seltsam. Ich hätte gedacht, daß es länger hält.

    Ich werde das Link generieren aus dem install Script nehmen und in das autostart übernehmen.

  • Einen offenen Punkt habe ich noch, um den ich mich bisher gedrückt habe: svdrpsend.


    svdrpsend ist ein perl Script und perl ist standardmäßig nicht installiert. Man kann es über entware aus dem Repository nachinstallieren.

    Aber dazu fallen mir nur Spatzen und Kanonen ein. Die Frage ist: Wird svdrpsend auf der Maschine benötigt? Gibt es Alternativen, die man nutzen kann? Hat da jemand vielleicht schon was oder zumindest eine Idee?


    Edit:

    Hat sich wohl erledigt. Das Wiki ist ein Quell des Wissens. Auf der Maschine gibt es netcat und damit funktioniert sowas:

    Code
    echo mesg 'Hello World!' | nc localhost 6419

    Ein einfaches Script kann man da auch finden. Das Script im Wiki werde ich wohl noch übernehmen :)

  • Habe nun auch mal auf einem neuen Ubuntu 20.04 versucht das ganze zu bauen. Leider ohne Erfolg. build-local.sh -i bricht damit ab:


    Code
    /tmp/kodi.bin.DfASeg.ltrans121.ltrans.o:<artificial>:function KODI::WINDOWING::AML::CWinSystemAmlogicGLESContext::CreateNewWindow(std::string const&, bool, RESOLUTION_INFO&): error: undefined reference to 'CEGLContextUtils::CreateSurface(fbdev_window*, int)'
    collect2: error: ld returned 1 exit status
    ninja: build stopped: subcommand failed.

    Da fehlt mir wohl noch ne Library oder ?

  • Habe nun auch mal auf einem neuen Ubuntu 20.04 versucht das ganze zu bauen. Leider ohne Erfolg. build-local.sh -i bricht damit ab:

    Du bist schon der zweite mit genau demselben Fehler. Das ist doch ... Das scheint beim linken von Kodi zu passieren.

    Baut du den 19er oder 20er Branch? Oder gar das stable Matrix Image oder tar?


    Ich lösch bei mir nochmal alles und bau neu.

  • Neu gebaut auf dem Entwicklungsrechner (Debian 11) und in einem ganz neuen Ubuntu 20.04 LXD Container. Im Container habe nur genau das gemacht, was auch im Readme steht: apt install, git clone, build-local.sh -9 -e.


    Und alles lief ohne Probleme durch. Dann habe ich den build-Plan (tools/viewplan) zwischen beiden Rechnern verglichen und der Plan ist identisch.


    Die Suche nach der vermissten Klasse CEGLContextUtils brachte einen Treffer in kodi/xbmc/utils/EGLUtils.cpp.

    Darin befindet sich

    bool CEGLContextUtils::CreateSurface(EGLNativeWindowType nativeWindow, EGLint HDRcolorSpace /* = EGL_NONE */)

    Vermisst wird CEGLContextUtils::CreateSurface(fbdev_window*, int). Ob die Typen jetzt kompatibel sind, könnte man prüfen.


    Es ist so keine Library, die fehlt, sondern der Code wird von Kodi direkt mitgeliefert.

    Hat der Rechner genug Arbeitsspeicher? Linker-Probleme mit Kodi hatte ich auch mit Github Workflows. Das habe ich da auf den mangelnden Speicher geschoben und versucht zu tricksen (mehr swap, weniger HD und umgekehrt) - ohne Erfolg.


    Funktioniert denn der Build ganz ohne VDR? Also quasi so echt richtig Orginal CoreELEC?

    Code
    export VDR="no"
    ./build-local -9

Jetzt mitmachen!

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