gut zu wissen, da brauche ich gar nicht erst testen, denn dann bleibe ich lieber bei dem Image von vor 2 Wochen.
Da funktoiniert der Neustart per Fernbedienung ja noch.
Das einzige was mir da fehlt ist die neuere Version von softhdodroid, bei dem jetzt der Ton mit DD+ ausgegeben werden kann.
Ich habe 3 Versionen hochgeladen mit aktuellen Plugins und eher zufällig ausgewählten Versionen von CE20-ng zwischen der letzten funktionierenden Version und der Version vor der ersten Fehlermeldung.
Test-0a6083b-CoreELEC-Amlogic-ng.arm-20.3-Nexus_devel_20231007163636.tar (26.9)
Test-ae69d66-CoreELEC-Amlogic-ng.arm-20.3-Nexus_devel_20231007162620.tar (10.9)
Test-bcd5f92-CoreELEC-Amlogic-ng.arm-20.3-Nexus_devel_20231007161353.tar (15.8)
Die Version Test-bcd5f92 sollte noch funktionieren. Bei denen danach, weiß ich es nicht. Es wäre schön, wenn die Versionen einen schnellen Test unterzogen werden können, damit die letzte funktionierende Version von CE20-ng bestimmt werden kann. Das dauert leider alles ziemlich lange.
Edit:
Ich habe alle Versionen gelöscht. Beim Build muss irgendwas schief gegangen sein.
Vorsicht, bei mir hängt das System in einer Boot Schleife... nachdem ich das mittlere (Test-ae69d66) Image unter /storage/.update abgelegt habe, liefe erst das Update durch und seit dem bootet mein Odroid N2+ in Dauerschleife. Es wird immer nur kurz das HardKernel Logo angezeigt und dann immer wieder Neustart, Logo usw.
Komme heute nicht mehr groß zum weiter probieren. Möchte nur die Warnung loslassen.
ich hatte bereits im beitrag #190 geschrieben, dass die letzte mit Neustart per Fernbedienung funktionierende Version diese ist:
VDR-CoreELEC-Amlogic-ng.arm-20.3-Nexus-2023-09-23.1-Odroid_N2.img.gz
Diese benutze ich momentan, damit ich nicht immer den Spannungsstecker ziehen muss, damit die Box wieder startet.
Vorsicht, bei mir hängt das System in einer Boot Schleife... nachdem ich das mittlere (Test-ae69d66) Image unter /storage/.update abgelegt habe, liefe erst das Update durch und seit dem bootet mein Odroid N2+ in Dauerschleife.
Oh wow. So fatal? Ich habe das File direkt mal gelöscht.
Ich hatte bereits im beitrag #190 geschrieben, dass die letzte mit Neustart per Fernbedienung funktionierende Version diese ist:
Ja, das habe ich schon verstanden. Soll ich bei CE20 auf dieser einen Version festhängen und kein Update mehr machen?
Ich fürchte, ich muss irgendwie ein 20er System aufbauen.
ich habe mir eine andere eMMC vorbereitet und werde mich auf die Suche machen. Nachvollziehen kann ich beide Probleme: Power-On und Boot-Loop. Das ist ein ziemlicher Mist, weil ich auch nicht weiß, was beim Build schief gegangen ist.
Edit:
Der Boot-Loop ist richtig ätzend. Ich bin da nur auf die harte Tour wieder rausgekommen.
Funktionierendes Archiv holen und entpacken:
wget https://github.com/Zabrimus/VDRSternELEC/releases/download/2023-10-07.1/VDR-CoreELEC-Amlogic-ng.arm-20.3-Nexus-2023-10-07.1-Odroid_N2.img.gz
gzip -d VDR-CoreELEC-Amlogic-ng.arm-20.3-Nexus-2023-10-07.1-Odroid_N2.img.gzPartition mounten
> sudo fdisk -l VDR-CoreELEC-Amlogic-ng.arm-20.3-Nexus-2023-10-07.1-Odroid_N2.img
Disk VDR-CoreELEC-Amlogic-ng.arm-20.3-Nexus-2023-10-07.1-Odroid_N2.img: 548 MiB, 574619648 bytes, 1122304 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe057a4ea
Device Boot Start End Sectors Size Id Type
VDR-CoreELEC-Amlogic-ng.arm-20.3-Nexus-2023-10-07.1-Odroid_N2.img1 * 8192 1056767 1048576 512M c W95 FAT32 (LBA)
VDR-CoreELEC-Amlogic-ng.arm-20.3-Nexus-2023-10-07.1-Odroid_N2.img2 1056768 1122303 65536 32M 83 Linux
> mkdir ce20
> sudo mount -t auto -o loop,offset=$((8192*512)) VDR-CoreELEC-Amlogic-ng.arm-20.3-Nexus-2023-10-07.1-Odroid_N2.img ce20Kopieren von kernel* und SYSTEM* auf die eMMC.
cp ce20/kernel* <pfad zu eMMC-Mount>
cp cd20/SYSTEM* <pfad zu eMMC-Mount>Alles klar, mein Ordoid N2+ läuft so auch wieder.
Sag bescheid wenn ich irgendwas testen kann...
Nach endlosen Compile-Läufen und Installationen habe ich den Commit gefunden, ab dem der Wakeup nicht mehr funktioniert:
Der Commit davor funktioniert noch einwandfrei.
Und genau diese Änderung verursacht die Probleme:
l301_manager: send scpi cmds only by sysfs callSoooo... Und da steige ich aus.
...aber das Wakeup Problem müssen doch auch die (nur) CoreELEC Installationen haben? Auf selber Hardware...
...aber das Wakeup Problem müssen doch auch die (nur) CoreELEC Installationen haben? Auf selber Hardware...
Das würde ich auch so sehen.
Ich habe einen package patch erstellt, der das File bl301_manager.c im Linux Kernel Driver auf die Vorversion zurücksetzt. Power-Off/On funktioniert (zumindest bei mir). Testweise habe ich das Update erstellt (ist sogar noch aktueller als die offizielle Version vom Samstag):
Wenn das zufriedenstellend läuft, werde ich den Patch committen und außer der Reihe das Build anwerfen um neue Releases zu erstellen. Ich hoffe, daß es für andere CE-Systeme keine Auswirkungen hat. Die Vorversion hat ja auch bisher problemlos funktioniert.
Super Idee vdr_rossi
habe ich mal schnell auf einer SDcard getestet.
Blankes CoreElec von heute genommen CoreELEC-Amlogic-ng.arm-20.3-Nexus_nightly_20231008-Odroid_N2.img.gz
Installiert und danach meine alte config.ini mit der Wakeup-Code meiner Fernbedienung reinkopiert.
Funktioniert, d.h. ich kann mit der Fernbedienung den Odroid runterfahren und danach problemlos wieder starten.
Es liegt also sehr wahrscheinlich nicht an den Commits, sonst hätten sich ja schon mehr Leute im Coreelec-Forum beschwert.
Muss also an irgendwas im VDR*ELEC Image sein, was hier Probleme macht!
Muss also an irgendwas im VDR*ELEC Image sein, was hier Probleme macht!
Frische Installation vs. Update. Vielleicht liegt es daran? Ich bin auch nur von der letzten funktionierenden Version immer höher gewandert durch die Updates.
Aber es ist tatsächlich so, daß ein Downgrade des bl301_manager.c einen Erfolg brachte und das auch reproduzierbar und in allen getesteten Versionen.
Vielleicht hat das irgendwas mit uboot zu tun und wieder das Thema Update/Neuinstallation. Aber da bin ich vollständig aus der Komfortzone und ich habe keinen blassen Dunst von dem Thema.
Frische Installation vs. Update.
Da habe ich jetzt mal weitergemacht und habe auf die neu installierte SDcard jetzt das letzte Image von VDR*ELEC als Update installiert, also die VDR-CoreELEC-Amlogic-ng.arm-20.3-Nexus-2023-10-07.1-Odroid_N2.img.gz in das /storage/.update-Verzeichnis gelegt und ein reboot gemacht.
Dann noch die /storage/.profile erstellt, aber so, dass zuerst KODI gestartet wird, weil ich zu faul war alles neu zu konfigurieren, sondern wollte das CoreElec-Backup nutzen, um wieder alles so zu haben, wie beim letzten System.
Hat auch alles soweit funktioniert, nach dem ersten reboot war dann alles soweit okay.
Ich konnte auch von KODI zum VDR wechseln und da war auch alles okay.
Den Odroid runtergefahren und dann konnte ich auch per Fernbedienung wieder starten.
Super, es geht wieder! 
ALso habe ich gedacht, da kannst Du ja jetzt wieder die /storage/.profile so machen, dass zuerst der VDR gestartet wird.
Klappte natürlich auch und der Odroid bootet direkt in den VDR.
Dann noch rasch der ultimative Gegentest: Odroid runtergefahren und dann per Fernbedienung wieder gestartet!
Schei...e es klappt nicht, der Odroid startet nicht mehr per Fernbedienung. 
Versorgungsspannung AUS und wieder EIN damit der Odroid überhaupt bootet.
Die /storage/.profile wieder so geändert, dass zuerst KODI gestartet wird und dann den Odroid runtergefahren.
Jetzt klappt auch der Neustart per Fernbedienung wieder!
Lange Rede kurzer Sinn:
Wenn zuerst in KODI gebootet wird und dann zum VDR geswitcht wird, kann man per Fernbedienung wieder starten! Egal ob man von KODI oder vom VDR aus den shutdown ausführt.
Wenn man allerdings zuerst zum VDR bootet, dann kann man nicht mehr per Fernbedienung neu starten! 
ABER und jetzt kommt das große ABER: Wenn man nun allerdings einmal vom VDR zu KODI und dann wieder von KODI zum VDR switcht, dann klappt auch hier der Neustart per Fernbedienung.
Fazit:
Es muss also einmal von KODI zum VDR geswitcht werden, dann kann man wieder per Fernbedienung neu starten.
jetzt denke ich, musst Du nochmals schauen, warum es nur dann funktioniert, wenn man mindestens 1x von KODI zum VDR switcht.
Ich denke nicht, dass diese Patches etwas damit zu tun haben. Der von Zabrimus identifizierte Patch im bl301_manager dürfte verantwortlich sein.
Zum besseren Verständnis: Laut https://discourse.coreelec.org…feature-inject-bl301/6321 ist es u.a. beim N2 nicht erforderlich, den wakeup-Code manuell mittels inject_bl301 in den Bootloader zu schreiben:
ZitatThere is no need to run this injection on Hardkernel Odroid devices as the bootloader provided by CoreELEC already support these BL301 features.
Gemäß https://discourse.coreelec.org…igure-ir-wakeup-code/5282 soll der Eintrag in der config.ini reichen:
ZitatOn next suspend/power off you should be able to wake up the device with your previously scanned IR code.
Nun ist die Frage, wann/wie an welcher Stelle setzt CE beim suspend bzw. Poweroff den IR code? Wenn das trotz des erwähnten Patches jetzt immer noch funktioniert, wenn man 1x Kodi startet und wieder beendet, dann würde das ja bedeuten, dass die von systemd ausgeführten Scripte zum Beenden oder Starten von Kodi irgendwas in der Richtung machen. Das konnte ich bisher aber nicht identifizieren.
Was mir aber auffällt ist, dass Portisch nur für den amlogic-Kernel 5.4.210 noch einen weiteren Patch eingepflegt hat:
Vielleicht muss dieser Patch auch in den Kernel 4.9.20?
Man muss einmal in Kodi gewesen sein, damit der shutdown funktioniert, richtig?
Nöö, der Shutdown funktioniert immer! 
Nur das Neustarten per Fernbedienung funktioniert nur dann, wenn einmal von KODI zum VDR geswitcht wurde. dazu gibt es m.W.n. ein extra Script.
Ich habe, bis das problem geklärt ist, die /storage/.profile so konfiguriert, das zuerst KODI gestartet wird. Und dann switche ich manuell zum VDR.
Damit kann ich dann wenn ich den Odroid wieder starten will, einen Neustart per Fernbedienung ausführen und muss nicht die Versorgungsspannung AUS-EIN-schalten.
...aber das Wakeup Problem müssen doch auch die (nur) CoreELEC Installationen haben? Auf selber Hardware...
Das würde ich auch so sehen.
Ich habe jetzt den nightly build CoreELEC-Amlogic-ng.arm-20.3-Nexus_nightly_20231008-Odroid_N2.img von CE heruntergeladen und getestet. Wakeup nach Ausschalten aus dem Kodi-gui funktioniert einwandfrei. Dann habe ich vdr in einer Ubuntu-chroot-Umgebung installiert und dort klappt zwar das Ausschalten (mittels Befehl halt -p ausgeführt in CE) aber ebenfalls nicht mehr das anschließende Wiedereinschalten per Fernbedienung. Getestet mit vdr beim CE-Start (kodi maskiert).
Ich habe bisher nicht gefunden, wie der Ausschaltmechanismus bei CE aus Kodi heraus genau umgesetzt ist. Es gibt hier eine kodi-poweroff.service
[Unit]
Description=Kodi poweroff script
After=kodi.service
Before=systemd-poweroff.service
DefaultDependencies=no
[Service]
Type=oneshot
Environment=HOME=/storage
ExecStartPre=-/usr/lib/kodi/kodi-after
ExecStart=-/bin/sh -c ". /etc/profile; exec /bin/sh /storage/.config/shutdown.sh poweroff"
RemainAfterExit=yes
[Install]
WantedBy=poweroff.target... aber eine /storage/.config/shutdown.sh habe ich nicht gefunden!
Also ich habe kein extra shutdown-Script, sondern habe nur in der conf.d/vdr.conf diese Option gesetzt: --shutdown="shutdown -h now".
Mehr ist da nicht und das lief bisher immer einwandfrei.
So, ich habe Portisch im CoreElec Forum mal gefragt. Eine korrespondierende Änderung zu dem Kernel-Patch ist dieser Patch für Kodi. Deshalb funktioniert das Einschalten per FB auch nur, wenn Kodi 1x gestartet wurde.
Um das nun auch beim Start mit maskiertem kodi und laufendem vdr zu erreichen, empfiehlt sich so ein system.d-Script:
CoreELEC:~/.config/system.d # cat setup_bl301.service
[Unit]
Description=Transfer IR code to bl301 blob
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo 1 > /sys/class/bl301_manager/setup_bl301'
[Install]
WantedBy=default.targetAlso die Datei als /storage/.config/system.d/setup_bl301.service anlegen und mit systemctl enable setup_bl301.service aktivieren. Nach einem reboot funktioniert das Einschalten dann wieder wie gewohnt. Der Kernel-Patch sollte in VDR*ELEC daher nicht deaktiviert werden. Er kann auch nicht die Ursache für die boot-Schleife sein, denn auf einem daily image von CE tritt das nicht auf.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!