Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Es sieht so aus, als wenn anstelle des Codes der Wert für die Code Maske genommen wird.

    setup_bl301.service ist Dein eigenes Script. Das soll doch eigentlich nur eine 1 in /sys/class/bl301_manager/setup_bl301 schreiben:

    Das Schreiben der Codes macht m.E. Kodi über update-bl301.service und inject_bl301.

    VDR1: Odroid N2+ mit CoreELEC und Ubuntu in chroot, 2x WinTV DualHD, Sandisk 2TB SSD

    VDR2: Tanix TX3 mit VDR*ELEC, WinTV DualHD, 500GB SSD

    Quote from Dr. Seltsam

    Das Schreiben der Codes macht m.E. Kodi über update-bl301.service und inject_bl301

    Wenn ich das richtig sehe, dann machen update-bl301 und inject-bl301 nur das Update/die Installation des bl301 im Bootloader.

    Code
    tanix1:~ # /usr/lib/coreelec/update-bl301 -v
CoreELEC BL301 installed but no update needed

    Ich habe mir eine /storage/.config/tanix1.remotewakeup angelegt und die kann ich in Kodi dann auch auswählen. Das hat allerdings auch keinen Einfluss. Ich verstehe nicht, wie der bl301_manager an die Werte kommt. Ein Mysterium...

    Schau mal in bl301_manager.c

    Es greifen offenbar die Initialwerte

    Code
    static u32 remotewakeup = 0xffffffff;
