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

Quote from astra

hier war es ebenfalls notwendig die neue Ordnerstruktur aus dem aktuellen Plugin/config an die entsprechende Stelle nach .config/vdropt/plugins... zu kopieren.

Also brauche ich eine generelle Lösung für das Problem. Aber wie unterscheiden zwischen Konfigurationen, die durch den Benutzer geändert werden können und denen, die fix sind? Und wie bestimmen, welche Dateien in welchem Plugin aktualisiert werden müssen?

Die ganzen Pluginkonfigurationen können nicht nach /usr/local gelegt werden, da diese dann read-only sind es auch keine Möglichkeit gibt, da irgendwas zu machen. Vielleicht könnte mit overlayfs da etwas versuchen, aber dann besteht das Problem mit den Bestandsinstallationen und einem evt. Migrationsscript.

Ich muss da mein Testsystem wieder rausholen und Experimente durchführen...

Quote from rell

Würde es nicht einfach reichen, bei jedem Update vdropt-sample zu aktualisieren, wie es ./install.sh -i macht und dann im Prinzip ein ./install.sh -C zu machen?

Das funktioniert leider nicht, da install.sh -C die bestehenden Konfigurationen eben nicht überschreibt, sondern im Prinzip nur neue Dateien (z.B. neue Plugins) rüberkopiert. Die Grundidee war genau, den evt. schon geänderten Bestand nicht zu überschreiben, damit durch das Update eigene Änderungen nicht verloren gehen.

Vielleicht wäre eine Whitelist mit Dateien/Verzeichnissen sinnvoll, die auf jeden Fall kopiert werden? Mit einem entsprechendes Update-Script, daß immer aufgerufen wird.

Schwierig ist es, alle Updates im Auge zu behalten und zu entscheiden, ob irgendwas kopiert werden muss. Das ist mir z.B. bei live und eben epg2vdr/scraper2vdr komplett durch die Lappen gegangen.

Edit:

Aber vielleicht ist genau diese Stelle (install.sh -C) gut geeignet, bestimmte Dateien/Verzeichnisse auf jeden Fall zu kopieren. Dann müsste man nur noch irgendwo erwähnen, daß das Script nach einem Update aufgerufen werden sollte, oder es gibt irgendwie/irgendwo ein Flag, daß den Aufruf einmal nach einem Update erledigt.

um auf die epg.dat zurück zu kommen, die gehört zur Auslieferung damit auch zwingend in das Paket der Distribution, immer passend zur Version des Plugins. Siehe als Beispiel yavdr

hi,

irgendwas geht mit dem heutigen git stand und epg2vdr schief:

loading plugin: /usr/local//lib/vdr/libvdr-epg2vdr.so.2.6.3

vdr: /usr/local//lib/vdr/libvdr-epg2vdr.so.2.6.3: cannot open shared object file: No such file or directory

tatsächlich finde ich die lib auch nicht in dem Verzeichnis..

Das sollte doch eigentlich beim erstellen des .tar schon richtig reingelegt werden?

Danke im Voraus für deine unermüdliche Unterstützung!

blöde Frage, welches tar?
Wenn du es selbst compilierst das git clonen dann make und make install, dann ist die Lib an Ort und Stelle (vorausgesetzt die vdr.pc passt).

Quote from reini-at

irgendwas geht mit dem heutigen git stand und epg2vdr schief:

loading plugin: /usr/local//lib/vdr/libvdr-epg2vdr.so.2.6.3

vdr: /usr/local//lib/vdr/libvdr-epg2vdr.so.2.6.3: cannot open shared object file: No such file or directory

Ich musste das Makefile Patch für die neue Version von epg2vdr neu erstellen. Dabei ist mir eine Änderung durchgegangen und das Installatationverzeichnis für die shared Library war Unsinn.

Das ist/sollte im Git wieder gefixed sein.

Danke für die Meldung.

ah okay es geht nicht um git@github.com:horchi/vdr-plugin-epg2vdr.git

Quote from horchi

blöde Frage, welches tar?
Wenn du es selbst compilierst das git clonen dann make und make install, dann ist die Lib an Ort und Stelle (vorausgesetzt die vdr.pc passt).

Er meint das Update-Tar, das erstellt wird, wenn man mein Repo (VDRSternELEC, CoreELEC + VDR) neu kompiliert. Dieses wird verwendet, um die bestehende Installation zu aktualisieren. In dem tar befindet sich die vollständige Installation (System + Kodi + VDR + Plugins + Anpassungen).

