Installation eines VDR+Plugins nativ auf CoreELEC Boxen

  • Ich kompiliere das auf dem VDR 1 aus meiner Signatur auf der 2TB-Platte. Platz ist genug. Die logs gehen bis 114.log und sind mit Ausnahme von 43.log allesamt leer mit 0 bytes.

    Laut top ist cc1plus noch mit 40% CPU-Auslastung aktiv. Vielleicht baut er ja doch noch.

    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

  • Ich hatte mal Probleme mit zu wenig Arbeitsspeicher. Swapt er?

  • wenn ich top richtig deute, ist genug RAM vorhanden:


    top - 00:26:03 up 43 min, 2 users, load average: 4,02, 4,31, 4,00

    Tasks: 230 gesamt, 5 laufend, 224 schlafend, 0 gestoppt, 1 Zombie

    %CPU(s): 94,6 be, 5,2 sy, 0,0 ni, 0,1 un, 0,1 wa, 0,0 hi, 0,0 si, 0,0 st

    MiB Spch : 3855,3 gesamt, 1739,5 frei, 1824,7 belegt, 291,0 Puff/Cache

    MiB Swap: 2048,0 gesamt, 1686,3 frei, 361,7 belegt. 1778,5 verfü Spch


    wäre interessant zu wissen, was unter buildprocess 114 kompiliert wird. Vielleicht macht er gerade den Kernel?

    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

  • Könnte sein. Vielleicht findest du in den Dateien in .threads/* Hinweise. Zumindest zu dem was auf dem Plan steht und was fertig ist. Oder du schaust direkt ins build Verzeichnus und beobachtest einfach den aktuellsten Ordner

  • Der build process hängt jetzt seit zwei Stunden bei

    Das ist allerdings seltsam. Kodi dauert tatsächlich sehr lange. Das der Build-Prozess dauerhaft hängt ist mir noch gar nicht passiert. Bisher brach es immer mit Build-Fehlern ab oder ging tatsächlich durch.


    Ich hatte bei dem automatischem Build schon die schlimmsten Befürchtungen mit den LibreELEC Builds. Das Upgrade von ffmpeg auf 5.1.2 hatte am Freitag noch zu Build-Abbrüchen geführt, aber @reel hat mit dem Fix von softhddevice-drm-gles die Probleme stark abgeschwächt.

  • Ich hatte kurz vor 18 Uhr begonnen. Nach Mitternacht war er immer noch nicht fertig. Da laut top aber der Compiler noch am Arbeiten war (mit einer Last von über 5!) , habe ich den Rechner über Nacht laufen lassen. Heute morgen war alles fertig. Meine Hardware (VDR1 aus Signatur) ist zugegebenermaßen schon 10 Jahre, aber eigentlich doch nicht so schwachbrüstig, oder doch?


    Es wird ja anscheinend auf der Konsole immer nur angezeigt, welches Paket zuletzt fertig gebaut wurde ("DONE"). Vielleicht kannst Du künftig auch anzeigen, welches Paket aktuell gebaut wird?

    Gibt es eine Möglichkeit, den build-Prozess auf ein oder mehrere bestimmte images zu beschränken? Im target-Ordner habe ich jetzt images auch für Boxen, die ich gar nicht habe. Mir hätten das generic und das für den N2 gereicht. Wahrscheinlich hätte das auch noch Zeit gespart.

    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

  • Es wird ja anscheinend auf der Konsole immer nur angezeigt, welches Paket zuletzt fertig gebaut wurde ("DONE"). Vielleicht kannst Du künftig auch anzeigen, welches Paket aktuell gebaut wird?

    Das macht CE/LE standarsmäßig so, stört mich aber auch. Das könnte man sicher patchen.


    Ich hatte kurz vor 18 Uhr begonnen. Nach

    Gibt es eine Möglichkeit, den build-Prozess auf ein oder mehrere bestimmte images zu beschränken? Im target-Ordner habe ich jetzt images auch für Boxen, die ich gar nicht habe. Mir hätten das generic und das für den N2 gereicht. Wahrscheinlich hätte das auch noch Zeit gespart.

    Mit der Variable UBOOT_SYSTEM kannst du das auf ein System beschränken. https://wiki.libreelec.tv/deve…/build-commands-le-11.0.x

  • Ich hatte kurz vor 18 Uhr begonnen. Nach Mitternacht war er immer noch nicht fertig. Da laut top aber der Compiler noch am Arbeiten war (mit einer Last von über 5!) , habe ich den Rechner über Nacht laufen lassen. Heute morgen war alles fertig.

    Meine Versuche mit dem Build auf Github selber sind spätestens nach 6 Stunden (Timeout) abgebrochen worden. Das sind nicht die schnellsten Build-Maschinen. Aber es kann durchaus sein, daß mehr als 6 Stunden benötigt werden. Das hängt extrem stark von der Maschine selbst ab. Zumindest beim ersten Lauf. Die folgenden sind erheblich schneller.

    Zum Beispiel braucht mein Build-Server (Ryzen 5, 6 Cores, 64 GB Ram) für ein vollständiges frisches Build aller Images (CoreELEC und LibreELEC) ca. 20 Stunden. Danach pendelt es sich bei ca. 2-3 Stunden ein, je nachdem wieviele und welche Pakete aktualisiert wurden.


    Es wird ja anscheinend auf der Konsole immer nur angezeigt, welches Paket zuletzt fertig gebaut wurde ("DONE").

    Auf der Console müsste aber auch angezeigt werden, welches Paket gerade gebaut werden soll. Das geht aber z.T. in den vielen Compilermeldungen unter.


    Das sieht z.B. so aus:

    Code
    UNPACK      alsa-ucm-conf
    BUILD      alsa-ucm-conf (target)
    [007/410] [DONE] install alsa-ucm-conf:target
        TOOLCHAIN      manual
    INSTALL      alsa-ucm-conf (target)
    >>> alsa-ucm-conf:target seq 9 >>>
    <<< _fonts:target seq 11 <<<


    Gibt es eine Möglichkeit, den build-Prozess auf ein oder mehrere bestimmte images zu beschränken? Im target-Ordner habe ich jetzt images auch für Boxen, die ich gar nicht habe. Mir hätten das generic und das für den N2 gereicht. Wahrscheinlich hätte das auch noch Zeit gespart.

    Eine gute Idee. Dazu muss erstmal herausgefunden werden, wie man die Targets einschränken kann. Ein wenig Forschung tut not :)

  • Eine gute Idee. Dazu muss erstmal herausgefunden werden, wie man die Targets einschränken kann. Ein wenig Forschung tut not :)

    Der Link von rell zu https://wiki.libreelec.tv/deve…/build-commands-le-11.0.x könnte weiterhelfen:


    Zitat

    To improve Jenkins/CI automation with ARM SoC $PROJECT(s) that support multiple $DEVICE types make image will iterate through all board/u-boot configurations defined in scripts/uboot_helper resulting in ~3-10 images in the target folder. To avoid this behaviour and build a single board-specific image UBOOT_SYSTEM=<board> can be appended to the build command, e.g. to build an Amlogic image for a LibreComputer LePotato board:


    Code
    PROJECT=Amlogic ARCH=arm DEVICE=AMLGX UBOOT_SYSTEM=lepotato make image

    Several ARM SoC devices have a UBOOT_SYSTEM=box configuration which excludes u-boot and provides all device-trees, allowing the image to boot using the Android/BSP u-boot on emmc/spi.

    Der von mir fett hervorgehobene Satz könnte darauf hindeuten, dass der Parameter ignoriert wird. Im uboot_helper Script sind auch mehr Boxen drin, als images erzeugt werden.

    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

  • Ich habe mir das angeschaut. Die LibreELEC Builds könnte man tatsächlich einschränken und auch den Build beschleunigen.

    Code
    uboot_helper: error: argument board: invalid choice: 'xxx' (choose from 'box', 'bananapi-m2s', 'bananapi-m2-pro', 'bananapi-m5', 'khadas-vim', 'khadas-vim2', 'khadas-vim3', 'khadas-vim3l', 'lafrite', 'lepotato', 'nanopi-k2', 'odroid-c2', 'odroid-c4', 'odroid-hc4', 'odroid-n2', 'radxa-zero', 'radxa-zero2', 'wetek-core2', 'wetek-hub', 'wetek-play2')
    *

    Für die CoreELEC Builds klappt das leider schon wieder nicht. Es gibt aber etwas ähnliches

    Code
    # CoreELEC Subdevices
    SUBDEVICES="Odroid_N2 Odroid_C4 Odroid_HC4 LePotato LaFrite Radxa_Zero Radxa_Zero2"

    Jetzt fehlt noch die Integration in das build.sh und die unterschiedlichen Namen

    Code
    Odroid_N2 vs. odroid-n2

    müssten geschickt aufgelöst werden.

  • Meister Zabrimus,


    was müsste ich denn tun, damit der Kernel mit einem zusätzlichen Modul gebaut wird?

    Ich könnte den pvrusb2-Treiber gebrauchen, der im Kernelzweig sonst unter /kernel/drivers/media/usb/pvrusb2 liegt. Ich muss für meinen Vater noch Dutzende VHS-Videos digitalisieren und könnte das mit einer PVRUSB2 und dem pvrinput-Plugin am N2 erledigen.

    Ob die Abhängigkeiten erfüllbar sind, weiss ich natürlich nicht. VIDEO_PVRUSB2_SYSFS muss mit rein, VIDEO_PVRUSB2_DVB sollte hingegen nicht mit einkompiliert werden: Das einzige Modell, das neben analog überhaupt auch einen DVB-Tuner hat, ist auf das alte DVB-T beschränkt, das in Deutschland nicht mehr ausgestrahlt wird.


    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

  • Das build.sh kennt nun den Parameter -subdevice mit dem zumindest ein Teil des Builds beschleunigt werden kann.


    Beispiele:

    Code
    ./build.sh -config CoreELEC-20 -subdevice Odroid_N2

    oder

    Code
    ./build.sh -config LibreELEC-master-arm-AMLGX -subdevice odroid-n2

    Ich hoffe, es funktioniert so, wie gewünscht. Lässt man -subdevice weg, dann ist der Build wie vorher auch.

  • Für Nr. 1 sollte es reichen, die kernelconfigs zu patchen. https://github.com/CoreELEC/Co…/devices/Amlogic-ne/linux

  • Eventuell ist das auch ein Thema für das addon dvb-latest?

    Das Plugin ist kein Problem, das kompiliere ich in chroot selbst.

    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

  • Dr. Seltsam: Interessehalber kurze Zwischenfrage... was ist eigentlich der Grund für die chroot Umgebung? Nur um zu kompilieren?

  • Dr. Seltsam: Interessehalber kurze Zwischenfrage... was ist eigentlich der Grund für die chroot Umgebung? Nur um zu kompilieren?

    ja, im wesentlichen ist es das. Ich habe ja viel mit dem softhdodroid-Plugin-Code experimentiert und auch ein paar Verbesserungen beigesteuert.

    VDR*ELEC hatte ich zwei mal mit verschiedenen images ausprobiert und beide male festgestellt, dass das Bild nach jedem Kanalwechsel für einen Moment in zu schneller Geschwindigkeit lief. Mit gleicher Pluginversion war das in chroot nicht aufgetreten. Wenn ich Zeit habe, schaue ich mir das nochmal an.

    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

  • Vielen lieben Dank!

    Kann ich dieses addon irgendwie einzeln updaten/neu kompilieren, ohne nochmal > 6 Stunden den ganzen build-Prozess zu durchlaufen?

    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

  • Dr. Seltsam: Interessehalber kurze Zwischenfrage... was ist eigentlich der Grund für die chroot Umgebung? Nur um zu kompilieren?

    ja das ist einfach nicht praktikabel: wenn du dich minimal damit beschäftigen und einfach nur TV schauen willst ist euer Image super, aber wenn du selbst entwickelst oder so wie ich immer nah an den Entwicklern bist ist das schon extrem hinderlich. - alleine heute das Problem mit softhdodroid mit jojo61 zu testen wird da schon zum Problem.


    Ansonsten bin ich sehr großer Fan von eurem Image und überlege es, wenn ich aus dem Urlaub zurückkomme, wieder unter das chroot zu machen. Ich hatte auch nicht auf dem Schirm das nur mit eurem Kernel da PIP unter softhdodroid funktioniert.


    Was mir da noch fehlen würde wäre ein funktionierendes irmplircd für den STM32 Empfänger von Emma53 , in dem Zusammenhang auch die Datei "de.yavdr.lircd2uinput.conf" unter /etc/dbus-1/system.d. (gibts im lircd2uinput yavdr Paket).


    Das von Dr. Seltsam angesprochene Problem mit der Geschwindigkeit beim Kanalwechsel kann ich übrigens so bestätigen, das liegt aber irgendwo beim vdropt selber: wenn ich auf eurem Image den vdr in meinem ubuntu chroot starte tritt das nicht auf.

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!