static u32 remotewakeupmask = 0xffffffff;

    und nicht der setup-Wert aus der config.ini, wie die Zeile

    MODULE_DESCRIPTION("Handle data between config.ini and bootloader blob bl301");

    beschreibt. Ich vermute, dass sich "irgendwas" verändert hat, dass dazu führt, dass die vorgenommenen Patches jetzt eine unerwünschte Nebenwirkung haben.

    VDR1: Odroid N2+ mit CoreELEC und Ubuntu in chroot, 2x WinTV DualHD, Sandisk 2TB SSD

    VDR2: Tanix TX3 mit VDR*ELEC, WinTV DualHD, 500GB SSD

    Quote from Dr. Seltsam

    Ich vermute, dass sich "irgendwas" verändert hat, dass dazu führt, dass die vorgenommenen Patches jetzt eine unerwünschte Nebenwirkung haben.

    Ich habe ein Build von CE21.2 ohne die ganzen Patches (dtb und bl301) probiert und es funktioniert immer noch nicht.

    Ich habe null Ahnung, wie der bl301_manager an die Konfiguration kommt oder auch nur, wie der die Werte übergeben bekommen soll. Ich komme nicht dahinter. Eigentlich würde ich erwarten, daß die Werte aus der /flash/config.ini irgendwie in das Kernel-Modul des bl301_managers kommen, aber wie ist völlig unklar. Mit einem reinen CE21.3 funktioniert es ja, also muss es irgendwie gehen. Ich dachte, ich starte einfach mal Kodi und lass das Ding machen, aber selbst das funktioniert nicht.

    Probier mal diese 21.2

    Mein Grundsystem ist älter. Ich habe irgendwann mal von SD-Karte in den internen eMMC kopiert und nutze seitdem nur noch den internen Speicher. Alle Updates habe ich immer nur über tar-files im .upload-Ordner gemacht.

    VDR1: Odroid N2+ mit CoreELEC und Ubuntu in chroot, 2x WinTV DualHD, Sandisk 2TB SSD

    VDR2: Tanix TX3 mit VDR*ELEC, WinTV DualHD, 500GB SSD

    Quote from Zabrimus

    Ich habe null Ahnung, wie der bl301_manager an die Konfiguration kommt oder auch nur, wie der die Werte übergeben bekommen soll. Ich komme nicht dahinter.

    das müsste über das Kodi addon service.coreelec.settings erfolgen. In den Sourcen finde ich den Code hier ab Zeile 747 uff.

    Code
    self.oe.set_config_ini("remotewakeup", "\'" + remote["remotewakeup"] + "\'")

    Wo wird self.oe.set_config_ini nun definiert? In der oe.py finde ich

    Code
    def set_config_ini(var, val="\'\'"):
   with xbmcvfs.configini() as config:
       config.set(var, val)

    Und in der gleichen Datei steht configini = '/flash/config.ini'

    VDR1: Odroid N2+ mit CoreELEC und Ubuntu in chroot, 2x WinTV DualHD, Sandisk 2TB SSD

    VDR2: Tanix TX3 mit VDR*ELEC, WinTV DualHD, 500GB SSD

    Quote from Dr. Seltsam

    das müsste über das Kodi addon service.coreelec.settings erfolgen. In den Sourcen finde ich den Code hier ab Zeile 747 uff.

    Darüber bin ich auch schon gestolpert. Aber dann beginnt die Magie, die ich nicht verstehe:

    Code
    if os.access('/sys/class/bl301_manager/setup_bl301', os.W_OK):
                    setup_bl301 = open('/sys/class/bl301_manager/setup_bl301', 'w')
                    setup_bl301.write('1')
                    setup_bl301.close()

    Wie soll ein write von "1" irgendeine Parameterübergabe triggern? Dazu muss man wohl Python und Linux Kernel Module tiefer verstehen.

    Der Build mit dem Stand vom 09.08 ist durchgelaufen und der wakeup funktioniert. Jetzt muss ich mich nur noch rantasten, ab wann es nicht mehr geht.

    Quote from Zabrimus

    Wie soll ein write von "1" irgendeine Parameterübergabe triggern?

    Gar nicht. Ich hatte einen ziemlichen Denkfehler. Das Kernelmodul wird beim Boot mit den Parametern geladen und das Schreiben von "1" triggert nur das Schreiben der bereits vorhandenen Parameter. Das erklärt auch, warum eine Änderung der config.ini erst nach einen Reboot aktiv wird.

    Quote from Zabrimus

    Diese funktioniert wieder. Ich versuche jetzt mal, diese Version noch einmal lokal zu bauen, damit ich mich wieder vortasten kann.

    Ich habe so einige Build und Tests hinter mir. Die Interim-Build habe ich wieder hochgeladen. Die Beobachtungen lassen mich aber etwas ratlos zurück. Alle(!) lokalen Builds funktioren bzgl. wake-up. Ein Gegencheck mit dem letzten Release auf Github funktioniert allerdings nicht und sobald ich wieder einen lokalen Build installiere, klappt es wieder.

    Die Github-Builds sind echte clean Builds, bei den lokalen Builds bin ich von commit Hash zu commit Hash gesprungen, um das Ganze stark zu beschleunigen. Ich würde aber erwarten, daß beide Versionen sich gleich verhalten. Aber genau das tut es nicht. Die Build Umgebung ist bei beiden (Github und lokal) Ubuntu 22.04.

    Ich werde jetzt einen lokalen clean Build starten und prüfen, wie da der wake-up funktioniert. Dann muss ich weitersehen.

    Auf jeden Fall bin ich verwirrt....

    Edit:
    Sooo. Ein clean Build ist durch und genau der funktioniert schon wieder nicht (wie auch die Github-Version). Was zum Henker unterscheidet einen clean Build von einem Build mit Updates?

    Edit2:

    Quote from Dr. Seltsam

    es gibt zwischen Deiner 21.3 und der stable 21.3 von CE Unterschiede in /etc/inject_bl301/bl301.conf

    Du hattest den absolut richtigen Riecher. Chapeau! Bei dem nicht-funktionierendem clean-Build habe ich im Build rumgefummelt und konnte ein Image erstellen, in dem die bl301.conf die fehlenden Zeilen hatte. Und damit funktioniert der wake-up wieder.
    Jetzt besteht die Aufgabe nur darin, herauszufinden, warum die bl301.conf unvollständig erzeugt wird.

    Edited 2 times, last by Zabrimus (December 14, 2025 at 6:18 PM).

    Glückwunsch und Danke für die Suche! :] Das ganze ist so komplex, dass ich jeden bewundere, der da noch durchblickt.

    Übrigens: Ich glaube, ps3remote.py läuft in ng immer noch nicht (siehe hier). In CE22-no hatte es aber funktioniert. Als ich CE21-ng getestet hatte, musste ich den workaround basteln. Vielleicht kannst Du Dir das auch nochmal anschauen.

    VDR1: Odroid N2+ mit CoreELEC und Ubuntu in chroot, 2x WinTV DualHD, Sandisk 2TB SSD

    VDR2: Tanix TX3 mit VDR*ELEC, WinTV DualHD, 500GB SSD

    Das Problem mit bl301 ist auch noch hausgemacht :(

    Bei den Github-Builds muss ich mit "AUTOREMOVE=1" arbeiten, da ansonsten der verfügbare Speicherplatz in den Images bei weitem nicht ausreicht. Ich lösche in den Images schon sehr aggressiv viele Pakete und vorinstallierte Programme.

    Bei "AUTOREMOVE=1" werden die Build-Sourcen gelöscht, wenn sie nicht mehr gebraucht werden. Dazu werden die Pakete analysiert und Abhängigkeiten ermittelt. Durch einige Testbuilds habe ich auch offziell nicht-abhängige Pakete als Ausnahme hinzugefügt. Wenn z.b. Paket A die Sourcen von Paket B benötigt, dann wird Paket B erst gelöscht, wenn Paket A fertig ist.
    Das hat bei inject_bl301 nicht funktioniert. Als schnelle Lösung habe ich für die bl301_* Sourcen Ausnahmen hinzugefügt.

    Ich habe die CoreELEC Images neu erstellen lassen und mit dem letzten CE-Release funktioniert der wake-up auf der TX3 wieder. Und auch wol klappt endlich :)

    Hi Zabrimus,

    hab mal CE22 mit deinen letzte n Änderungen neu gebaut, das Wakeup mit der Fernbedienung klappt jetzt! :thumbup:

    Allerdings will wol noch nicht:

    In der config.ini ist wol aktiv; allerdings sehe ich davon nichts in der boot.ini und auch nicht in der Kernel cmdline.

    Hier zum Vergleich unter CE21

    Wie es aussieht, fehlt mir der wol Eintrag in der boot.ini. Ich hab das nachgetragen und auch das setenv initargs erweitert.

    In der Kernel Cmdline kommt es auch an:

    CoreELEC:~ # cat /proc/cmdline
    systemd.show_status=auto BOOT_IMAGE=kernel.img boot=UUID=1234-ABCD disk=UUID=1a02624b-7ddf-4ccc-95e3-0eb663bb57e1 console=ttyS0,115200 console=tty0 no_console_suspend keymap=us enable_wol=1 hdmitx=cec7f remotewakeup=0x00003fbd decode_type=0x4 remotewakeupmask=0x000037ff enable_system_power=0 gpiopower=479 vout=2160p50hz,dis frac_rate_policy=0 hdmitx=, hdr_policy=1 quiet

    Allerdings will wol weiterhin nicht.

    Code
    CoreELEC:~ # dmesg | grep bl30
