Installation eines VDR+Plugins nativ auf CoreELEC Boxen

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?

Ich gebe es auf. Mit CE-no 22 oder wahrscheinlicher mit dem Kernel stimmt etwas ganz und gar nicht.

Ein einfaches

/usr/bin/mount -t nfs 192.168.178.9:/mnt/video /storage/mount/video

auf der Console und das System rebootet.

Zitat von vdr_rossi

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:

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:

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.

Zitat von LotharE

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.

Zitat von LotharE

Noch eine Idee?

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

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

Kannst du mal das Ergebnis von

ldd /usr/local/bin/cefbrowser 

prüfen?

Auf CE21 müsste das so aussehen:

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:

ldd /usr/local/bin/cefbrowser  
/usr/lib/libarmmem-v7l.so => /usr/lib/libarmmem-v7l.so (0xf71c0000)
libfmt.so.9 => /usr/lib/libfmt.so.9 (0xf720d000)
libcef.so => not found
libssl.so.3 => /usr/lib/libssl.so.3 (0xf714b000)
libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0xf6e7a000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf6cb0000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xf6c70000)
libc.so.6 => /usr/lib/libc.so.6 (0xf6b00000)
/lib/ld-linux-armhf.so.3 => /usr/lib/ld-linux-armhf.so.3 (0xf71e9000)
libm.so.6 => /usr/lib/libm.so.6 (0xf6a90000)

Der einzige Unterschied ist eben genau

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

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

Und dann den Build normal starten.

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

Also muss man tatsächlich ein neues Build erzwingen:

Zitat von Zabrimus

cd CoreELEC

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

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

cat packages/vdr/vdr-depends/_cefbrowser/package.mk  | grep "^PKG_VERSION"
PKG_VERSION="4bdb4fd86499e9bf85b8f8db7dd2dd8ab0c97133"