Posts by Dr. Seltsam

so eine Option gibt es in den softhdodroid-Einstellungen nicht

Quote from horchi

Im Wohnzimmer auf dem N2+ mit coreElec als Basis zappt es (auch über streamdev) sehr flink.

Hast Du in den softhdodroid-Einstellungen die Option Fast Channel Switch noch aktiviert? Das ist noch immer der default-Wert, weil das Umschalten sonst in der Anfangszeit des Plugins recht lange dauerte. Das ist inzwischen aber gefixt. Mit aktiviertem Fast Switch mogelt softhdodroid. Das neue Bild ist zwar extrem schnell da, aber die A/V Synchronisation ist noch nicht fertig. Das Bild läuft einen Moment und bleibt dann kurz stehen, bis der Ton synchron ist. Wenn der Versatz gering ist, fällt das oft kaum störend auf. Aber nur ohne Fast Switch ist der Umschaltvorgang absolut sauber und mit softhddrm-gles vergleichbar. Ansonsten vergleichst Du Äpfel mit Birnen, denn rell hat so einen Fast Switch nicht implementiert (was auch richtig ist).

I am sorry

mit meinem letzten Patch hat sich leider ein Bug eingeschlichen, der Radiosender stumm bleiben lässt. Auch mit aktiviertem Hintergrundbild (iptv oder radio-Plugin) klappt die Tonwiedergabe je nach Methode (PlayPes/Stillpicture) nur sehr unzuverlässig. Zum Glück scheint es nicht viele Radiohörer zu geben, sonst hätte sich bestimmt schon jemand gemeldet

jojo61 So muss es bitte geändert werden:

--- audio.c.orig	2026-04-26 12:21:35.418194479 +0200
+++ audio.c	2026-04-30 13:18:30.000000000 +0200
@@ -2170,7 +2170,7 @@
             pthread_cond_signal(&AudioStartCond);
             Debug(3, "audio: Start on AudioEnque Threshold %d n %ld IsReady %d\n", AudioStartThreshold, n, AudioVideoIsReady);
         }
-
+        AudioPlay();
     }
     // Update audio clock (stupid gcc developers thinks INT64_C is unsigned)
     if (AudioRing[AudioRingWrite].PTS != (int64_t) AV_NOPTS_VALUE) {
@@ -2261,7 +2261,6 @@
     //}
     Debug(3,"audio: AudioVideoIsReady");
     AudioVideoIsReady = 1;
-    AudioPlay();
 
 }

Das Wiederanschalten des Tones nach dem Kanalwechsel erfolgt dann auch bei fehlenden Videopaketen, sobald der Audio Thread wieder angelaufen ist.

Ich verlinke hier mal das Kodi-Wechselproblem:

Post

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

Mit dem CE22-image vom 03.04.26 sowie dem update CE-Amlogic-no.aarch64-22.0-VDR-0410.tar funktioniert es noch. Ab CE-Amlogic-no.aarch64-22.0-VDR-0417.tar tritt der Fehler auf.

Laut https://github.com/Zabrimus/VDRSt…ELEC-22-Release ist da von Zabrimus aber gar nichts an den CoreELEC-Sourcen geändert worden. Oder kann das ein git-Anzeigefehler sein?

Das sind jetzt so viele Commits bei CE in den letzten Tagen erfolgt, dass wir erstmal abwarten sollten, bis die im nächsten release von Zabrimus…

Dr. Seltsam

April 26, 2026 at 1:44 PM

Vielleicht ist es ein Timing Problem - kodi wird gestartet, noch ehe softhdodroid mit dem Abarbeiten des DETA fertig ist. Um da testweise einen sleep einzubauen, müsste man aber diverse Scripte in angepasster Form in storage ablegen. Es müsste sich aber auch manuell auf der Konsole testen lassen:

svdrpsend PLUG softhdodroid DETA
svdrpsend REMO off
svdrpsend PLUG cecremote DISC
echo rm pip0 > /sys/class/vfm/map

