Posts by FireFly

    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:

    Code
    1. #> lirc-lsplugins
    2. # Driver Flags Plugin
    3. ....
    4. ya_usbir -asL /usr/lib64/lirc/plugins/ya_usbir.so
    5. ...

    und mit mode2 kann man alle installierten (und erkannten) yaUSBIR Adapter anzeigen lassen


    Code
    1. #> mode2 --list-devices
    2. /dev/bus/usb/001/002 [10c4:876c] UG Development Lab yaUsbIR V3:IR transceiver with power switch version: 1.10 serial: XXXX

    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:

    Code
    1. Jun 2 11:39:49 MLD-rpi4 user.err vdr: [7902] ERROR: channel C-133-3-8 not defined
    2. Jun 2 11:39:49 MLD-rpi4 user.err vdr: [7902] ERROR: error in /etc/vdr/timers.conf, line 53
    3. Jun 2 11:39:49 MLD-rpi4 user.err vdr: [7902] ERROR: channel C-133-2-22 not defined
    4. Jun 2 11:39:49 MLD-rpi4 user.err vdr: [7902] ERROR: error in /etc/vdr/timers.conf, line 54
    5. Jun 2 11:39:50 MLD-rpi4 user.err vdr: [7902] ERROR: source base /media/dvd not found

    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:

    Code
    1. Jun 2 11:39:50 MLD-rpi4 user.err vdr: [7902] tvguide: Osd Icon Cash created in 383 ms
    2. Jun 2 11:39:51 MLD-rpi4 user.err vdr: [7902] tvguide: Grid Icon Cash created in 152 ms
    3. Jun 2 11:39:51 MLD-rpi4 user.err vdr: [7902] tvguide: Channelgroup Cash created in 147 ms
    4. Jun 2 11:39:54 MLD-rpi4 user.err vdr: [7902] tvguide: Logo Cash created in 3533 ms

    Werden da Logos und Icons "geschürft" ?!? Jetzt kann man offenbar mit Logos Geld verdienen :wow:D

    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.

    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.

    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):

    • von einem USB-Stick (oder andere Suse-Partition) booten
    • mount destination partition, e.g. to /mnt
    • mount -B /sys /mnt/sys
    • mount -B /dev /mnt/dev
    • mount -B /run /mnt/run
    • mount -B /proc /mnt/proc
    • chroot /mnt
    • mkinitrd (creates also changed grub.cfg with new UUID)
    • exit