[VDR*ELEC] - LibreELEC/CoreELEC mit VDR Client

Zabrimus · August 31, 2025 at 9:56 AM

Der lokale Build ist endlich soweit durchgekommen, daß libplacebo mit der bekannten Meldung scheitert. Endlich habe ich eine Chance zu schauen, ob ich eine Lösung finden kann.

Zabrimus · August 31, 2025 at 11:42 AM

Ich verstehe es nicht und bin mir nicht sicher, ob der Patch (committed) funktioniert

1. fehlerhaften Patch erstellt und das ging natürlich schief
2. den fehlerhaften Patch noch erweitert und das ging auch schief
3. den fehlerhaften Patch gelöscht und auf einmal baut alles

Ich komme auch nicht mehr zurück ohne wieder einen ganz neuen Build zu starten. Irgendwas im Build-Verzeichnis hat sich repariert.
Wenn die letzten Commits auch nicht funktionieren, dann muss ich wohl wieder neu bauen. Aber hoffen wir erstmal.

vdr_rossi · August 31, 2025 at 12:08 PM

Bin auch dabei verschiedene Sachen zu probieren.

Angefangen mit einer frischen Ubuntu 20.04 VM. Da klemmt es schon zu Anfang bei e2fsprogs:host
Auch einzeln manuell bauen klappt nicht (./build.sh -config LibreELEC-12-x86_64-x11 -extra dynamite -package e2fsprogs:host)

Außerdem versuchte ich die 13er Version. Scheitert auch gleich zu Anfang.

Bleibe weiter dran.

vdr_rossi · August 31, 2025 at 1:20 PM

Hatte meine ursprüngliche 22.04 build vm zwischendurch auch auf 24.04 upgedatet...

Darauf ist der build jetzt komplett durchgelaufen

vdr_rossi · September 3, 2025 at 8:14 PM

Wie ändere ich /usr/local/bin/autostart.sh ?

verwende softhddrm und muss nicht nur kodi beenden, sondern auch xorg

# Start either Kodi or VDR on reboot

. /storage/.profile

if [ "${START_PRG}" = "vdr" ]; then

systemctl stop kodi && systemctl stop xorg

if [ "Generic" = "Amlogic-ce" ]; then

echo 4 > /sys/module/amvdec_h264/parameters/dec_control

fi

systemctl start vdropt

fi

Die Datei liegt im squashfs Dateisystem und lässt sich nicht ändern. Einen Ablageort im build System habe ich nicht gefunden, wo ich es auch hätte ändern können.

Zabrimus · September 3, 2025 at 8:22 PM

Quote from vdr_rossi

Die Datei liegt im squashfs Dateisystem und lässt sich nicht ändern. Einen Ablageort im build System habe ich nicht gefunden, wo ich es auch hätte ändern können.

Nicht im Build, aber im System unter /storage/.config/autostart.sh.

vdr_rossi · September 3, 2025 at 8:28 PM

Ja, aber darin wird ja wieder weiter verwiesen:

Bash

#!/bin/sh
/usr/local/bin/autostart.sh

Oder kopiere ich den Inhalt, von der nicht änderbaren, einfach komplett da rein? Oder kann ich mischen?

rell · September 3, 2025 at 8:40 PM

Quote from vdr_rossi
Ja, aber darin wird ja wieder weiter verwiesen:
Bash
#!/bin/sh
/usr/local/bin/autostart.sh
Oder kopiere ich den Inhalt, von der nicht änderbaren, einfach komplett da rein? Oder kann ich mischen?

autostart.sh wird doch nur beim ersten Start aufgerufen, oder? Wäre es nicht sinnvoller, die systemd services zu ändern? Da könntest du dann ein Skript ausführen, das in /storage liegt.

jojo61 · September 3, 2025 at 11:26 PM

Du kannst den "systemctl stop xorg" doch gleich in "/storage/.config/autostart.sh" ablegen. Da baue ich auch immer alles ein was ich so brauche.

vdr_rossi · September 4, 2025 at 2:11 PM