ob der echo-Befehl überhaupt notwendig ist oder sogar stört, müsste ich nachsehen. Jetzt jedenfalls 1-3 Sekunden warten und dann

systemctl start kodi

Zurück mit stop kodi und ATA sowie REMO on

Ich habe in softhdodroid bezüglich der Hardware-Deinitialisierung nichts gefunden, was bei einem Beenden von vdr anders gemacht würde als beim DETA des Ausgabeplugins.

Hallo Zabrimus ,

ich habe mir gestern einen Wolf gesucht, warum sich CE22 nach dem Ausschalten nicht mehr per FB einschalten lässt. Nach meiner Erinnerung war das ein längst gelöstes Problem mit dem bl301 blob (Das Übertragen des IR Codes erfolgt erst beim Start von Kodi und muss manuell angestoßen werden, wenn man in vdr bootet und Kodi nicht benutzt.) Du hast das im README aber tatsächlich noch als Option beschrieben, die manuell aktiviert werden muss:

CoreELEC 20 and above: Wakeup via remote

Since CoreELEC 20 it could be necessary to enable the systemd script /storage/.config/system.d/setup_bl301.service if the system boots directly VDR. If you observe problems starting your system via remote and you are using CoreELEC 20 or above, then try to enable the systemd script via

cp /usr/local/system.d/setup_bl301.service /storage/.config/system.d
systemctl daemon-reload
systemctl enable setup_bl301.service
systemctl start setup_bl301.service 

Mein Vorschlag wäre, dass setup_bl301.service bereits per default aktiv ist. Oder automatisch aktiviert wird, wenn /usr/local/bin/install.sh -b vdr  ausgeführt wird. Inzwischen ist das nämlich nicht mehr "could be necessary" sondern in allen CE-Versionen zwingend erforderlich, wenn man eine amlogix-Box mit dem integrierten IR-Empfänger einschalten können will.

update zu meinem Problem aus Dezember (siehe vorherige Postings): Mit einem neu verlöteten TSP31238 (geänderte PIN-Belegung) funktioniert die FB wieder wie gewohnt. Jetzt nutze ich den inzwischen schon ersetzten N2 für Experimente mit CE22. Hier fiel mir auf, dass das für amremote verwandte Script ps3remote.py unter Python 3.14 nicht mehr funktioniert. Mit diesem Patch läuft es wieder:

--- ps3remote.py-orig	2026-04-26 13:49:08.793205174 +0200
+++ ps3remote.py-neu	2026-04-25 18:13:27.777562950 +0200
@@ -122,9 +122,20 @@
         help="drop to GROUP")
     return parser.parse_args()
 
+def get_or_create_eventloop():
+    try:
+        return asyncio.get_event_loop()
+    except RuntimeError as ex:
+        if "There is no current event loop in thread" in str(ex):
+            loop = asyncio.new_event_loop()
+            asyncio.set_event_loop(loop)
+            return asyncio.get_event_loop()
+        else:
+          raise ex
+    
 def main():
     options = parse_args()
-    loop = asyncio.get_event_loop()
+    loop = get_or_create_eventloop()
     event_translator = EventTranslator(loop, options)
     drop_privileges(options.user, options.group)
     try:

Das ist abwärtskompatibel zu python 3.11 aus CE21-ng.

Zabrimus Kannst Du das bitte aufnehmen?

seahawk1986 Vielleicht möchtest Du das als ursprünglicher Entwickler dieses Scripts auch in Deinen Sourcen nachpflegen?

Mit dem CE22-image vom 03.04.26 sowie dem update CE-Amlogic-no.aarch64-22.0-VDR-0410.tar funktioniert es noch. Ab CE-Amlogic-no.aarch64-22.0-VDR-0417.tar tritt der Fehler auf.

Laut https://github.com/Zabrimus/VDRSt…ELEC-22-Release ist da von Zabrimus aber gar nichts an den CoreELEC-Sourcen geändert worden. Oder kann das ein git-Anzeigefehler sein?

Das sind jetzt so viele Commits bei CE in den letzten Tagen erfolgt, dass wir erstmal abwarten sollten, bis die im nächsten release von Zabrimus angekommen sind.

