Wenn die /flash/dtb.img beim Bauen aus den Sourcen jedesmal neu erstellt wird, sollten wir vielleicht das hier patchen
- wol = <0x01>;
+ wol = <0x00>;sonst müsste man nach jedem Update die dtb.img wieder herstellen.
Apropos rc - läuft das bei euch unter CE22-no? Bekomme die amremote/eventlircd Geschichte da nicht zum laufen.
amremote ist wohl noch eine Baustelle. Ich habe hier lircd unter CE22 laufen. Dr. Seltsam hat dazu etwas erwähnt und auch einen Workaround für CE21.
Wenn die /flash/dtb.img beim Bauen aus den Sourcen jedesmal neu erstellt wird, sollten wir vielleicht das hier patchen
Ich würde erst ein Update versuchen und prüfen, ob wol immer noch funktioniert oder eben nicht. Bei dtb-Patches bekomme ich immer eine Gänsehaut.
Bei meinem Test lief amremote ohne workaround in CE22-no. Wird da denn eine andere Version der python-lib verwandt als für CE21-ng?
Morgen,
ich habe eben CE22 neu gebaut und das Update eingespielt.
Das wol funktioniert damit weiterhin. 
/flash/dtb.xml ist identisch zu Deiner Version.
Die Fehlermeldung im init-previous.log ist weg.
CoreELEC:~ # cat init-previous.log
'reboot update' or 'run update' was not run
UPDATE IN PROGRESS
Please do not reboot or turn off your CoreELEC device!
Found new compressed image file
Decompressing image file... OK
Mounting system partition...
Checking kernel.img.md5... OK
Checking SYSTEM.md5... OK
Checking size: OK
Updating from 22.0-Piers_devel_20251215080345 to 22.0-Piers_devel_20251217074944
Updating Kernel ... 100%
Updating Kernel md5... 100%
Updating System ... 100%
Updating System md5... 100%
Updating Boot Files...
Updating device tree with g12b_s922x_odroid_n2.dtb...
Updating device_trees folder...
Updating dtb.img by dtb.xml...
Updating boot.ini with Odroid_N2_boot.ini...
Updating boot logos with odroid_boot-logo.bmp.gz...
Updating u-boot on /dev/mmcblk1 with Odroid_N2_u-boot...
Boot Files Updated.
Cleaning up... done
System reboots now...Moin Zabrimus,
da es ja keine kompletten images mehr gibt sondern nur noch tar-Files, und ich auf meiner alten Mühle einen ganzen Tag brauche, um ein Image selbst zu bauen, ist bei einer Neuinstallation meine Grundlage immer ein ein zuvor installiertes image von CoreElec.
Ich habe also die alpha2 von CE-22-no auf meiner zweiten TX3 installiert und nach dem Einrichten CE-Amlogic-no.aarch64--22.0-VDR-1214.tar in den .update-Ordner geschoben. Nach dem Neustart kommt die Box nicht mehr über das TX3-Bootlogo hinaus. Nach einigen Minuten habe ich den Stecker gezogen und mir die µSD-Karte im PC angesehen. Der .update-Ordner ist leer und auf der ersten Partition ist die SYSTEM offenbar aus Deinem tar-File, denn sie enthält den Ordner /usr/local/bin. Die dtb.img ist ebenfalls korrekt. Logfiles gibt es leider keine. Kannst Du das bei Dir nachstellen? Ich vermute, Du hast bei Dir mit selbstgebauten images getestet?
da es ja keine kompletten images mehr gibt sondern nur noch tar-Files,
Eigentlich sollten einmal im Monat (am Monatsanfang) die kompletten Images gebaut werden. Im Dezember war der erste Build am 7.12 und damit hat meine Bedingung if [ $(date +"%d") -lt 7 ]; then nicht funktioniert. Mist, darauf habe ich nicht geachtet.
Kannst Du das bei Dir nachstellen?
Normalerweise müsste bei einem Update eine Ausgabe erscheinen mit Entpacken, prüfen, installieren und ähnliches. Also das was auch in /storage/init-previous.log zu sehen ist. Das Update scheint nicht vollständig durchgelaufen zu sein, warum auch immer. In dem Update-Tar im Verzeichnis target befinden sich der Kernel und das System und die md5 Files. Hast du mal versucht diese 4 Files in das /flash zu kopieren?
Ich vermute, Du hast bei Dir mit selbstgebauten images getestet?
Ich dachte, die letzten Tests hätte ich mit den Builds von Github probiert. Ich mache mal eben ein neues Update und schaue, wie die TX3 reagiert.
Ich habe zunächst versucht, den kompletten Inhalt der Bootpartition aus dem CE-22-Image zurückzukopieren in die SD-Karte. Die Box bootete dann wieder. Dann habe ich nochmal CE-Amlogic-no.aarch64--22.0-VDR-1214.tar in den .update-Ordner geschoben und neu gebootet. Es blieb wieder beim TX3-Bootlogo stehen. Keine Anzeige von Entpacken, prüfen, installieren o-ä.
Nach ein paar Minuten habe ich abgebrochen und mir die Karte im Rechner angesehen. Es gibt keinerlei Logdateien. Auf der Bootpartition ist die SYSTEM (72 MiB) offenbar unvollständig. Ich habe sie zusammen mit der KERNEL gelöscht und wollte sie mitsamt ihrer md5-Dateien nun durch die Dateien aus Deinem tar-File ersetzen. Nun kommt die Meldung, dass zu wenig Speicherplatz auf der Zielpartition zur Verfügung stünde - es fehlen 54 MiB. df -h sagt:
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sdg1 512M 82M 430M 17% /media/martin/COREELECDas reicht nicht:
martin@martin-desktop:/tmp/CoreELEC-Amlogic-no.aarch64--22.0-VDR-1214/target$ ls -l
total 495460
-rw-r--r-- 1 martin martin 24823808 2025-12-15 01:04 KERNEL
-rw-r--r-- 1 martin martin 48 2025-12-15 01:04 KERNEL.md5
-rw-r--r-- 1 martin martin 482516992 2025-12-15 01:04 SYSTEM
-rw-r--r-- 1 martin martin 48 2025-12-15 01:04 SYSTEM.md5Das erklärt, warum VDR*ELEC in Version 22 nicht auf eine CE22-Installation passt.
Ich habe auf der TX3 ein Update auf CE22 gemacht und es lief nicht gut. VDR hat weder Bild noch Ton. Kodi startet allerdings.
Also eigentlich kann das gar nicht funktioniert haben. Die Boot-Patition ist nur 512 MB groß, da passen nicht Kernel, System und die devices trees rein.
Das erklärt, warum VDR*ELEC in Version 22 nicht auf eine CE22-Installation passt.
Bei meinem Odroid ist die boot Partition auch 512 MB gross aber meine SYSTEM ist da nur 440 MB und nicht wie bei dir 480 MB gross. Ich baue selber und frage mich was da anders ist als die SYSTEM aus dem GIT. Ist da evtl. noch der cef Browser mit drin ?
Dann würde ich verstehen das es nicht mehr klappt. Ich denke wir sollten einfach die boot Partition vergrössern.
Also eigentlich kann das gar nicht funktioniert haben. Die Boot-Patition ist nur 512 MB groß, da passen nicht Kernel, System und die devices trees rein.
Das ist ein guter Punkt. Die Installation hat aber funktioniert, Kodi konnte gestartet werden, Addons wurden aktualisiert, per ssh kam ich drauf. Irgendwas ist seltsam und ich probiere es noch einmal.
Ich denke wir sollten einfach die boot Partition vergrössern.
Dies lässt sich machen, allerdings hat das Nebenwirkungen. Man kann dann nicht mehr von einem reinen CE/LE auf VDR*ELEC aktualisieren, weil CE/LE eine kleinere Boot Partition haben. Es wird dann auf jeden Fall ein Image von VDR*ELEC benötigt.
In SYSTEM befinden sich viele Konfigurationen die beim setup nach /storage installiiert werden und ansonsten im SYSTEM nix zu suchen haben. Man könnte den Kram auslagern, dann müsste man aber nach Installation diese Files separat downloaden und installieren. Irgendwie gefällt mir das alles nicht. Es gibt Configs, die aktualisiert werden müssen. Ich denke da z.B. an das Live-Plugin.
Wenn da einer eine gute Idee hat, dann raus damit.
In SYSTEM befinden sich viele Konfigurationen die beim setup nach /storage installiiert werden und ansonsten im SYSTEM nix zu suchen haben.
Sind die den zumindest als zip dort gelagert ?
Man kann dann nicht mehr von einem reinen CE/LE auf VDR*ELEC aktualisieren
Ich halte das für keinen wesentlichen Nachteil. Ich nutze immer das VDR*ELEC Image für die erstinstallation. Warum sollte man da mit einem CE/LE Image beginnen ?
Ich wäre dafür die, die "Installations-Kompatibilität" zu CE-Images beizubehalten. Dann lieber ein paar große Brocken aus dem squashfs-File rausnehmen und zur Nachinstallation anbieten - entweder per wget oder vielleicht sogar über die Kodi-Oberfläche als addon - ähnlich wie /storage/.kodi/addons/virtual.system-tools/. Kandidaten dafür wären m.E. die channellogos und der cef-Browser. Was dazu alleine alles in /usr/local/private liegt beansprucht viel Platz.
Und die channellogos bedürfen doch ohnehin Anpassungen durch den Benutzer. Angesichts der Vielzahl unterschiedlicher Provider, die alle eine unterschiedliche Schreibweise für die Kanalnamen haben, kann das eh nie out-of-the-box für alle funktionieren. Das Konzept von MegaV0lt ist ja auch so gedacht, dass man die LogoMapping.xml nach seinen individuellen Bedürfnissen editiert und dann ein Script (mp_logos.sh) laufen lässt, das die passenden Symlinks anlegt. Innerhalb des squashfs-Systems kann man aber nichts verändern und das Script und seine Konfigurationsdatei sind ja auch nicht dabei. Das gehört m.E. alles in /storage. Den Pluginparameter (-l ) für die Skins auf ein Verzeichnis in /storage umzubiegen ist ja kein Problem.
Ich habe die Workflows auf Github so umgestellt, daß jetzt immer Images erzeugt werden (sollen). Morgen kann man sehen, wie das so funktioniert und ob der Platz/die Zeit für die Workflows reicht.
Desweiteren gibt es ein paar gute Ideen, das SYSTEM kleiner zu bekommen. Ein paar Brocken könnten tatsächlich als Kodi-Addon umgebaut werden. Ich habe auch eine Anleitung gefunden, wie man Github als Kodi-Repository nutzen kann.
Dabei habe ich festgestellt, daß ich schon an Addons gearbeitet hatte und nicht weiter verfolgt, weil ich auf CE22 gewartet habe. Diese sind allerdings meinem Spieltrieb zu verdanken und für fast alle eher uninteressant 
Der Umbau wird allerdings ein wenig Zeit kosten, weil a) Umbau und b) Test des Umbaus und c) Änderung der Doku.
Eine andere Frage, die vielleicht jemand direkt beantworten kann:
Kann man Kodi-Addons auf der Console installieren lassen - auch ohne das Kodi läuft?
Lt. der Seite muss man anscheinend nur die ZIP-Datei des Plugins ins Plugin-Verzeichnis entpacken?!
Die Konfiguration des Plugins muss dann aber offenbar immer in Kodi selbst erfolgen.
Lt. der Seite muss man anscheinend nur die ZIP-Datei des Plugins ins Plugin-Verzeichnis entpacken?!
So einfach ist das? Klingt auf jeden Fall gut. Im Post 15 sind noch ein paar arbeiten notwendig, aber auch das lässt sich scripten. Danke!
Ich versuche gerade, den cefbrowser mitsamt cef selbst in ein Addon zu packen. Die Abhängigkeiten sind schon spannend und was da alles zusammenkommt ist schon enorm. Ein weiterer Vorteil ist, das ich dann auch cef aktualisieren kann ohne laufende System zu brechen oder eher das Risiko kleiner zu halten.
Ich habe gerade festgestellt das irgendwann in CE-21 die aml Module upgedatet wurden. Nun funktioniert h265 nur noch eingeschränkt. Die offenen SES Testsender funktionieren noch, aber der HD+ Testsender funktioniert nicht mehr.
Dort wird kein Bild mehr angezeigt. Ich habe dann mal ein Recording davon gemacht und versucht in Kodi abzuspielen. Das geht da auch nicht mehr (schwarzes Bild). Allerdings zeigt Kodi da ein vorschaubild und deswegen bin ich mir sicher das das Video aufgezeichnet wurde.
Ich vermute mal das Coreelec davon noch nichts mitbekommen habt.
PS: der Ton funktioniert in VDR und in Kodi.
Ich habe gerade festgestellt das irgendwann in CE-21 die aml Module upgedatet wurden.
Welche meinst du denn? Seit Omega 21.3 gab es nicht wirklich spektakuläres mehr.
Ich vermute mal das Coreelec davon noch nichts mitbekommen habt.
Das wird ein Problem. Für CE 21 passiert nicht mehr wirklich viel und denke nicht, daß da noch etwas gefixed wird.
Wenn das Paket identifiziert werden kann, kann man ein Downgrade machen, damit es wenigstens wieder funktioniert.
Welche meinst du denn? Seit Omega 21.3 gab es nicht wirklich spektakuläres mehr.
Ich kann es leider nicht genauer spezifizieren. Es könnte mit Omega 21.3 gekommen sein. Ich vermute mal das es in der CE-22 und CE-21.3-NE Version auch nicht mehr geht. Habs aber nicht ausprobiert.
Zu erkennen ist es einfach daran das nun unter /dev neue devices für hevc zu finden sind. Z.b. /dev/amstream_hevc_frame und /dev/amstream_dves_hevc_frame. Die gab es vorher (vermutlich dann in 21.2) noch nicht.
Stell doch mal von diesem HD+Sender eine Beispielaufnahme online. Hast Du mal geprüft, ob der Fehler in CE22-no auch auftritt? Wenn ja, sehe ich Chancen, dass ein Fix gefunden und dann auch für CE21 rückportiert wird. Wenn nein, wird es wohl in der Tat heißen, dass man sich nur noch auf no konzentriert.
Don’t have an account yet? Register yourself now and be a part of our community!