D.h. ich kann doch mischen?

Dachte ich kann nur von Datei a a auf Datei b verweisen, aber nicht Befehle in Datei a platzieren und auf weiteren Befehlen in Datei b verweisen?
Aber in diesem Fall geht es nicht anders.

Werde es einfach ausprobieren.

Außerdem schaue ich mir Realisierungsmöglichkeiten per systemd service an.

jojo61 · September 4, 2025 at 2:42 PM

Quote from vdr_rossi

D.h. ich kann doch mischen?

Das sind doch Aufrufe von scripten und keine links. Natürlich kannst du in "/storage/.config/autostart.sh" alles machen was du willst. Alles was du vor dem VDR machen willst muss dann vor den Aufruf "/usr/local/bin/autostart.sh"

jojo61 · September 14, 2025 at 12:10 PM

Zabrimus bitte aktualisiere doch mal dash2ts im VDR*Elec. Das ist leider etwas veraltet und stört mich beim entwickeln

Ausserdem bin ich über deine serversenke gestolpert. Bisher hat dein script meine sourcen immer aus meinem GIT geholt Kann ich das irgendwie beim build umgehen das es von der serversenke geholt wird.

Zabrimus · September 14, 2025 at 12:55 PM

Quote from jojo61

bitte aktualisiere doch mal dash2ts im VDR*Elec. Das ist leider etwas veraltet und stört mich beim entwickeln

Öhm? Der letzte Commit in deinem Repository ist schon 2 Monate alt.

Code

jojo61 Fix for Coreelec-NE Version b3fcf73  · 2 months ago

Hast du das Repository geändert oder evt. deine Änderungen nicht gepushed?

Quote from jojo61

Ausserdem bin ich über deine serversenke gestolpert.

Die serversenke wird nur als allerletztes Fallback verwendet, wenn sowohl das offizielle Repository, als auch die Spiegel von CoreELEC und LibreELEC die Sourcen nicht haben. Sollte serversenke weg sein, dann würde das Build mit fliegenden Fahnen untergehen, weil die Sourcen nicht geladen werden können.

jojo61 · September 14, 2025 at 1:13 PM

Quote from Zabrimus

Öhm? Der letzte Commit in deinem Repository ist schon 2 Monate alt.

Deine package.mk ist aber noch älter Da wird noch die Version 1fb9ca9 geholt.

LotharE · September 14, 2025 at 2:59 PM

Hi Zabrimus,

habe eben nochmal CE21-ng gebaut.

Beim Starten des VDRs bekomme ich jetzt diesen Fehler:

Code

Sep 14 14:43:00 CoreELEC vdr[19138]: [19138] loading plugin: /usr/local/lib/vdr/libvdr-softhdodroid.so.9
Sep 14 14:43:00 CoreELEC vdr[19138]: [19138] loading plugin: /usr/local/lib/vdr/libvdr-satip.so.9
Sep 14 14:43:00 CoreELEC vdr[19138]: [19138] loading plugin: /usr/local/lib/vdr/libvdr-skinnopacity.so.9
Sep 14 14:43:00 CoreELEC vdr[19138]: [19138] loading plugin: /usr/local/lib/vdr/libvdr-epgsearch.so.9
Sep 14 14:43:00 CoreELEC vdr[19138]: [19138] loading plugin: /usr/local/lib/vdr/libvdr-femon.so.9
Sep 14 14:43:00 CoreELEC vdr[19138]: [19138] loading plugin: /usr/local/lib/vdr/libvdr-systeminfo.so.9
Sep 14 14:43:00 CoreELEC vdr[19138]: [19138] ERROR: /usr/local/lib/vdr/libvdr-systeminfo.so.9: cannot open shared object file: No such file or directory

Ist das Plugin Systeminfo hier rausgeflogen; ohne geht's ?

PS

Beim Build for CE22-no bekomme ich ich seit einiger Zeit diesen Fehler:

Code

