Posts by Zabrimus

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Quote from Dr. Seltsam

    ssh-Verbindung wird erfolgreich aufgebaut - CoreELEC meldet sich mit den Daten der Box - und die Verbindung wird sofort ohne Angabe eines Fehlergrundes wieder geschlossen.

    Ich kann mich ganz dunkel erinnern mal etwas über ssh Probleme gelesen zu haben. Allerdings weiß ich nicht mehr in welchen Zusammenhang. Soweit ich mich erinnere, konnte per samba ein update tar eingespielt werden. Aber wie gesagt: Dunkelste Erinnerungen und ich finde den Beitrag nicht mehr.


    Wenn sshd läuft, reagiert und dann die Verbindung (nach dem Login?) gekappt wird.... Da fällt mir nichts zu ein.


    Ich musste erstmal schauen. Der RTL8821CU ist ein WLAN chip. Nutzt du wlan oder lan?

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Quote from Dr. Seltsam

    Zabrimus: Vielleicht kannst Du einstweilen den Patch von rell übernehmen?

    Ich habe es versucht. Allerdings schlagen die Patches fehl (rejected) und ich das erstmal wieder reverted. Ich hoffe, ich komme heuten Abend dazu.


    Quote from rell

    Das Problem ist, dass es bei den CoreELEC Builds wohl auch ein Cache gibt, aus dem die Quellen gezogen werden, und es erst dann auffällt, wenn es jemand meldet.

    Z.B. in CoreELEC/sources befinden sich alle bisher heruntergeladenen Pakete. Und falls die gewünschte Version bereits vorhanden ist, dann wird diese eben genommen.

    Link-Fehler findet man immer erst dann, wenn es jemand meldet oder man das sources komplett löscht (was ich eher gaaaanz selten mache).

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Quote from Dr. Seltsam

    CMake Error at /srv/martin/VDRSternELEC-CE20/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find Alsa (missing: ALSA_LIBRARY ALSA_INCLUDE_DIR) (found version "1.2.8")

    Alsa wird nicht gefunden. Hmm....

    Quote from Dr. Seltsam

    /srv/martin/VDRSternELEC-CE20/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/bin/clang-format: error while loading shared libraries: libclang-cpp.so.15: cannot open shared object file: No such file or directory -- Found ClangFormat: /srv/martin/VDRSternELEC-CE20/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/bin/clang-format (found version "")

    Da scheint auch etwas nicht zu stimmen.

    Quote from Dr. Seltsam

    /build.sh -config CoreELEC-20 -addon dvb-latest,system-tools

    Das läuft bei mir durch. Das letzte Kodi Update war vor 2 Tagen. Damit müssten wir beide dieselbe Version haben.


    Wenn etwas an der toolchain nicht stimmt, dann wird das schwierig. Die offizielle Empfehlung ist, alles löschen und neu bauen. Manchmal kann man auch Teile der toolchain neu erstellen lassen, in dem evt. betroffene Pakete gelöscht werden.


    Du kannst ja mal versuchen verschiedene Pakete zu löschen und dann neu bauen zu lassen.

    Dazu im CoreELEC Verzeichnis folgendes ausführen

    Code
    PROJECT=Amlogic-ce DEVICE=Amlogic-ng ARCH=arm ./scripts/clean llvm
PROJECT=Amlogic-ce DEVICE=Amlogic-ng ARCH=arm ./scripts/clean alsa
PROJECT=Amlogic-ce DEVICE=Amlogic-ng ARCH=arm ./scripts/clean kodi

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Quote from Dr. Seltsam

    Ich kann für mein Digitalisierungsvorhaben auch erstmal eine SD-Card mit CE 19 verwenden.

    Ich habe gerade einen Patch für CE20 eingecheckt, bei der auch das pvrusb2 Kernelmodul endlich gebaut wird und auch das Log-Spamming verhindert wird - so hoffe ich.


    Quote from Dr. Seltsam

    Auch wenn nur 74 Pakete gebaut werden muss, um ein einzelnes addon kompilieren zu können, ist das sehr zeitaufwändig. Die ganzen Pakete hatte ich ja gestern schon gebaut, war natürlich alles weg, nachdem ich Dein git neu ausgecheckt hatte.

    Hast du die letzte gebaute Version gelöscht und komplett neu ausgecheckt?

    Quote from Dr. Seltsam

    Hätte es gereicht, in dem Ordner mit der schon einmal durchlaufenen Installation ein git pull zu machen?

    Genau das. Der neue Build ist dann um (falsche physikalische Einheit) Lichtjahre schneller.

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Quote from Dr. Seltsam

    Ich habe das addon jetzt für CoreELEC-20 gebaut

    Oje. Bei CE20 bin ich noch nicht dahinter gekommen, wie ich den Treiber aktivieren kann. Bisher sind meine Versuche alle gescheitert. Das mag daran liegen, daß ich wohl nicht verstanden habe, wie die Makefiles und .configs beim Bauen erstellt werden und wie ich das von außen beeinflussen kann. Ich muss für CE20 erstmal herausfinden, wie ich den Build des Treibers triggern kann.


    -addon für die Liste der der Addons

    -addononly nur Addons bauen

    Quote from Dr. Seltsam

    Jetzt will er 74 Pakete bauen und ist aktuell bei toolchain.

    Die toolchain (compiler, make und co.) wird benötigt, damit überhaupt etwas gebaut werden kann. 74 Pakete sind kein vollständiges Build.

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Quote from CKone

    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).

    Ich bin mir da jetzt nicht sicher. Ist das eine Anfordung?

    Quote from CKone

    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.

    Das ist seltsam. Gibt es irgendwelche Patches, die in der chroot Version existieren, aber im Image fehlen? Am Ausgabedevice kann es doch nicht liegen, oder? Ich meine, es sollte so gar keinen Unterschied geben.

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Quote from Dr. Seltsam

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

    Das hatte ich irgendwo schon einmal beschrieben.

    im build.sh die Zeile am Ende build löschen und dann nur das Addon bauen lassen

    Code
    ./build.sh -config CoreELEC-19 -addon dvb-latest

    Im Ordner CoreELEC/target/ oder einem Unterordner davon befindet sich das installierbare Addon im zip Archiv.

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    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.

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    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.

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Quote from Dr. Seltsam

    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.


    Quote from Dr. Seltsam

    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 <<<


    Quote from Dr. Seltsam

    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 :)

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Quote from Dr. Seltsam

    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.

  • Video Treiber für Odroid-N2+ (softhdodroid)

    Quote from Dr. Seltsam

    und erhielt die wenig vertrauenserweckende Fehlermeldung

    Die Meldung kann bei einem frischen Checkout immer noch kommen, aber die Fehlermeldung sollte im Build-Script und für den Build keine Auswirkungen haben.

    Zugegeben: Das eigentliche Problem hätte man eleganter lösen können.


    Baut es denn nicht?


    Edit:

    Die Fehlermeldung sollte jetzt auch bei einem frischen Checkout nicht mehr kommen. Es ist eleganter gelöst worden.

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Quote from LotharE

    cp: cannot overwrite non-directory '/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/lirc/media' with directory '/home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/.sysroot/lirc.target/usr/include/lirc/media'

    Ach mist. Das Problem hab es schon irgendwann einmal.

    .../usr/include/lirc/media ist in der einen Version ein Link und in einer anderen ein echtes Verzeichnis und das beisst sich dann.


    Lösche mal den entsprechenden Link


    Code
    rm /home/lothar/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/lirc/media

    Dann sollte es wieder bauen.