Sorry für die Verwirrung und danke für den rixen fix! Werde ich am Nachmittag testen!

Ich denke, das ist eine gute Gelegenheit mal die typischen Probleme aufzulisten, die ich bisher mit den Makefiles hatte. Dies ist keine Liste von Fehlern, sondern resultiert einfach daraus, daß im VDR*ELEC ein cross-compile gemacht wird und der Cross Compiler und die Tools in CoreELEC sich z.T. leicht anders verhalten, als auf dem Host.

CE verwendet z.B. ein gepatches install und pkg-config. Damit sind die Pfade/Parameter anders, als man vielleicht erwarten würde. Das Buildverzeichnis ist natürlich beim cross-compile ein anderes, die Header und Libraries kommen auch woanders her.

CC = g++

Verwendet den Host Compiler und nicht den Cross Compiler.

Anweisungen wie

 $(shell python3-config --includes)

rufen das python3-config auf dem Host auf. Damit werden die Header vom Host verwendet und der Build schlägt fehl mit der interessanten Fehlermeldung: Cross compile badness... Header vom Host werden geladen.

Austauschen in den Makefiles der Plugins muss ich immer

-LIBDIR   = $(call PKGCFG,libdir)
+LIBDIR   ?= $(call PKGCFG,libdir)

Da kommt das pkg-config von CoreELEC zum tragen und das liefert Pfade, die (für mich) nicht brauchbar sind. Im Build wird das LIBDIR explizit an das make übergeben.

Die Installation muss im makefile auch immer geändert werden

-   install -D -m644 $^ $(DESTDIR)$(LIBDIR)/$^.$(APIVERSION)
+  install -D -m644 $^ $(LIBDIR)/$^.$(APIVERSION)

Und wieder macht das install von CoreELEC etwas spannendes. Da liegt übrigens das Problem, was gerade erst gemeldet wurde. Das DESTDIR wird von install geändert auf etwas unbrauchbares wie /home/user/..../VDRSternELEC/... Und dieses Installationsverzeichnis funktioniert seltsamerweise nicht richtig. An anderen Stellen im Makefile an denen DESTDIR verwendet wird, funktioniert es übrigens einwandfrei.

Ich denke, das müssten so die typischen Probleme sein: Vom Host der compiler, die Header, die Libs. Und die Versionen von pkg-config und install.

Verschiedene (wenige) Pakete haben Spezialprobleme, wie der Versuch, die erzeugten arm Binaries auf dem Host aufzurufen zu wollen. Hier besteht die Lösung dann darin, die Hilfstools speziell für den Host zu kompilieren und zu verwenden.

Quote from rell

Ich könnts mir beizeiten mal anschauen, wenn du willst... Am Ende würde es vieles entschlacken und einfacher machen.

Klar. Wenn du eine Lösung dafür findest würde es die packages erheblich einfacher gestalten.

Ich hatte mich schon gefragt, warum ich z.B. das DESTDIR bei der Installation der shared library rausgenommen hatte und ob das überhaupt sinnvoll war und ist.

Die Frage stand allerdings nur bis heute morgen im Raum, bis ich den Fehlerbericht gelesen hatte

danke! läuft jetzt wieder

Hi, wie ist die Installation auf x86-Systemen gedacht? Das Image auf einen USB-Stick brennen und von diesem betreiben? Oder geht es auch klassisch von einer Festplatte oder einem System mit Betriebssystem-Platte und Medienplatte z. B.?

LibreELEC läuft auf x86.

Ok, danke. Ich werde mich dann mal tiefer in LibreELEC einlesen. Jahre zuvor hatte ich es kurz mal auf einem Wetek installiert, aber das System wurde dann einfach so benutzt, so daß ich es unter der Haube nie kennen gelernt habe.

So, ich habe es jetzt auf einem x86-64 System getestet. Der LibreELEC-Teil funktionierte soweit getestet einwandfrei inkl. Installation von anderem Skin z. B.. Was jedoch nicht funktionierte war jegliche Installation von VDR-relevanten Paketen. Die Meldung jeweils ein simples "Installation fehlgeschlagen". Auffällig dabei, daß in den Listen hinter den VDR-relevanten Paketen schon keine Paketgrößen angezeigt werden im Gegensatz zu den LibreELEC-eigenen Paketen. War/ist jetzt einfach die VDR*ELEC-Paketquelle offline oder woran könnte es liegen?