../../util/subst -f ../../util/subst.conf /home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib/dirpaths.h.in ../../lib/dirpaths.h
/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/toolchain/bin/host-gcc -I. -I../../lib -I/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib  -march=native -O2 -Wall -pipe -I/home/lothar/V                                                                                       DRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/toolchain/include -Wno-format-security   -DHAVE_CONFIG_H  -c /home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib/support/cstring.c -o cstring.o
/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/toolchain/bin/host-gcc -I. -I../../lib -I/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib  -march=native -O2 -Wall -pipe -I/home/lothar/V                                                                                       DRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/toolchain/include -Wno-format-security   -DHAVE_CONFIG_H  -c /home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib/support/mkquota.c -o mkquota.o
/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/toolchain/bin/host-gcc -I. -I../../lib -I/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib  -march=native -O2 -Wall -pipe -I/home/lothar/V                                                                                       DRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/toolchain/include -Wno-format-security   -DHAVE_CONFIG_H  -c /home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib/support/plausible.c -o plausible.o
/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib/support/plausible.c: In function 'check_partition_table':
/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib/support/plausible.c:132:2: error: unknown type name 'blkid_probe'
  132 |  blkid_probe pr;
      |  ^~~~~~~~~~~
/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib/support/plausible.c:136:7: warning: implicit declaration of function 'blkid_new_probe_from_filename' [-Wimplicit-function-declaration]
  136 |  pr = blkid_new_probe_from_filename(device);
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib/support/plausible.c:140:8: warning: implicit declaration of function 'blkid_probe_enable_partitions' [-Wimplicit-function-declaration]
  140 |  ret = blkid_probe_enable_partitions(pr, 1);
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib/support/plausible.c:144:8: warning: implicit declaration of function 'blkid_probe_enable_superblocks' [-Wimplicit-function-declaration]
  144 |  ret = blkid_probe_enable_superblocks(pr, 0);
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib/support/plausible.c:148:8: warning: implicit declaration of function 'blkid_do_fullprobe' [-Wimplicit-function-declaration]
  148 |  ret = blkid_do_fullprobe(pr);
      |        ^~~~~~~~~~~~~~~~~~
/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib/support/plausible.c:152:8: warning: implicit declaration of function 'blkid_probe_lookup_value' [-Wimplicit-function-declaration]
  152 |  ret = blkid_probe_lookup_value(pr, "PTTYPE", &value, NULL);
      |        ^~~~~~~~~~~~~~~~~~~~~~~~
/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/lib/support/plausible.c:160:2: warning: implicit declaration of function 'blkid_free_probe' [-Wimplicit-function-declaration]
  160 |  blkid_free_probe(pr);
      |  ^~~~~~~~~~~~~~~~
make[3]: *** [Makefile:416: plausible.o] Error 1
make[3]: Leaving directory '/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/.x86_64-linux-gnu/lib/support'
make[2]: *** [Makefile:457: all-libs-recursive] Error 1
make[2]: Leaving directory '/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/.x86_64-linux-gnu'
make[1]: *** [Makefile:372: all] Error 2
make[1]: Leaving directory '/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/e2fsprogs-1.47.3/.x86_64-linux-gnu'
FAILURE: scripts/build e2fsprogs:host during make_host (default)
*********** FAILED COMMAND ***********
make ${PKG_MAKE_OPTS_HOST}
**************************************
FAILURE: scripts/build e2fsprogs:host has failed!

Display More

Auch wenn ich in eine neues Verzeichnis abrufe, kommt dieser Fehler. Ich sehe dass bei deinen Releases der Build für CoreELEC-22-no wohl klappt.

Liegt's evtl. an meinem Host-System, Debian 11 auf x86-64 mit Kernel 6.10 ?

Zabrimus · September 14, 2025 at 3:24 PM

Quote from jojo61

Deine package.mk ist aber noch älter Da wird noch die Version 1fb9ca9 geholt.

Ich habe mich zu sehr auf das update-Script verlassen. Nur muss man es auch geeignet aufrufen. Update ist drin.

Zabrimus · September 14, 2025 at 3:27 PM