[    2.706304] bl30_manager: driver probe
[    8.735945] bl30_manager: Do setup BL30 blob
[    8.735982] bl30_manager: IR remote wake-up code: 0x3fbd
[    8.735987] bl30_manager: IR remote wake-up code protocol: 0x4
[    8.735990] bl30_manager: IR remote wake-up code mask: 0x37ff
[    8.735993] bl30_manager: enable 5V system power on suspend/power off state: 0
[    8.735997] bl30_manager: gpiopower: 65535 (479)
[    8.736001] bl30_manager: support WOL: 0

    Hab ich noch was übersehen?

    Nachtrag: Ich hab nochmal im Coreelec Git nachgeschaut:

    CoreELEC/projects/Amlogic-ce/devices/Amlogic-no/bootloader/Odroid_N2_boot.ini at coreelec-22 · CoreELEC/CoreELEC · GitHub
    CoreELEC/projects/Amlogic-ce/devices/Amlogic-no/bootloader/config.ini at coreelec-22 · CoreELEC/CoreELEC · GitHub

    Dort finde ich in beiden Dateien keine Bezüge zu wol.

    Edited once, last by LotharE (December 15, 2025 at 11:15 AM).

    Ich habe im softhdodroid nun noch das Setting Hdr2Sdr gefixed. Damit kann man nun auch HDR Sendungen auf einem SDR Monitor anschauen.

    Jetzt fehlt nur noch ein funktionierendes WOL im CE-22 und dann kann man es tatsächlich als VDR einsetzen.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login