SATIP-Plugin Patches

  • 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 ;)

  • Es wäre cool, dieses Problem endlich zu fixen.

    Dann könnte man das in einen Fork integrieren, den jeder nutzen kann oder den jemand als binary zur Verfügung stellen kann.



    Aber wie sollen andere so tiefgreifende Patche verstehen, ohne das ganze Plugin erneut zu debuggen?

    Patche sollten im Idealfall eine Zeile ändern und dazu erklären, was und wie exakt geändert wird. Für jede einzelne Änderung.


    Schade um die viele Arbeit, die du investiert hast. :-/

  • Wegen: Viel Spaß damit mit rofafor.

  • Hm,


    so leider hier nicht verwendbar


    damit kann hier leider noch nicht sauber durch den VDR geschaltet werden . Das Ergebnis ist der VDR bleibt mit ein ring buffer overflows

    hängen.

    (VDR) NUC11PAHi5 * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2021)* (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65GX9LA

  • 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

  • Ohne die drei Patches läuft es bei dir?

    Ja ohne Fehler -- > Das Ausgabe-Plugin ist softhddrm 3.6


    Grüße

    cinfo

    (VDR) NUC11PAHi5 * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2021)* (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65GX9LA

  • Komisch ... und wenn Du den secfilter_fix Patch weglässt?

    werde ich morgen mal testen.

    (VDR) NUC11PAHi5 * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2021)* (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65GX9LA

  • Irritierend sind dann noch die vielen Meldung der Art "SDT: channel 529 NID/TID (1/1100) not found, got 1/1094".

    Die Meldungen bekomme ich trotz aller 3 Patche auf meinem Test VDR weiterhin.


    Code
    1. May 30 14:00:17 user.debug VDR-2204-Dev vdr: [280] SDT: channel 276 NID/TID (133/11) not found, got 133/12
    2. May 30 14:06:00 user.debug VDR-2204-Dev vdr: [280] SDT: channel 159 NID/TID (1/1020) not found, got 1/1012
    3. May 30 14:06:42 user.debug VDR-2204-Dev vdr: [280] SDT: channel 305 NID/TID (1/1030) not found, got 1/1026
    4. May 30 14:08:08 user.debug VDR-2204-Dev vdr: [280] SDT: channel 29 NID/TID (1/1078) not found, got 1/1074
    5. May 30 14:08:51 user.debug VDR-2204-Dev vdr: [283] SDT: channel 0 NID/TID (1/1088) not found, got 1/1084
    6. May 30 14:15:16 user.debug VDR-2204-Dev vdr: [280] SDT: channel 56 NID/TID (1/1015) not found, got 1/1011
    7. May 30 14:21:20 user.debug VDR-2204-Dev vdr: [280] SDT: channel 0 NID/TID (53/1119) not found, got 1/1115
    8. May 30 14:23:06 user.debug VDR-2204-Dev vdr: [280] SDT: channel 148 NID/TID (1/1038) not found, got 1/1064
    9. May 30 14:23:28 user.debug VDR-2204-Dev vdr: [283] SDT: channel 280 NID/TID (1/1044) not found, got 1/1040
    10. May 30 14:24:54 user.debug VDR-2204-Dev vdr: [283] SDT: channel 346 NID/TID (1/1016) not found, got 1/1010
    VDR
  • 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.

  • Komisch ... und wenn Du den secfilter_fix Patch weglässt?

    werde ich morgen mal testen.

    Hm, ich glaube mein Ausgabe -Plugin "softhddrm 3.6" mag diese Patches nicht


    (VDR) NUC11PAHi5 * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2021)* (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65GX9LA

  • Länger als 500ms sollten die Meldungen aber nicht kommen.

    Kann ich bestätigen, höchster Wert bei einem kurzen Test war 404ms.


    Man könnte zwar im VDR die FLUSHTIME auf 500ms hoch setzen, dann wäre das Umschalten aber eventuell langsamer

    Werde ich testen, die Umschaltzeiten sind mir egal, ist ein reiner Backend.

    VDR
  • 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.

  • .. oder im SATIP in tuner.h das ePidUpdateIntervalMs verringern ....

    Da scheint mir das Risiko von Folgeprobleme großer zu sein.

    Mit "define FLUSH_TIME 500" seit einer Stunde keine Meldung mehr, sonst alle paar Minuten.

    Passt für mich so, danke für den Tipp.

    VDR