Quote from LotharE

Ist das Plugin Systeminfo hier rausgeflogen; ohne geht's ?

Ich habe es nicht mehr compiliert bekommen und muss noch schauen, was da genau falsch ist.

Quote from LotharE

e2fsprogs:host

Das Problem habe/hatte ich auch immer wieder. Die Ursache ist unklar und ich weiß nicht woran es liegt und wie man es beseitigt. Irgendwann ging der Build durch und seitdem hoffe ich, es gibt für das Package kein Update. Vielleicht man einen echt frischen Build versuchen.

Ich baue auf Ubuntu Jammy (22.04) und Debian 13.

Zabrimus · September 16, 2025 at 6:58 AM

Queste erfolgreich abgeschlossen...

Der automatische Build wurde erweitert und es ist seit langer Zeit endlich gelungen, einen vollständigen und fehlerfreien Build zu machen.

LE 13 wird auch mit gebaut mit zusätzlichen neuen Configs:
- LibreELEC-12-x86_64-Generic, LibreELEC-13-x86_64-Generic (VDR/Kodi ohne X11)
- LibreELEC-12-x86_64-GenericLegacy, LibreELEC-13-x86_64-GenericLegacy (VDR/Kodi mit X11)
- LibreELEC-13-aarch64-Rockchip-RK3588, LibreELEC-13-aarch64-Rockchip-RK3576, LibreELEC-13-aarch64-Rockchip-RK356x (RK3566, RK3568)
Diese sind brandneu und evt. gibt es noch keine offiziellen Nightly-Builds von LibreELEC

Sonstige Änderungen:
- vdr-plugin-systeminfo wurde wieder eingebaut
- vdr-plugin-xineliboutput kompiliert nicht mit LibreELEC-13-x86_64-GenericLegacy. Für xine-lib habe ich noch Patches gefunden, aber das Plugin macht Probleme. Ursache ist hier das Upgrade auf GCC 15.

Ein vollständiger Clean-Build aller Varianten dauert fast 3 Tage. Es sind einfach zuviele Varianten vorhanden. Beim Build habe ich konsequent "AUTOREMOVE=yes" gesetzt und nur dadurch hatte ich überhaupt genug Platz für alles.
Der Build auf Github ist noch ein Problem. Platz ist mittlerweile genug vorhanden, aber die Zeit ist das Problem, weil nach 6 Stunden der Build hart abgebrochen wird.

vdr_rossi · September 16, 2025 at 5:32 PM

Probiere später einen build mit LibreELEC-12-x86_64-Generic aus.

Müsste nicht der llvm Patch von ~/patches/LibreELEC.tv.libreelec-13/ auch nach ~/patches/LibreELEC.tv.libreelec-12/ kopiert werden?

Meine mich zu erinnern, dass mein LibreELEC-12 build auch daran scheitert.

Zabrimus · September 16, 2025 at 5:58 PM

Quote from vdr_rossi

Meine mich zu erinnern, dass mein LibreELEC-12 build auch daran scheitert.

Ich weiß es nicht. Ich habe in den letzten Wochen sehr viele Builds hinter mir und bin aktuell nur froh, daß endlich mal alles durchgeht und einen Fehler nach dem anderen beseitigen konnte. Eigentlich müsste ich einen komplett neuen Clean-Build von allem machen, aber da ist die Motivation gerade nicht hoch. Ich weiß noch, daß ich z.B. für die LE13 arm Configs zuallererst das Paket libtool:host bauen musste und dann den Rest, weil es sonst nicht klappte. Es kann also noch sein, daß noch weitere Build-Bomben existieren.

Im LibreELEC Forum wird auch der Tip gegeben, den Build bei Problemen einfach nochmal zu starten, weil sich dadurch der Build-Plan ändert und sich evt. Multithreading-Build-Probleme automatisch lösen. Das klappt aber leider nicht immer, gerade bei den :host Paketen ist der Erfolg sehr bescheiden.

Der LibreELEC-12-x86_64-Generic ist ohne X11.

Participate now!