Wenn vdr im Hintergrund keine Aufnahmen machen muss, kann man in der .profile die Zeile SWITCH_VDR_SCRIPT auskommentieren. Dann wird vdr komplett beendet. Das klappt auch ab der Version 0417 noch. Entweder gibt es noch einen gravierenden Unterschied zwischen DETA und Beenden des Plugins, oder es liegt an einem Unterschied beim Kodi-Start. Mir ist der Mechanismus nämlich noch nicht klar. Wo wird denn hier überhaupt Kodi nach dem DETA gestartet bzw. beim ATTA wieder beendet?

#!/bin/bash

# Use this script to either attach or detach the VDR frontend
# The script takes one parameter 'attach' or 'detach' which can be used to distinguish between the desired command.

# The following sample works only for softhdodroid
# For all other VDR frontend plugins, the script needs to be adapted

if [ "$1" = "attach" ]; then
    systemctl is-active --quiet vdropt
    if [ $? -ne 0 ]; then
      # VDR is not running, start
      systemctl start vdropt
    else
      # Attach to running VDR
      # echo 4 > /sys/module/amvdec_h264/parameters/dec_control
      /usr/local/bin/svdrpsend REMO on
      /usr/local/bin/svdrpsend PLUG cecremote CONN
      /usr/local/bin/svdrpsend PLUG softhdodroid ATTA
    fi
elif [ "$1" = "detach" ]; then
    /usr/local/bin/svdrpsend PLUG softhdodroid DETA
    /usr/local/bin/svdrpsend REMO off
    /usr/local/bin/svdrpsend PLUG cecremote DISC
    echo rm pip0 > /sys/class/vfm/map
fi

laut Portisch ist die Meldung kein Fehler

Quote from jsffm

Auch ohne X-Server?

sowohl mit als auch ohne. Kann sein, dass ich für softhddevice mit x-server in der remote.conf XKeySym-Einträge benutzen musste.

ich muss jetzt mal ganz blöd fragen:

Ich habe in 25 Jahren noch nie mit irgendeiner angeschlossenen Tastatur Probleme gehabt, egal welches output-Plugin ich benutzt habe. vdr hat jede Tastatur out-of-the box erkannt und den Anlerndialog gestartet, wenn noch keine remote.conf vorhanden war.

Wo genau liegt jetzt der Vorteil dieses Plugins bzw. für welchen Anwendungsfall wird es benötigt?

Quote from pixelpeter

Nutzt jemand mit diesem Plugi auch KODI?

Ich hatte es bisher mit dem externalplayer gestartet, allerdings bekomme ich hier kein Bild.

Der externalplayer dürfte hier nicht der richtige Ansatz sein. Es sollte besser über die commands.conf ein script gestartet werden, das das Ausgabeplugin mittels svdrpsend detached und kodi startet. Nach dem Beenden von kodi folgt dann wieder ein attach. So läuft es mit softhdodroid und softhddrm-gles bei VDR*Elec problemlos.

Ob vaapuvideo beim DETA die Ressourcen für Kodi freigibt und sich ATTA analog seiner Erstinitialisierubg beim Start zurückholt, weiss ich nicht. Aber vielleicht hatte es seahawk so getestet.

Das externalplayer-Plugin macht m.E. nur Sinn wenn eine X-Umgebung mehrere Programme gleichzeitig darstellen kann.

Quote from Zabrimus

Ich weiß gar nicht was nicht funktioniert. Ich nehme an, das Plugin kennt die svdrp Kommandos ATTA und DETA?
Dann kannst du in /storage/.profile einen zusätzlichen Eintrag machen
SWITCH_VDR_SCRIPT=/usr/local/bin/switch_vdr_softhdodroid.sh
und ein eigenes Script angeben und evt. nur im bestehenden Script softhdodroid durch softhddevice-drm-gles ersetzen. Da hilft nur probieren.

