Installation eines VDR+Plugins nativ auf CoreELEC Boxen

  • Ich muss gerade an die Inflation von Logging-Frameworks und Programmiersprachen denken und komme dabei automatisch auf einen Comic von xkcd.


    Meine Ziele:

    - VDR/Plugins nativ auf CoreELEC Boxen

    - Einfache Installation (ohne ein neues Image oder alternativ ein neues CoreELEC Image mit VDR/Plugins)

    - Einfacher Wechsel von VDR <-> Kodi


    Bis auf den letzten Punkt ist die Sache mittlerweile ziemlich rund. Ich habe es bei mir aktuell so eingestellt, daß automatisch nach einem Reboot erst VDR gestartet wird. Aber so ganz zufrieden bin ich noch nicht.


    Das Repository befindet sich auf Github:

    https://github.com/Zabrimus/CoreELEC

    Die Hauptarbeit findet im Branch 19.4-Matrix-VDR statt.


    Releases werden automatisch gebaut und die aktuelle Version ist 0.1.4 (ca. 46 MByte gepackt).

    Es gibt keine Packages, sondern nur ein tar Archive (all in one) mit VDR und allen bisher vorhandenen Plugins und den notwendigen Libs.

    Eigentlich sollten keine Bestandsdaten in /storage überschrieben werden. Neue Verzeichnisse werden angelegt:

    - /storage/.config/vdropt

    - /storage/.config/vdropt-samples

    - /storage/.fonts

    - /storage/.opt/vdr


    Installation ist simpel:

    cd / && tar -xf /storage/coreelec-19-vdr.tar.gz

    wenn das Archiv nach /storage kopiert wurde)

    Sinnvoll ist dann noch das entpacken der Konfigurationsdaten:

    cd /opt/vdr/bin && ./install.sh -i

    In /storage/.config/vdropt befinden sich dann die Default Konfigurationen von VDR und den Plugins.


    Für ein Update führe ich nach dem entpacken von coreelec-19-vdr.tar.gz, statt install.sh -i

    ein install.sh -C aus. Damit werden die Bestandkonfigurationen mit den neuen "gemischt". Das ist natürlich nur sinnvoll, wenn es neue Konfigurationen/Plugins gibt.


    Es kann natürlich noch sein, daß etwas nicht richtig funktioniert. Auch weil ich einfach nicht weiß, wie ich alle Plugins testen soll.

    Aber dafür (und für neue Pluginwünsche) gibt es dann die Issues auf Github.


    Weitere Informationen (auch zur Deinstallation, falls man sich dafür entscheiden sollte) findet sich auf Github.

  • Meine Ziele:

    - VDR/Plugins nativ auf CoreELEC Boxen

    - Einfache Installation (ohne ein neues Image oder alternativ ein neues CoreELEC Image mit VDR/Plugins)

    - Einfacher Wechsel von VDR <-> Kodi

    Das klingt super, so hatte ich mir es gewünscht. :thumbup::thumbup::thumbup:

    Das werde ich auf jeden Fall testen, wenn ich wieder zu Hause bin.


    Es klingt zumindestens so, als wenn unsereiner das auch ohne tiefere Linuxkentnisse hinbekommen könnte.

    Wenn dann noch die Umschaltung VDR <--> KODI problemlos laufen sollte, dann wäre das die Lösung!

  • In der neuen Version 0.1.5 habe ist alles drin, was ich haben wollte:

    - Switch Vdr -> Kodi (über die commands.conf)

    - Switch Kodi -> Vdr (über das Powermenu, Eintrag VDR)

    - Einfache Auswahl VDR oder Kodi beim booten

    - Update softhdodroid


    In einer frischen Umgebung sollten alle Scripte/Änderungen automatisch installierbar sein. Ansonsten findet sich auf Github oder als Ausgabe des install.sh ein Hinweis, was wo noch manuell gemacht werden sollte.

    Den Wechsel Kodi->Vdr bzw. die Änderung des Power-Menus gibt es nur für den Default-Skin. Aber die Änderung im xml ist so einfach, daß andere Skins auch schnell angepasst werden können - hoffe ich.


    Jetzt noch Fehler finden und beseitigen, die evt. noch vorhanden sind. Hinweise sind willkommen.


    Zabrimus

  • Zabrimus

    ab kommende Woche bin ich wieder zu Hause und da werde ich mir gleich eine SDcard besorgen und Dein System auf meinem Odroid N2 testen.


    Eine Frage hätte ich im Vorfreld noch:

    Welche CoreElec-Version soll ich verwenden: 19.4-Matrix (stable) oder geht auch die Nightly-Version (die verwende ich eigentlich sonst immer)?


    Apropo, wo wir gerade bei den ersten Fragen sind, und es werden bestimmt noch viele weitere Fragen folgen!

    Sollten wir für Deine Version von VDR unter Verwendung von CoreElec nicht einen separaten Thread aufmachen? :/

  • Eine Frage hätte ich im Vorfreld noch:

    Welche CoreElec-Version soll ich verwenden: 19.4-Matrix (stable) oder geht auch die Nightly-Version (die verwende ich eigentlich sonst immer)?

    Compiliert habe ich mit der stable Version. Ich weiß aber nicht, ob der 20er oder andere 19er funktionieren. Das habe ich noch nicht ausprobiert. Aber solange die Libs in Kodi keine inkompatiblen Änderungen haben oder sogar rausgeflogen sind, könnte es klappen.

    Der Build läuft in 3 Phasen:

    1. Es wird das CoreELEC Image gebaut ohne VDR

    2. Neuer Build mit dem VDR

    3. Es werden alle Libs eingesammelt, die in 1. nicht vorhanden und in 2. neu erzeugt wurden. Ich habe mich bei den Abhängigkeiten/Libs überall in CoreELEC bedient, ungeachtet wo die Pakete liegen (addons, chrome, sonstige depends, ...)


    Anfangs hatte ich den 19er Branch und auch immer wieder die Änderungen von CoreELEC gefetcht. Das ging nicht gut, weil ich mit dem kompilieren nicht hinterher kam. Das dauerte alles viel zu lange.

    Apropo, wo wir gerade bei den ersten Fragen sind, und es werden bestimmt noch viele weitere Fragen folgen!

    Sollten wir für Deine Version von VDR unter Verwendung von CoreElec nicht einen separaten Thread aufmachen?

    Ich denke schon, da die Anfänge im Thread andere Schwerpunkte hatten. Nur fällt mir leider kein Titel ein, der nicht nach Plagiat aussieht oder eine Verwechslungsgefahr darstellt. Wenn du ne gute Idee hast, einfach aufmachen und ich schwenke mit.

  • Zabrimus

    na ja, als Threadtitel würde ich im Prinzip einfach den 1. Punkt aus Deinem Beitrag #93 etwas modifizieren:


    Installation eines VDR+Plugins nativ auf CoreELEC Boxen


    Und da können wir dann zu Anfang die letzten Beiträge aus diesem Thread reinkopieren bzw. da könnte uns einer der Forum-Admins behilflich sein. ;)

  • Hallo,


    dies ist der neue Thread, als Abspaltung von VDR auf 40€ TV-Box - Tanix TX3 und ähnlichen Amlogic basierten Boxen. Ich muss nur noch einen Foren Admin finden, der aus dem anderen Thread die Beiträge ab #93 hierhin schiebt.


    Aber zum Thema. Der Build-Prozess bedarf weiterer Erläuterungen, da der Build abbricht, wenn bestimmte Pakete nicht installiert sind. Obwohl eigentlich vorher ein Check stattfindet, der leider aber nicht vollständig ist. Es ist z.T. schwierig herauszufinden, was genau fehlt. Das build-local.sh wurde auch so geändert, daß es schnell abbricht, falls was schief geht.


    Getestet habe ich den Build in einem frischen Ubuntu Focal Container (lxc). Debian 11 sollte genauso funktionieren. Andere Systeme oder Versionen sind nicht getestet worden.


    Installation der notwendigen Pakete:

    Code
    1. apt-get install build-essential coreutils squashfuse git curl xfonts-utils xsltproc default-jre \
    2. libxml-parser-perl libjson-perl libncurses5-dev bc gawk wget zip zstd libparse-yapp-perl \
    3. gperf lzop unzip patchutils cpio

    Als normaler User (nicht root!) kann man dann build so durchführen:

    Code
    1. git clone https://github.com/Zabrimus/CoreELEC.git
    2. cd CoreELEC
    3. git checkout 19.4-Matrix-VDR
    4. ./build-local.sh

    Im Verzeichnis build-artifacts sollte dann das vdr Tar zu finden sein.


    Zur neuen Entwicklung/Integration eines neuen Plugins empfiehlt sich tatsächlich erst ein Build im Container, da schon einiges kopiert/gelöscht wird und falls man dabei einen Fehler macht, ist man erstmal froh nicht root zu sein.


    Zabrimus

  • Einige Beträge auf Wunsch von Zabrimus hierher verschoben ...

    HowTo: APT pinning

  • Nur eine kurze Bemerkung. Ich musste ein neues Release machen, weil im alten das autostart script irgendwie verschütt gegangen ist.

    Ohne das Script klappt weder die Auswahl von Kodi/VDR beim boot noch der Wechsel zur Laufzeit.

    Das Build wurde gestartet. Dauert ca. eine Stunde.

  • Ich kriege während des build-Prozesses auf einem Ubuntu 21.10. diesen Error:


    Es liegt an glibc 2.34 und dazu gibt es einen Patch

    Ich füge die beiden gepatchten Dateien mal bei. Vielleicht magst Du das ja in Dein git aufnehmen.

    Files

    • c-stack.zip

      (4.81 kB, downloaded 47 times, last: )

    ACT-620, Asrock B75 Pro3-M, 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.

  • Es liegt an glibc 2.34 und dazu gibt es einen Patch

    Ich füge die beiden gepatchten Dateien mal bei. Vielleicht magst Du das ja in Dein git aufnehmen.

    Patches werden beim Build automatisch angewandt. Ganze Dateien müsste ich erst manuell kopieren.

    Ich habe daher den Patch in CoreELEC/packages/devel/m4/patches committed.


    Danke.

  • zwei weitere compile-Fehler konnte ich mit diesen Patches beheben::

    https://gitlab.gnome.org/GNOME…3d34bc1b981ca03d4be299576

    https://gitweb.gentoo.org/repo…f8be65960861ac489fefbcaf4


    Bei diesem Fehler in "BUILD nfs-utils (host)" hänge ich fest:


    welches abhängige Paket fehlt mir?

    Sollte ich --enable-tirpc ausprobieren und wenn ja, wo in der build.sh wäre das zu ergänzen?

    ACT-620, Asrock B75 Pro3-M, 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.

  • FAILURE: scripts/build nfs-utils:host has failed!


    Sollte ich --enable-tirpc ausprobieren und wenn ja, wo in der build.sh wäre das zu ergänzen?


    In diesem Fall hilft ein grep in packages nach PKG_NAME="nfs-utils". Das Ergebnis ist CoreELEC/packages/network/nfs-utils/package.mk.

    Und da findet man auch die configure option

    Code
    1. --disable-tirpc

    Und jetzt kommt das ganz große Aber! Und damit auch Aufwand, Risiko und Frust.


    Man kann es in der packages.mk ändern, es würde auch gebaut werden. In dem erzeugten VDR-tar würde die Änderung aber nicht mehr vorhanden sein, weil die Dateien sowohl im VDR-losen Image, als auch im VDR-Image auftauchen und somit nicht als Neu identifiziert würden. Und es werden einige executables erzeugt, die auch nicht mehr vorhanden wären.


    Und das geht mit den Patches für glib und cxxtools weiter. Die zusätzliche Frage wäre dann, ob man Abhängigkeiten beider Pakete auch nach vdr-depends mitnehmen müsste und auch die Pakete, die von beiden abhängig sind.


    Solche Änderungen ziehen einen Rattenschwanz nach sich, der nicht mehr beherrschbar ist. Bis ich auf die Idee kam, 2 Builds zu machen und die neuen Libraries einzusammeln, hatte ich es versucht und war eigentlich nur noch damit beschäftigt, alles irgendwie kompilierbar zu bekommen und bin am Ende damit gescheitert.


    Ganz anders sieht das aus, wenn man statt dem VDR-only tar tatsächlich ein ganzes Image baut. Dann wären diese Änderungen leichter machbar, einfach weil alle Libs und Executables Teil des Images wären und damit alles rund und stimmig.


    Ich arbeite gerade daran, die Fehler zu beseitigen, die noch auftauchen, wenn man Images statt dem VDR-tar bauen will. Dann kann man überlegen, die Patches zu integrieren. Wobei ich noch überlegen müsste, wie der Branch gestaltet werden kann, so daß beides (tar und Image) funktioniert. Aber dafür würde sich eine Lösung finden lassen z.B. mit einem zusätzlichen patches-Verzeichnis nur für die Images.

    Das Nächste wäre dann der Image-Bau für die echten CoreELEC Branches 19 und 20 und nicht nur das stable Release.


    Eine schmutzige Lösung wäre es aktuell, die Patches lokal in den patches Order der jeweiligen Pakete zu kopieren und zu bauen.

    Dann müsste man aber beides installieren: Das neue Image aus dem target Verzeichnis (z.B.

    CoreELEC-Amlogic-ng.arm-19.4-Matrix_devel_20220422145611.tar, wobei das jüngere tar genommen werden müsste, kopieren nach /storage/.update + reboot) + das VDR-tar installieren. Wenn man das Risiko eingehen will, kann man es versuchen.


    Oder, falls genug Geduld vorhanden ist, wartet man auf die noch kommen Fixes für den Image-Bau.

  • Es gibt 2 neue Branches:

    coreelec-19-VDR

    coreelec-20-VDR


    Und neue Optionen für build-local.sh:

    Code
    1. $ ./build-local.sh
    2. Usage: [-t] [-i] [-9] [-0]
    3. -t : Build tar (Matrix). Version containing only VDR and is installable in an existing Kodi installation
    4. -i : Build images (Matrix). Images will be created which can be written to an SD card. Contains VDR in /usr/local
    5. -9 : Build images (corelec-19). Images will be created which can be written to an SD card. Contains VDR in /usr/local
    6. -0 : Build images (corelec-20). Images will be created which can be written to an SD card. Contains VDR in /usr/local

    Damit können 4 verschiedene Builds gemacht werden:

    - Der normale Matrix Build aus dem nur das tar mit VDR erstellt wird. [-t]

    - Der Matrix Image Build. VDR wird nach /usr/local installiert und es entstehen die normalen CoreELEC Images.

    - Der 19er Build (mehr oder weniger nightly oder weekly) aus dem CoreELEC Images mit VDR erstellt werden.
    - Der 20er Build (mehr oder weniger nightly oder weekly) aus dem CoreELEC Images mit VDR erstellt werden.-


    Die Branches coreelec-19-VDR und coreelec-20-VDR werde ich bei Gelegenheit von CoreELEC pullen. Sie sind also nicht unbedingt tagesaktuell.


    Die Builds sollten alle durchlaufen. Getestet sind sie allerdings nur schwach.


    Irgendwo wurde mal angesprochen, daß man für Pip einen Kernelpatch/Parameter/Konstante ändern müsste. Jetzt da Images erzeugt werden können, wäre es vielleicht eine Möglichkeit den Kernel entsprechend auszutauschen.

    Aber das ist nur eine Idee, weil ich noch gar nicht weiß, wo, wie, welcher Kernel in den Build überhaupt eingebunden wird. Und wie man den ersetzen könnte.


    Zabrimus

  • Du musst den Kernel nicht ersetzen. Du musst nur einen Patch weglassen, das ist alles. Ich finde nur grad nicht welchen du weglassen musst.


    Edit:

    Es ist der 003-multi-decoders-limit-maximum-number-of-decoder.patch

  • So einfach? Ich habe den Patch mal rausgeschmissen.


    Aber es gibt noch ein Problem mit den Images. Kodi startet weder mit, noch ohne Patch.

    VDR läuft gut, aber Kodi will nicht. Und das Log liefert keine echten Hinweise.

    CApplication::CreateGUI - unable to init windowing system


    Jetzt muss ich überlegen, wie ich an die Ursache komme und eine Lösung finde.

  • Die neue Version 0.1.7 wird frisch gebaut. Im Wesentlichen sind neue Plugins hinzugekommen. Z.T. ermöglicht durch den Umstieg von ImageMagick auf GraphicsMagick. Keine Ahnung, was im Cross-Compiler deaktiviert wurde, aber ImageMagick (bzw. Magick++) will einfach nicht bauen. Probiert habe ich es auch mit dem coreelec-20 Branch.


    New plugins:

    vdr-plugin-fritzbox

    vdr-plugin-radio

    vdr-plugin-systeminfo

    vdr-plugin-weatherforecast

    vdr-plugin-tvguideng

    vdr-plugin-skinelchihd


    Plugin update:

    softhdodroid


    Changes:

    replaced ImageMagick by GraphicMagick due to compile problems


    Bugfixes:

    several, mostly for image based build


    So langsam sollte das Feature-Complete sein. Sofern mir nicht spontan noch etwas einfällt oder jemand Wünsche äußert.


    Zabrimus


    ps: Persönlich bin ich auf die 19er Images umgestiegen. Das Update ist vom Entwicklungsrechner viel gemütlicher :saint: