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

Es wäre interessant zu wissen, welcher Teil der Änderung das Problem bei Dir verursacht.

Kannst Du mal schrittweise testen:

erst in SetPlayMode die beiden Zeilen

Clear();
MyVideoStream->ClearClose = 0;

auskommentieren. Dann erfolgt beim Umschalten kein amlReset mehr.

Wenn das Problem immer noch auftritt, verlege bitte

amlSetInt("/sys/class/video/blackout_policy", ConfigVideoBlackPicture);

wieder in Playmode 0 hinter die beiden o.g. Zeilen.

Wenn es dann nicht mehr auftritt, entferne die Kommentierung für die beiden o.g. Zeilen wieder und teste erneut.

Quote from jojo61

Habs grad gefixt und eingecheckt

ist super jetzt mit dem aktuellen Stand, alle meine Anmerkungen sind umgesetzt bzw behoben. Damit lass ich es jetzt über das Wochenende laufen aber ich bin schwer begeistert - war ich ja gestern schon. Wollte auch gestern Abend nur den ein oder anderen vom fehlerhaften Update abhalten und keine Aufruhr machen

Dass das Bild während einer Wiedergabe reproduzierbar an einer Stelle stehen bleibt tritt wirklich sehr sehr selten auf (vllt 3x in 2 Monaten), ich vermute das es ein kurzzeitiges Problem im Empfangsstream war, mit dem andere Frontends etwas großzügiger umgehen - Wenn hier jemand früher als ich einen Beispielschnipsel beisteuern kann wird jojo61 sich sicher freuen. Bin selber auch die zweite Märzhälfte in Urlaub.

Dann könntest Du in SetPlayMode hinter MyVideoStream->InvalidPesCounter = 0; die Zeilen

// tell hw decoder we are closing stream
VideoSetClosing(MyVideoStream->HwDecoder);
VideoResetStart(MyVideoStream->HwDecoder);

ergänzen. Ich konnte allerdings nicht nachvollziehen, dass die irgend etwas zur Ausführung bringen.

Und letztlich könntest Du

VideoDisplayWakeup();
Play();

für Playmode 1 bis 4 wieder eintragen. Ich konnte allerdings nicht feststellen, dass das irgendwas bewirkt.

Ich verstehe es bloß nicht, denn inzwischen hast Du eigentlich alles wieder so zurückgeändert wie in Deinem Original. Mit welcher Box testest Du? Muss mir dann wohl auch mal einen satip-Server einrichten. Was hast Du dafür laufen? minisatip?

Ja, die aktuelle git ist fixer geworden.

...

was anderes: Ich habe auf meiner Tanix TX3 ein normales CoreELEC und dann vdr in Ubuntu-chroot nach Rezept von beta. Ich würde gerne auch das timergesteuerte wakeup einrichten, stehe allerdings nach den letzten Threads zu dem Thema total im Wald und blicke nicht mehr durch. Kann ich den Kernel von Zabrimus aus seinem iso nehmen (welche Dateien genau?) und auf meine bestehende CE-Installation verpflanzen? Muss ich irgendwelche Module laden? Was muss ich mit dem Tool inject_bl301 genau machen? Und wie sieht das shutdown-Script aus? Wäre toll, wenn Du dazu mal ein kleines HowTo schreiben könntest.

ich hatte auch lange ein Zabrimus Image unter dem chroot, nutze jetzt das originale CE20.

Auch wenn es hier etwas OT ist: was sind eure genauen Gründe weiter auf Zabrimus aufzubauen, bisher fehlt mir hier nichts außer das ich es nicht hinbekomme die "de.yavdr.frontend.conf" und die "de.yavdr.lircd2uinput.conf" nach /etc/dbus-1/system.d zu bekommen?

Ich hatte schon versucht das Verzeichnis mit "mount -o bind /storage/.config/dbus-1/system.d /etc/dbus-1/system.d" vor start des dbus Deamon im Filesystem auszutauschen aber ich bekomm es irgendwie nicht funktional hin das ich mir den Service mit "dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames" anzeigen kann.

Ist aber jetzt auch nicht kriegsentscheidend für mich.

die zu bauende distri ist dann ce20? baut das unter Ubuntu 22.04?

o.k., dann muss ich es auf dem VDR laufen lassen, der hat noch (oder wieder) 20.04

Auf dem Desktop-Rechner mit 22.04 hatte ich dies probiert:

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

und erhielt die wenig vertrauenserweckende Fehlermeldung

Read config CoreELEC-20
fatal: mehrdeutiges Argument 'origin/coreelec-20': unbekannter Commit oder Pfad existiert nicht

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.

Quote from jojo61