Auf dem Raspi 4 hatte ich es so wie von rell in RE: [VDR*ELEC] - LibreELEC/CoreELEC mit VDR Client vorgeschlagen erfolgreich getestet. Allerdings habe ich das Script in switch_vdr_softhddevice-drm-gles.sh umbenannt und so auch in der .profile hinterlegt.

Zabrimus: Es gibt außer dem Namens des output-Plugins keine Unterschiede im Script. Der amlogic-spezifische Befehl echo 4 > /sys/module/amvdec_h264/parameters/dec_control kann raus, das ist mittlerweile in softhdodroid integriert und wird auch bei jedem ATTA und RESU neu ausgeführt.

Quote from rell

Dr. Seltsam Mit deinen Artefakten komme ich nicht recht weiter. "Im Dunkeln tappen" trifft es...

Da hier im Forum (auch von dir ) aber immer wieder die Frage nach den Umschaltzeiten kommt, habe ich jetzt eine Zeitmessung eingebaut. Start der Messung ist sobald der VDR einen ChannelSwitch initiert - das Plugin reagiert auf cStatus::ChannelSwitch(). Gestoppt wird, sobal das erste Bild auf den Schirm wandert. Zusätzlich wird die Zeitspanne ab dem ersten vom VDR gesendeten Audio- oder Videopaket bis zum Erscheinen auf dem Monitor geloggt. Damit kann man Sender, Einstellungen und Platformen zu vergleichen und muss nicht mehr subjektiv beurteilen.

Außerdem kann man den internen Puffer (aktuell 450ms) per Setup nach oben und unten korrigieren und sich so an den optimalen Wert herantasten. Ich bin mit -135 jetzt mal bei 315ms Puffer und das Umschalten fühlt sich flott an...

Als Info wird im Setup auch der Jitter von Audio und Video angezeigt - einmal als Maximum der letzten 1000 Pakete und einmal als Maximum seit dem letzten Kanalwechsel.

Da das Thema A/V-Sync gerade im vaapivideo Thread diskutiert wird, habe ich in der developer-readme nochmal 3 Diagramme ergänzt, wie der Sync beim Streamstart in softhddevice-drm-gles gehandelt wird. Vielleicht ist das ja für den ein oder anderen wie zork hilfreich...

Danke, so etwas ähnliches hatte jojo61 auch mal als Debug-Code in softhdodroid eingebaut. Man muss im Hinterkopf behalten, dass die Dauer des Umschaltvorgangs stark davon beeinflusst wird, ob man gerade ein i-frame verpasst hat, oder ob dieses zufällig gerade kommt. Ich hatte mal die TS-Streams von Vodafone in avidemux geprüft und festgestellt, dass je nach Sender und Sendung die GOP eine Länge von knapp über 2s haben kann. Die verschiedenen Ausgabeplugins funktionieren ja auch sehr unterschiedlich. Bei softhdodroid werden die Videopakete direkt an den amlogic-Kernel geschickt, der sich um alles weitere selbst kümmert und sogar die Dekodierung der SPS-Daten zur Ermittlung des richtigen Seitenverhältnisses übernimmt. Wir verwerfen das Audio solange, bis Videodaten da sind und die Audio-PTS nicht hinterherhinkt. Die Synchronisation übernimmt dann wiederum der Kernel und blendet das Bild erst ein, wenn A/V synchron sind. Ffmpeg wird nicht benötigt!

Das Problem der Artefakte ist für mich eher nachrangig, da ich den Raspi ja nicht produktiv als VDR nutze. Mein Haupt-VDR ist und bleibt der N2+. Die Tanix TX3 ist im Vergleich zum RPi4 für mich besser als Zweit-VDR geeignet:

• Gehäuse mit Display und IR-Empfänger
• timergesteuertes Aufwachen über RTC

Wer seinen Raspi 24/7 betreibt und einen TV hat, der über CEC auch die Menütaste einbindet, wird beides nicht brauchen.

Wenn Sundtek irgendwann mal den avisierten Protoypen seines DVB-C USB Tuners ausliefert, werde ich den auch nochmal am Raspi testen. Meine positiven Erfahrungen mit dem WinTV dualHD-Stick basieren alle auf dem Einsatz unter Kernel 4.9 (CoreElec). Vielleicht ist da im 6er-Kernel auch was kaputt-optimiert worden.

