Installation eines VDR+Plugins nativ auf CoreELEC Boxen

  • Sehr positiv überrascht war ich über das Ausgabeplugin (softhdodroid), das einfach seinen Dienst macht und nicht klagt. Mit Ton, Bild und allem.

    Da hat jojo61 ja auch hart dran gearbeitet und diverse Patches vorgenommen, damit das Plugin auch mit dem 5er-Kernel läuft. :thumbup:

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Die Reboot-Probleme von CE22-no lassen sich eindeutig auf die NFS Mount zurückführen. Ein ganz frisches System mit einem Mount in /system/storage/system.d führte nur zu einer Reboot-Schleife.

    Der Mount auf der Konsole brachte dann die Erleuchtung: Ich hatte auf dem Server die Exports geändert (neue Platte) und die Konfiguration auf dem Testsystem nicht nachgezogen.


    Eine Korrektur führte noch zu einer neuen Schleife, aber danach startete Kodi endlich. Ein Reboot bzw. sogar eine Reboot-Schleife halte ich für eine wenig sinnvolle Fehlerbehandlung von NFS Mounts. Da war CE20 deutlich toleranter. Was passiert denn, wenn der Server nicht erreichbar ist?


    Edit:

    Ich finde auch gerade ein frisches Logfile in /storage/inject_bl301.log mit dem Inhalt

    /usr/sbin/inject_bl301: /usr/lib/libcurl.so.4: version `CURL_OPENSSL_4' not found (required by /usr/sbin/inject_bl301)


    Der Inject braucht curl? Wozu? Und warum ist es nicht da?

  • Sehr positiv überrascht war ich über das Ausgabeplugin (softhdodroid), das einfach seinen Dienst macht und nicht klagt. Mit Ton, Bild und allem


    Da hat jojo61 ja auch hart dran gearbeitet und diverse Patches vorgenommen, damit das Plugin auch mit dem 5er-Kernel läuft. :thumbup:


    Ok, gilt die Aussage auch für Libreelec mit 6er Kernel?

  • Ok, gilt die Aussage auch für Libreelec mit 6er Kernel?

    Nein. softhdodroid funktioniert nicht mit mainline Kernel, der von LE nutzt wird, und deshalb nur mit CoreELEC. Für LibreELEC müsstest du softhddevice-drm-gles nehmen.

  • Kompiliere selber mit ./build.sh -config CoreELEC-21-ng -extra dynamite,channellogos -addon dvb-latest,dvb-tools,network-tools,system-tools

    Bin also mit CoreELEC-21-ng unterwegs.


    Nutze VDR als Hauptfrontend, nun habe ich seit langem mal wieder Kodi gestartet und stelle fest das es keine Möglichkeit zurück zum VDR gibt?

    War das nicht oben links unter dem "Stecker" Symbol aufzurufen?

  • War das nicht oben links unter dem "Stecker" Symbol aufzurufen?

    Das sollte eigentlich so sein. Ich habe das gerade mal bei mir geprüft und tatsächlich ist da nix zu finden. Auch Änderungen an DialogButtonMenu.xml bringen nix.


    Dann habe ich im Kodi-Log das gefunden:

    Code
    2024-05-16 07:18:57.713 T:5046  warning <general>: CAddonMgr::FindAddons: Addon 'skin.estuary' already present with higher version 3.0.10 at '/usr/share/kodi/addons/skin.estuary/' - other version 3.0.5 at '/storage/.kodi/addons/skin.estuary/' will be ignored

    Das bedeutet, das die Version in /storage/.kodi gar nicht verwendet wird, sondern nur die mitgelieferte. Eieiei.... Sowas habe ich nicht vorhergesehen.


    Was ich testweise gemacht habe ist folgendes:

    Code
    cd /storage/.kodi/addons/skin.estuary
    cp -a /usr/share/kodi/addons/skin.estuary/* .

    Danach die xml/DialogButtonMenu.xml geändert und den VDR Eintrag - wie oben beschrieben - hinzugefügt, Kodi restartet und der Button für den Wechsel nach VDR ist wieder da.

    Ich werde mal schauen, ob ich den VDR-Eintrag nicht direkt in den Skin einbauen kann und vielleicht ein Copy-Script für den Skin. Problem ist nur, daß ich nicht weiß, ob jemand selbst lokal am Skin bastelt und die Änderungen überschrieben würden.

  • Für das Power-Menu habe ich für den Default Theme estuary nun 2 Patches (für CE und LE) committed, die den VDR Eintrag gleich per Default in die Images packt.

    Damit sollte bei spontanen Skin-Updates das Problem mit dem Wechsel zu VDR nicht mehr auftauchen.

  • Hallo Zabrimus,


    ich habe gestern mal auf meinen ODROID N2+ ein Upgrade von Nexus 20.5 auf Omega 21.1 versucht.


    Nachdem in Kodi die Addons migriert bzw. aktualisiert sind und ich gebootet habe, zeigt sich ein seltsamer Fehler:

    Der cefbrowser startet nicht.


    Code
    CoreELEC:~ # journalctl -u cefbrowser
    Mai 18 16:43:04 CoreELEC systemd[1]: Started cefbrowser.service.
    Mai 18 16:43:04 CoreELEC docker[6611]: /app_bin/cefbrowser: error while loading shared libraries: libfmt.so.10: cannot open shared object file:  No such file or directory
    Mai 18 16:43:05 CoreELEC systemd[1]: cefbrowser.service: Main process exited, code=exited, status=127/n/a
    Mai 18 16:43:05 CoreELEC systemd[1]: cefbrowser.service: Failed with result 'exit-code'.
    Mai 18 16:43:08 CoreELEC systemd[1]: cefbrowser.service: Scheduled restart job, restart counter is at 29.
    Mai 18 16:43:08 CoreELEC systemd[1]: Started cefbrowser.service.


    Es wird eine Library nicht gefunden und dann alle paar Sekunden versucht neu zu starten.


    Das Ganze passiert mit meiner selbst kompilerten Version von VDRSternELEC als auch mit einem Release von Dir vom 4.5.


    Hast Du eine Idee, was da nicht passt?


    Schöne Grüße

    Lothar

  • Mai 18 16:43:04 CoreELEC docker[6611]: /app_bin/cefbrowser: error while loading shared libraries: libfmt.so.10: cannot open shared object file: No such file or directory

    Das sieht so aus, als ob im Docker-Container etwas fehlen würde. Was mich allerdings ziemlich wundert, weil der Browser und der Container sich gar nicht geändert hat.


    CoreELEC 20 hat ein 9er libfmt Paket und CoreELEC 21 ein 10er. Aber im Container selbst sollte das doch egal sein, was auf dem Host installiert ist.

    Ich muss das Problem nachstellen um zu schauen, was da schief geht. Der Docker Container basiert auf debian:bookworm und libfmt10 gibt es erst in experimental. Im Container selbst wird libfmt9 installiert.


    Ahhh.. Mist. Ich glaube, ich komme so langsam dahinter. Der Browser wird beim Build auch gebaut und damit hat der eine Abhängigkeit zu libfmt10 (seit CE 21), das es aber im Container noch gar nicht geben kann.


    Ich muss ein neues libfmt9 Paket für den Browser hinzufügen und ich hoffe, daß nicht noch andere Libs betroffen sind.

  • Meine erste Idee hatte unangenehme Nebenwirkungen. Jetzt bin ich direkt an die Quelle gegangen und baue den Browser bzw. das abhängige spdlog (und damit libfmt) anders. Damit sollte generell die Abhängigkeit zur externen libfmt beseitigt sein.

    Ich hoffe, es gibt kein anderes ähnliches Problem.

  • Natürlich funktioniert nicht alles auf Anhieb. Wie sollte es auch anders sein :(


    Ich habe für CE21 ein neues Docker-Image erstellen müssen - auf Basis von Debian Trixie (testing). Um den Browser in CE21 wieder zum laufen zu bekommen muss folgendes erledigt werden:

    - Browser stoppen (systemctl stop cefbrowser)

    - Alle Browser Images im docker löschen. Auf jeden Fall das Image cefbrowser-base: docker rmi cefbrowser-base

    - Neues Image pullen: docker pull ghcr.io/zabrimus/cefbrowser-base-ce21-armv7:latest

    - Die Datei /storage/.config/system.d/cefbrowser.service anpassen.

    Am Ende das ghcr.io/zabrimus/cefbrowser-base:latest durch ghcr.io/zabrimus/cefbrowser-base-ce21-armv7:latest ersetzen.

    - systemctl daemon-reload

    - systemctl start cefbrowser


    Wenn ich keinen Schritt zu erwähnen vergessen habe, sollte es mit CE21-ng wieder funktionieren. Das ganze muss ich nur noch in die Paket-Installation einpacken.


    Ich muss endlich mal schauen, ob mit CE22 auf Docker verzichtet werden kann und der ganze Spaß irgendwann ein Ende hat.

  • Morgen Zabrimus,


    ich habe jetzt das aktuelle Repo gepulled und CE21 neu gebaut.


    Dann deine obigen Steps ausgeführt. Leider wird jetzt libfmt.so.10 nicht gefunden, auch nach einem Reboot.

    Code
    Mai 19 11:06:39 CoreELEC systemd[1]: Started cefbrowser.service.
    Mai 19 11:06:43 CoreELEC docker[3926]: /app_bin/cefbrowser: error while loading shared libraries: libfmt.so.10: cannot open shared object file: No such file or directory
    Mai 19 11:06:43 CoreELEC systemd[1]: cefbrowser.service: Main process exited, code=exited, status=127/n/a
    Mai 19 11:06:43 CoreELEC systemd[1]: cefbrowser.service: Failed with result 'exit-code'.
    Mai 19 11:06:46 CoreELEC systemd[1]: cefbrowser.service: Scheduled restart job, restart counter is at 1.
    Mai 19 11:06:46 CoreELEC systemd[1]: Started cefbrowser.service.

    Noch eine Idee?

    Schöne Grüße
    Lothar

  • Hast du das Docker-Image und das systemd Script aktualisiert?

    Ja!



    PS Ich sehe grade

    Code
    CoreELEC:~ # ll /usr/local/bin/cefbrowser
    -rwxr-xr-x    1 root     root       2638316 Mar  5 05:58 /usr/local/bin/cefbrowser

    Sollte da was aktuelles stehen?

  • libfmt.so.10 hätte gar nicht mehr auftauchen dürfen.


    Kannst du mal das Ergebnis von

    Code
    ldd /usr/local/bin/cefbrowser 

    prüfen?


    Auf CE21 müsste das so aussehen:

    Code
    ldd /usr/local/bin/cefbrowser  
    libcef.so => not found
    libssl.so.3 => /usr/lib/libssl.so.3 (0xf72e1000)
    libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0xf6feb000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf6e00000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xf6de3000)
    libc.so.6 => /usr/lib/libc.so.6 (0xf6c93000)
    /lib/ld-linux-armhf.so.3 => /usr/lib/ld-linux-armhf.so.3 (0xf738e000)
    libm.so.6 => /usr/lib/libm.so.6 (0xf6c4f000)

    Auf meiner älteren (noch nicht aktualisierten) CE20 Maschine hingegen sieht das noch so aus:

    Der einzige Unterschied ist eben genau

    Code
    libfmt.so.9 => /usr/lib/libfmt.so.9 (0xf720d000)
  • Ein andere Idee habe ich noch. Vielleicht wird subproject spdlog nicht wirklich neu gebaut. Ich nehme an, du behälst das Build-Verzeichnis und machst nur einen neuen Build, oder?


    Dann versuche mal vor dem Build

    Code
    cd CoreELEC
    PROJECT=Amlogic-ce DEVICE=Amlogic-ng scripts/clean _cefbrowser

    Und dann den Build normal starten.

  • Bedi mir sieht's so aus:


    Auf CE21



    Auf CE20

    Der cefbrowser selbst ist jeweils von Anfang März.

  • Ich habe gestern erst den Browser aktualisiert. Das würde das Problem erklären.


    Also muss man tatsächlich ein neues Build erzwingen:

    cd CoreELEC

    PROJECT=Amlogic-ce DEVICE=Amlogic-ng scripts/clean _cefbrowser


    Die Versionsnummer des Browser muss "4bdb4fd8...." sein:

    Code
    cat packages/vdr/vdr-depends/_cefbrowser/package.mk  | grep "^PKG_VERSION"
    PKG_VERSION="4bdb4fd86499e9bf85b8f8db7dd2dd8ab0c97133"
  • So, Build ist nach dem clean durch, jetzt passt alles!


    Code
    CoreELEC:~/.config/system.d # ldd /usr/local/bin/cefbrowser
    libcef.so => not found
    libssl.so.3 => /usr/lib/libssl.so.3 (0xf7315000)
    libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0xf701f000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf6e34000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xf6e17000)
    libc.so.6 => /usr/lib/libc.so.6 (0xf6cc7000)
    /lib/ld-linux-armhf.so.3 => /usr/lib/ld-linux-armhf.so.3 (0xf73c2000)
    libm.so.6 => /usr/lib/libm.so.6 (0xf6c83000)

    Der Browser läuft jetzt auch unter CE21.


    Danke Dir!
    Lothar

Participate now!

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