Wenn du ein Corelec mit chroot nutzt dann ist es ganz einfach. Du holst dir das Generic Image von Zabrimus und kopierst es nach /storage/.update

Nach dem booten hast du dann alles was du brauchst. Es wird dabei nur die CE Installation upgedatet und dein chroot bleibt unangetastet.

Der inject_bl301 läuft auch automatisch. Du müsstest dann eine Datei /sys/class/rtc/rtc0/wakealarm haben.

Das hat wunderbar geklappt. Ich habe dazu die tar-Datei aus dem target-Ordner genommen (soll laut CE schneller gehen als img.gz). nach dem reboot ist /sys/class/rtc/rtc0/wakealarm vorhanden.

Quote

Je nachdem welche Distro du im chroot nutzt sollte das stellen des wakealarms schon drin sein. Ich hatte aber auch im Thread von Zabrimus mal ein script zum stellen des wakealarms eingestellt. Das findest du aber auch in anderen Threads. Wenn du da nicht weiter kommst dann schreib nochmal.

Ich habe jetzt diesen Beitrag uff. gefunden:

Post

[VDR*ELEC] - CoreELEC mit Amlogic und wakeup

Hallo

ich habe festgestellt das die Wakeup funktionalität der Boards ohne Hardware RTC nicht sauber funktioniert. Der RTC kann (so wie ich es getestet habe) nur bis ca. 70 Minuten gesetzt werden.

Werden grössere Zeiten eingetragen werden dann wacht das Board früher auf weil die Zeit wohl wrapped.

Bei den Tests ist mir aufgefallen das es egal ist welchen Timer man nutzt. Also meson-vrtc oder aml_vrtc haben den gleichen Fehler. Wir hatten ja den Device Tree gepacht damit der meson-vrtc zum Einsatz…

jojo61

March 3, 2023 at 2:44 PM

Wenn ich es richtig verstanden habe, brauche ich nicht in/sys/kernel/debug/wakeup_time schreiben, sondern kann das gleiche

Shutdown-Script wie auf dem N2 benutzen. Dort sieht meine vdrshutdown.sh so aus (nach Rezept von beta für vdr in chroot) :

#!/bin/bash
sudo hwclock --systohc --utc
NextTimer=$(($1 - 600 ))  # 10 minutes earlier
sudo bash -c "echo 0 > /sys/class/rtc/rtc0/wakealarm"
sudo bash -c "echo $NextTimer > /sys/class/rtc/rtc0/wakealarm"
killall loopershutdown

(Die letzte Zeile sorgt für den Shutdown, der in chroot ja nicht direkt ausgeführt werden kann)

Ich werde das heute Nacht mit einem Timer testen. Einstweilen fällt mir auf, dass bei der Tanix TX3 zwar das Bild beim Ausschalten sofort weg ist, aber dann bleibt die Box noch mehrere Minuten an (erkennbar am Display), ehe sie ausschaltet. Ob es daran liegt, dass der hwclock-Befehl bei manueller Ausführung einen Fehler bringt? edit: ja, bei deaktivierter Zeile wird sofort abgeschaltet

sudo hwclock --systohc --utc
hwclock: ioctl(RTC_SET_TIME) to /dev/rtc0 to set the time failed: Invalid argument

/dev/rtc0 ist vorhanden. Auf dem N2 funktioniert der hwclock-Befehl problemlos.

....

Für alle die kein /sys/class/rtc/rtc0/wakealarm haben und in /sys/kernel/debug/wakeup_time schreiben müssen, könnte Deine Aussage

Quote

Wobei man evtl. von $2 (Zeit bis zum nächsten Timer in Sekunden) noch 300 abziehen sollte um etwas vorlauf zu haben.

verwirren. Ist es nicht vielmehr so, dass man dann 300 Sekunden dazuaddieren muss?

#!/bin/bash
NextTimer=$(($2 + 300 ))  # number of seconds from the current time until the next timer event + 5 minutes buffer
echo 0 >/sys/kernel/debug/wakeup_time
echo $NextTimer >/sys/kernel/debug/wakeup_time
systemctl suspend

hm... ja, Du hast Recht. Wenn ich sie dazu addiere, dauert es länger und die Box schaltet zu spät ein. Ich werde alt...

Das mit dem Patch freut mich.

Moin Moin

horchi hat mich gerade darauf Aufmerksam gemacht, dass UHD mit HLG nur Standbild bringt. Er ist auf CE 19, ich auf 20.

Bringt bei live genauso wie bei Wiedergabe nur Standbild aber läuft nicht an: d90c638 13892df läuft hier noch, ich hangel mich mal nach vorn der Fehler tritt erstmalig in d74ba03 auf