Quote from rell

Hm, wie du sagtest. Wahrscheinlich irgendwas im kernel oder ffmpeg. Aber warum habe ich das nicht?

weil Du satip nutzt und kein lokales DVB device?

Die Google KI sagt

Quote

RTP (
Real-Time Transport Protocol) überträgt H.264-Video-NAL-Units (Network Abstraction Layer) im RFC 3984-Format, welches keine Startcodes (0x000001 oder 0x00000001) verwendet. Stattdessen werden NALUs direkt in RTP-Pakete verpackt, wobei die Länge der NALU oft aus der RTP-Nutzlast abgeleitet wird.
Wichtige Details:

Kein Startcode: RTP verwendet NAL-Units ohne die Annex-B-Startcodes (0x000001), die man typischerweise in Dateien oder Transportströmen (TS) findet.

Quote

Falls du die Muße hast, ffmpeg nochmal zu bauen, könntest den Wert hier (4) mal weiter hochsetzen. Der Zähler startet bei -15 oder -16 und das sind dann die ominösen 21, die ein decode forcieren. Vielleicht hilft es, auf etwas mehr input zu warten.... Nur ein Schuß ins Blaue.

mit 8 statt 4 tritt es genauso auf, wobei das das Umschalten schon spürbar verlangsamt

Quote

Was du (nur zum Test) auch probieren könntest, wäre hier wie bei Amlogic das flag QUIRK_CODEC_SKIP_FIRST_FRAMES zu aktivieren. Damit wird das erste I-Frame immer verworfen.

ändert auch nix

Beim Log mit der End-Nr. 3 stimmte die gepostete Konfiguration noch nicht.

Anbei ein neues Log. Das Umschalten auf channel 1 hat Artefakte, der Wechsel danach auf channel 1 ist störungsfrei

Quote from rell

Hast du beim Test im Setup Menu das "Drop invalid P-Frames until num I-Frames" gesetzt?

Die beiden Optionen machen folgendes:

"Parse stream until num I-Frames" -> produziert "schöne" Logs aller Frames bis die angegebene Anzahl an I-Frames (+1) beim Streamstart erreicht ist.
"Drop invalid P-Frames until num I-Frames" -> falls ein P-Frame mit einer Rückwärtsreferenz ankommt, die auf ein Frame vor dem ersten I-Frame verweist, wird das P-Frame verworfen. Das wird solange gemacht, bis die hier angegebene Anzahl von I-Frames erreicht ist.

Mit den standard und codec logs sollte man das sehen können.

EDIT: Ziel wäre es, im besten Fall einen Unterschied zwischen Stream-Starts mit und Stream-Starts ohne Artefakte erkennen zu können. Wahrscheinlich ist das ein Irrweg, aber mei...

Das sollte eigentlich passen. Der neue Code prüft auf 0x000001 und 0x00000001. Er gibt aber dem Aufrufer zurück, ob der 3- oder 4-byte lange Startcode gefunden wurde. Damit ist das offset für das nachfolgende Parsen gesetzt. Auf die Startcode-Prüfung folgt immer die Suche nach dem Nal Unit Type. Wird da nicht der gefunden, nach dem gerade gesucht wird, passiert auch nichts. So die Theorie, aber m.E. sollte es passen.

Display More

Ich habe verschiedene Optionen probiert, aber es ändert nichts. Jetzt habe ich mal die SD-Karte mit VDR*ELEC wieder in den Pi gesteckt und das vnsiserver-plugin installiert. Wenn ich jetzt zu Kodi wechsle und dort die Programme durchschalte (also Kodi zur Ausgabe benutze), habe ich im Moment des Umschaltens genau die gleichen Artefakte. Es scheint also irgendeinen Bug im Kernel oder ffmpeg bei der HW-Dekodierung zu geben.

Anbei ein heutiges Log (wieder unter Raspberry Pi OS). Konfiguration:

softhddevice-drm-gles.DecoderNeedsIFrame = 1
softhddevice-drm-gles.DisableDeint = 0
softhddevice-drm-gles.DropInvalidH264PFrames = 1
softhddevice-drm-gles.HideMainMenuEntry = 0
softhddevice-drm-gles.LogLevel = 48
softhddevice-drm-gles.MaxSizeGPUImageCache = 128
softhddevice-drm-gles.ParseH264Dimensions = 1
softhddevice-drm-gles.ParseH264StreamStart = 1

Das Umschalten auf channel 2 und danach auf 3 bringt jeweils Artefakte. Das letzte Umschalten zurück auf channel 2 ist dann ohne Artefakte.

ich bekomme beim make install (als root)

root@CoreELEC ~/vdr/PLUGINS/src/skinflatplus # make install
install -D libvdr-skinflatplus.so /usr/local/lib/vdr/libvdr-skinflatplus.so.11
mkdir -p /var/lib/vdr/themes
cp themes/* /var/lib/vdr/themes
mkdir -p /usr/local/share/vdr/plugins/skinflatplus/icons
cp -r --remove-destination icons/* /usr/local/share/vdr/plugins/skinflatplus/icons
cp: cannot overwrite non-directory '/usr/local/share/vdr/plugins/skinflatplus/icons/MVFog/extraIcons' with directory 'icons/MVFog/extraIcons'
cp: cannot overwrite non-directory '/usr/local/share/vdr/plugins/skinflatplus/icons/MVMint/extraIcons' with directory 'icons/MVMint/extraIcons'
cp: cannot overwrite non-directory '/usr/local/share/vdr/plugins/skinflatplus/icons/MVPumpkin/extraIcons' with directory 'icons/MVPumpkin/extraIcons'
make: *** [Makefile:164: install-icons] Error 1

Liegt es daran, dass es sich z.B. bei "extraIcons" in /usr/local/share/vdr/plugins/skinflatplus/icons/MVFog um einen Symlink handelt, der der in /usr/local/share/vdr/plugins/skinflatplus/icons/MVdefault verweist?

lrwxrwxrwx    1 root     root            23 Oct 13 19:40 extraIcons -> ../MVdefault/extraIcons

Ich musste erst die Symlinks löschen, ehe der cp-Befehl funktionierte

Für TVs und Bluray ist Limited Range der Standard. Full RGB ist für Gaming und angeschlossene PCs - oft wird das am TV für solche Zuspieler eingestellt. Die meisten TVs merken sich das für jeden HDMI-Eingang separat. Man wundert sich dann später, wenn man ein anderes Gerät anschließt, dass es sch... aussieht. Ich glaube, softhddevice hatte standardmäßig Full RGB. Die meisten PC-basierten VDRs dürften deshalb Full RGB ausgegeben haben. Es spricht nichts gegen Limited Range, solange das auf beiden Seiten übereinstimmt.

Quote from rell

Dr. Seltsam Vielleicht hast du ja die Möglichkeit, diesen Branch mal zu testen und mit den neuen Optionen zu spielen und zu versuchen, ein Log zu entlocken... Der versucht sich, deinem Problem zu nähern..

Kompiliert und getestet - leider gleiches Problem. Welche Logs sind wichtig?

Was mir auffällt: Der Sequence Start Code wird durch die byte-Folge 0 0 1 definiert. So prüft es auch jojo61 in softhdodroid:

		while (len--) {
			if (nalHeader[0] == 0 &&
				nalHeader[1] == 0 &&
				nalHeader[2] == 1) {

Die Google KI sagt, dass es auch 4 byte-Startcodes gibt, aber anscheinend kommen die in der Praxis bei DVB nicht vor.

Wenn ich Deinen neuen Code richtig verstehe, prüft Du jetzt zwar beide Varianten (3 und 4 bytes), aber weiterhin nur die letzte Stelle auf 1.
Kann es sein, dass es byte Folgen gibt, bei denen das 3. oder 4. byte zwar eine 1 ist, die aber trotzdem keinen Sequence Start Code darstellen?