lt. Femon-Plugin liefert er derzeit nur AC-3 im Format "3/2 L C R SL SR", also kein mp2
Bleibt bei mir aber auch stumm ....
Der SES UHD Demo Channel hat die gleichen Parameter (kein mp2-Audio, nur AC-3 3/2), ist aber zu hören
Schein also am Sender zu liegen
Nachdem es mit LIRC 0.10.1 im Vergleich zu 0.9.4c leichte Änderungen gab habe ich das LIRC driver Plugin für yaUSBIR angepasst und auch auf github angelegt: https://github.com/FireFlyVDR/lirc-drv-yausbir
yaUSBIR erscheint jetzt auf der Treiberliste:
und mit mode2 kann man alle installierten (und erkannten) yaUSBIR Adapter anzeigen lassen
Wie wär's mit GraphicsMagic ? Das hat im Gegensatz zu ImageMagick ein stabiles Interface und du musst zum Umstellen (fast) nichts umprogrammieren. Das ist mir für skinElchiHD empfohlen worden und mittlerweile nutze ich es hier nur noch (obwohl ich Imagemagick offiziell auch noch unterstütze)
Das sieht nach einem Parser- oder Übertragungsfehler aus. Die ersten drei Nibbles müssten 0xFFF anstatt 0xFEE sein lt. https://en.wikipedia.org/wiki/Elementary_stream
Da sind zwar gaaanz viele Dateien in den tgz aber nicht wirklich relevantes, da in log/messages oder log/vdr so gut wie nichts zu VDR drin steht. Dreh mal den Loglevel hoch: --log=3 wo auch immer das bei MLD gesetzt wird
Evtl. relevant ist das:
Da scheint es Timer zu geben zu denen kein Kanal existiert.
Und wenn du die channels.conf im Editor änderst muss VDR gestoppt sein.
Aber das ist auch interessant:
Werden da Logos und Icons "geschürft" ?!? Jetzt kann man offenbar mit Logos Geld verdienen 
Für openSuse 15.3 und das bald erscheinende 15.4 sind hier zwei Source RPMs zum Selbstkompilieren der Treibermodule.
Zusätzlich zu den saa716x-Modulen wird jetzt das Frontendmodul stv090x mit dem Patch für DVBv5 erzeugt, um korrekte Werte für die Signalstärke und die Carrier-Noise-Ratio CNR anzuzeigen.
Der Transponder 12226 beinhaltet nur SD-Sender, hauptsächlich von RTL Austria. Auffällig ist, dass alle Deine Section Pakete die maximale Länge von 4096 haben (also nicht wirklich "incomplete" sind aber halt die Länge nicht mit der im Paket angegebenen übereinstimmt)
Bild und Ton hast Du aber, oder?
Bei mir treten mit keinem Sender des Transponders Probleme auf weshalb ich da nicht wirklich unterstützen kann.
Aber Du kannst ja zuerst mal den Error Code vom fehlgeschlagenen send section data ausgeben lassen:
Edit: hast Du es mal ohne den Quirk 0x08 probiert? Also mit -s 192.168.xx.xx|DVBS2-3|OctopusNet
Hm, ich denke diese Version vom Patch das lasse ich mal beim Ausgabe-Plugin "Softhddrm" weg
Den Satz verstehe ich nicht .....
Poste doch mal die Zeilen VOR den Fehlermeldungen - die Meldungen sind ja immer die gleichen
Welche VDR-Version und SATIP-Version nutzt Du ? Welchen SATIP-Server?
Die Problem mit dem Ausgabe-Plugin "Softhdrm" kommen von oben aus dem
satip_retune_fix.diff
Probiere doch mal stattdessen den angehängten Patch. Anstatt als Workaround immer neu zu tunen sollte der jetzt die eigentliche Ursache beheben. Außerdem werden nutzlose Requests an den SATIP-Server unterdrückt.
Intensiv getestet habe ich den Patch bisher nicht, also besser noch nicht in Produktivsysteme einspielen 
Interessant, gerade den hätte ich als am wenigsten invasiv eingeschätzt, weil nur ein Retune mehr gemacht wird. Wenn ich die Tage Zeit habe schaue ich noch mal, ob ich etwas finde warum der Vergleich beim Retune fehl schlägt.
Werde ich testen, die Umschaltzeiten sind mir egal, ist ein reiner Backend
... oder im SATIP in tuner.h das ePidUpdateIntervalMs verringern ....
Hm, ich glaube mein Ausgabe -Plugin "softhddrm 3.6" mag diese Patches nicht
das fürchte ich auch ....
Kommt davor wieder das video/cuvid: closing eof ? Lt. Source gibt es die Meldung "failed to send section data" wenn der Socket ein Problem hat, also offenbar nichts mehr angenommen wird.
Getestet habe ich mit VDR 2.6.1 und softhddevice mit VAAPI sowie VDR 2.4.7 und softhddevice mit VDPAU.
Die Meldungen bekomme ich trotz aller 3 Patche auf meinem Test VDR weiterhin.
Ja, wie im ersten Post geschrieben bekommt man die Meldungen damit nicht ganz weg. Man könnte zwar im VDR die FLUSHTIME auf 500ms hoch setzen, dann wäre das Umschalten aber eventuell langsamer. Länger als 500ms sollten die Meldungen aber nicht kommen.
Mit dem angehängten Patch für den VDR (ursprünglich von HelmutB) kannst Du überprüfen wie lange die Meldungen nach dem Umschalten kommen. Bis auf einen falsch konfigurierten Kanal mit TID 2000 sollten alle Meldungen innerhalb 500ms kommen.
Man könnte auch im SATIP-Plugin das ePidUpdateIntervalMs von 250 ms reduzieren wobei dann eventuell der SATIP-Server nicht mehr nachkommt, weshalb ich es bei diesem Kompromiss gelassen habe.
Ja ohne Fehler -- > Das Ausgabe-Plugin ist softhddrm 3.6
Komisch ... und wenn Du den secfilter_fix Patch weglässt?
cinfo : Das sieht eher nach einem Problem des Ausgabe-Plugins aus
May 29 18:46:57 BM2LTS64nDD vdr: video/cuvid: closing eof
May 29 18:47:00 BM2LTS64nDD vdr: [1473] ERROR: 1 ring buffer overflow (752 bytes dropped)
May 29 18:47:06 BM2LTS64nDD vdr: [1473] ERROR: 57 ring buffer overflows (75012 bytes dropped)
der Ringbuffer läuft über weil die Daten nicht schnell genug verarbeitet werden können. Ohne die drei Patches läuft es bei dir?
Was heißt das "closing eof" vom Ausgabeplugin? Das sieht aus als würde das Ausgabedevice geschlossen und dann kommen natürlich Overflows
Nachdem ich mit dem SATIP-Plugin immer wieder mal einen schwarzen Bildschirm oder fehlgeschlagene Aufnahmen hatte, habe ich die Probleme in den letzten Monaten genauer analysiert.
Das erste Problem ("Transfer-Mode kann nicht gestartet werden") war, dass die interne Zuordnung der Receiver im Plugin manchmal fehl schlägt, wenn das interne Attach() des Plugins einen anderen Receiver auswählt als Assign() vorgesehen hat, weil er auf die gleiche Frequenz getuned ist. Das tritt insbesondere bei EPG-Scans auf und den Patch hatte ich schon hier gepostet.
Auch das zweite Problem liefert ab und zu einen schwarzen Bildschirm. Ursache ist, dass offenbar ein Retune ausgelassen wird, obwohl die Streamparameter doch nicht "identical" sind und dann der VDR vergeblich auf die angefragten PIDs wartet. Vermutlich hat sich streamParamM schon geändert bevor es lastParamM zugewiesen wird. Workaround ist immer neu zu tunen, auch wenn die Streamparameter die gleichen sind. Nicht ganz optimal, aber funktioniert.
Irritierend sind dann noch die vielen Meldung der Art "SDT: channel 529 NID/TID (1/1100) not found, got 1/1094". Das rührt daher, dass der Sectionfilter, der sich in gleichen Form auch im Kernel befindet, mehr als die angefragten NID/TID Kombinationen durchlässt. Abhilfe schafft der dritte Patch, der außerdem nur das erste Byte vergleicht anstatt für jedes Paket 18 Bytes, da VDR nur die PID bei der Abfrage mitgibt, die sich im ersten Byte befindet.
Ganz weg bekommt man die Meldungen damit aber nicht, da offenbar nach einem Retune noch alte Pakete im Puffer des SATIP-Servers sind. VDR ignoriert zwar ab 2.6 die Pakete mit den falschen PIDs die ersten 100ms (FLUSHTIME), aber das SATIP-Plugin ändert die PIDs in UpdatePids() frühestens nach 250ms. Auch ein Anhängen von "pids=none" beim Retune des neuen Transponders brachte keine Abhilfe. Bis auf einen (offenbar falsch konfigurierten) Sender kommen die PIDs damit max. 2x 250ms = 500ms lang was tolerierbar ist.
Damit habe ich bisher keinen Fehler mehr gehabt, aber evtl. sollte man es doch erst mal auf einem Testrechner ausprobieren, da die Patches sehr weit eingreifen
Das Problem beim Schneiden ist, dass das Filesystem mit SSD schneller voll läuft als VDR es prüft. Da werden dann schon mal 10 GB in 23 sec kopiert. Mit einer vergleichsweise langsamen HDD gibt es keine Probleme.
Um mal zu diesem Thema zurück zu kommen: wie kann man das lösen? Immer warten mit dem Schneiden bis "vielleicht" die alten Aufnahmen gelöscht sind ist ja keine Lösung zumal laufende Aufnahmen dabei abbrechen können.
Ich mounte die Devices immer über Namen (/dev/sda1 etc.), nie über UUIDs. Von daher sollte es also schon passen.
Aber wer weiß, wo sonst noch UUIDs verwendet werden?
Die UUIDs müssten noch in der grub.cfg stehen und werden von mkinitrd angepast. Ich würde folgendes probieren (habe letztes Jahr damit die Systempartition von Suse 15.x kopiert):
Das Problem beim Schneiden ist, dass das Filesystem mit SSD schneller voll läuft als VDR es prüft. Da werden dann schon mal 10 GB in 23 sec kopiert. Mit einer vergleichsweise langsamen HDD gibt es keine Probleme.
