Sundtek Support Forum

nach längerem Testen und Analysieren bezüglich der Continuity Counter (CC) / TEI-Aussetzer auf bestimmten Transpondern (z. B. Polsat / RTL7) konnte ich das Ursachenmuster nun sehr konkret eingrenzen.


​Erst dachte ich kurzzeitig, dass ein Update (z. B. der Treiber von Januar) das Problem gelöst hatte – das erwies sich jedoch als Trugschluss, da ich zu dem Zeitpunkt schlicht auf Sendern unterwegs war, die entweder aktive Piloten nutzten oder standardmäßig mit Roll-off 0.35 liefen.

​Nach gezielten und systematisierten Tests zeigt sich nun folgendes klares Bild:

​Sender mit Pilot = ON laufen absolut fehlerfrei durch – völlig egal, welcher Roll-off verwendet wird (z. B. BBC Brit mit Roll-off 0.20 + Pilot ON läuft völlig stabil). Die Pilot-Töne scheinen hier als rettender Synchronisations-Anker zu wirken.

​Sender ohne Pilot (Pilot = OFF) laufen ausschließlich dann fehlerfrei, wenn sie einen Roll-off von 0.35 haben (z. B. das ZDF-HD-Paket läuft komplett problemlos).

​Sender mit Pilot = OFF und Roll-off 0.20 (wie Polsat oder RTL7) produzieren hingegen Aussetzer und CC-Fehler.

​Meine Beobachtung & Vermutung:
Es drängt sich der Verdacht auf, dass der Treiber bzw. Demodulator intern starr mit einem Roll-off von 0.35 arbeitet:

​Bei Roll-off 0.35 + Pilot OFF passt es (durch Tests mit ZDF-HD verifiziert).

​Bei Roll-off 0.20 + Pilot ON rettet der Pilot die Synchronisation trotz der falschen Roll-off-Verarbeitung.

​Bei Roll-off 0.20 + Pilot OFF schlägt die Synchronisation unter Last fehl, weil der Roll-off-Faktor falsch interpretiert wird und die Piloten als Korrektur fehlen.

​Zusätzlicher Hinweis: Manuelle Einstellungen in TVHeadend bezüglich des Roll-offs scheinen keinen Effekt zu haben. Selbst wenn man dort etwas falsches erzwingt, laufen funktionierende Sender unbeeindruckt weiter, was vermuten lässt, dass diese Parameter vom Treiber ignoriert werden.

​Kann es sein, dass hier im Treiber/Firmware-Bereich Roll-off 0.20 bei fehlenden Piloten nicht korrekt dynamisch geschaltet wird und hart auf 0.35 zurückfällt?


​Über eine kurze Rückmeldung oder Prüfung dazu würde ich mich sehr freuen!

zu der DLS Thematik: Ich kann, wenn ich manuell tune mittls des mediaclient (wir im Forum hier beschrieben: https://support.sundtek.com/index.php?topic=2115.0) nur Bilder laden. Im Forum steht, dass /opt/bin/mediaclient --getdigitaldata -d /dev/dab0 eine Info zum aktuellen titel liefern soll. das kann ich zur Zeit nicht reproduzieren.

./mediaclient -m DAB -d /dev/dab13 -f 180064000 --sid 0x121b

(DAB13 deshalb, weill der Service gern mal wegfliegt und dann ein neues virtuelles Device erzeugt wird.

Erhalte momentan nur sowas:

DIGITAL DATA SERVICE: 512 -- d0
74 d0 00 08 12 02 7a e1
EXTENSION FLAG: 0
CRC_FLAG: 1
segment flag: 1
user_access_flag: 1
data_group_type: 4
MOT Data 6.1.3 Transport of body segments
continuity_index: d
repetition_index: 0
last segment: 0
segment number: 8
user access field:
length indicator: 2
transport id identifier: 27a
POSITION: 7
repetition count: 7
segment size: 501
--------> 74 d0 00 08 12 02 7a e1 f5 98
DIGITAL DATA SERVICE: 512 -- e0
74 e0 00 09 12 02 7a e1
EXTENSION FLAG: 0
CRC_FLAG: 1
segment flag: 1
user_access_flag: 1
data_group_type: 4
MOT Data 6.1.3 Transport of body segments
continuity_index: e
repetition_index: 0
last segment: 0
segment number: 9
user access field:
length indicator: 2
transport id identifier: 27a
POSITION: 7
repetition count: 7
segment size: 501

Zitat von: Sundtek am Dezember 02, 2025, 06:18:00 Nachmittag

Welchen Sinn macht es DAB in TVHeadend zu integrieren wenn es schon den UPnP Streamingserver gibt mit dem Du DAB/DAB+ bereits jetzt in Kodi integrieren kannst?

Für mich liegt der Sinn darin, dass ich mit TVHeadend nur ein zentrales System für die Bereitstellung von TV und Radio pflegen muss. Und in Kodi liegt der Vorteil darin, dass ich die in TVHeadend konfigurierten Sender-Listen in meiner gewünschten und zentral festgelegten Sortierung direkt verfügbar habe, ohne dies in Kodi noch manuell konfigurieren zu müssen. Und zusätzlich zu meinen DVB-S-Sendern hätte ich dann auch direkt die DAB-Sender dabei, ohne erst noch weitere Systeme wie den Streaming Server einbinden zu müssen. Und ich kann z.B. auch in einem Guss abbilden, dass manche Sender von Satellit und manche von DAB genutzt werden, die aber beide in einer Senderliste vermischt auftauchen können. In TVheadend werden außerdem noch die ganzen Senderlogos zentral verwaltet, welche dann auch direkt in Kodi genutzt werden. Über die o.a. Integration via UPnP musste ich dafür alle Senderlogos manuell in die m3u-Datei des Streaming Servers schreiben und diese Datei stelle ich dann auf einem internen Webserver bereit, d.h. wenn sich im Streaming Server die Senderliste ändert, muss ich auch die m3u-Datei wieder anpassen. Und mir fällt grade noch ein, dass TVHeadend so konfiguriert werden kann, dass regelmäßig nach neuen/geänderten/entfernten Sendern gesucht wird, was für DAB ggf. auch ein sinnvolles Feature wäre. Sicherlich im Ganzen eine spezielle Anforderung.
Ich weiß ehrlich gesagt nicht, ob es überhaupt möglich wäre, die Kernel-Schnittstelle bzw. den Treiber so zu implementieren, dass sich der DAB-Tuner quasi wie ein DVB-S-Tuner verhält und TVHeadend diesen dann ebenso einbinden könnte. Stecke dafür leider viel zu wenig in der Thematik drin. Vielleicht hast Du ja noch Ideen, wie man die Einbindung von DAB-Sendern im obigen Sinne komfortabler realisieren könnte.

Hallo zusammen,

ich habe mich die letzten zwei Tage mit dem Thema DAB-Stick von Sundtek, TVHeadend, Homeassistant auseinander gesetzt und  für mich eine Lösung entwickelt (mit Claude), die sehr verlässlich funktioniert. Ich habe das vorbereitet, um es über GIT zu teilen. Wenn interesse besteht, kann ich das hier im Forum einmal vorstellen..... In dem Zuge kämpfe ich gerade noch damit, dass der mediaclient das DLS nicht sauber dekodiert. Das ist denke ich aber ein Problem des Clients und wird irgendwann wieder aktiviert werden.

Bei interesse gern einmal schreiben, dann kann ich das ja mal teilen.

Gruß Stefan Jasper

Hallo,

ich betreibe einen Dual S2 (Serial: U220618155849, Bus 3-2.3.4.1) an einem
Linux-Host (Kernel 7.0, Docker, linuxserver/tvheadend, Treiber-Build
2026-06-25 04:01:17, gestartet mit
mediasrv -d --wait-for-devices --config=... --pluginpath=...).

Symptom:
Ein mediasrv-Thread läuft dauerhaft auf 100% (1 Kern, Container in
docker stats bei ~101%). Der Zustand ist reproduzierbar und kehrt nach
Neustart nach einiger Zeit zurück.

Analyse mit strace (heißer Thread):

  strace -c -p <TID>  (8 s):
    788584 x poll, 370 x open (Fehler), je 74 x recvfrom/stat (Fehler)

  poll([{fd=1630364978, events=...}, {fd=24, ...}, {fd=23, ...}], 3, -1)
    = 1 ([{fd=1630364978, revents=POLLNVAL}])

~98.000 poll-Calls/s. Der erste FD (1630364978) ist ungültig (echte FDs
gehen nur bis ~29), poll mit Timeout -1 kehrt dadurch sofort mit POLLNVAL
zurück — klassischer Busy-Loop ohne Backoff.

Begleitbefunde:
- /var/log/mediasrv.log: 1123x "TS Sync byte not aligned, realigning
  stream", 91x "There have been 10 ts errors within 1 second", jeweils
  nach "Frontend has locked" -> "Starting transfer".
- /proc/<pid>/fd: ein Handle zeigt auf /dev/sundtek/usb/003/015 (deleted),
  in dmesg USB-Disconnects auf Bus 3/4 sowie
  "usbfs: process mediasrv did not claim interface 0 before use" für
  3-2.3.4.1.
- Tvheadend-Epggrabber tuned beide Tuner laufend durch (alle paar Sekunden
  neuer Mux).

Analyse mit Ghidra (headless):
- Hauptbinary (642 Funktionen): poll wird als roher syscall(7) (= SYS_poll)
  aufgerufen. Heißer Kandidat: net_poll @ 0042fd20 — prüft nach poll nur
  Bits wie POLLIN/POLLHUP, ein POLLNVAL-Handling habe ich im Decompilat
  nicht gefunden; nonzero revents wird als "bereit" gewertet, der Aufrufer
  pollt sofort erneut.
- libdrv_em28xx.so (2409 Funktionen): nur 3 Poll-Stellen (Audio-/DTV-
  Client-Helper mit Timeout 0, accelerated-USB-Loop mit Timeout 10 ms) —
  keine passt zum beobachteten poll(3 FDs, -1).

Bitte:
Könnt ihr prüfen, ob net_poll defekte FDs (CLOSE/use-after-close nach
USB-Reconnect) aus dem Poll-Set entfernen und POLLNVAL/POLLERR mit Backoff
behandeln kann? Aktuell hilft nur ein Neustart von mediasrv (habe ich per
Healthcheck automatisiert). Falls ihr weitere Logs/Befunde braucht (usbmon,
mediaclient --tsscan, Core-Dumps — es liegen auch ältere core.* im
Treiberverzeichnis), liefere ich sie gerne nach.

Danke und viele Grüße!

Hallo Sundtek-Team,

kurze Nachfrage: Kommt hierzu noch eine Rückmeldung, und lässt sich das Problem überhaupt treiber- bzw. firmwareseitig beheben? Eine kurze Zwischeninfo wäre wirklich hilfreich. Falls das Verhalten technisch nicht lösbar ist oder hier nichts mehr passiert, würde ich den Stick gerne zeitnah zurückschicken.

Aktuell läuft bei mir notgedrungen wieder der alte Hauppauge-Stick. Der beherrscht unter Linux zwar kein echtes Standby und lässt den Multischalter dauerhaft an, aber er läuft im laufenden Betrieb zu 100 % stabil ohne Ruckler. Dort bleiben die Zähler (TE und CC) in TVHeadend während des gesamten Schauens dauerhaft auf 0. Dass beim reinen Umschaltvorgang/Einrasten kurz 1 bis 4 Fehler gezählt werden, ist völlig verständlich – aber danach kommt absolut nichts mehr.

Bei eurem Stick habe ich mittlerweile diverse Lösungsansätze durchprobiert:

Hardware-PID-Filterung: Lässt sich bei diesem Modell nicht aktivieren, um den USB-Overhead zu reduzieren und zu testen, ob die Drops dadurch verschwinden.

Isochronous-Modus (ISO): Funktioniert bei diesem Stick ebenfalls nicht, obwohl er als einziges Gerät am Controller hängt (was bei anderen Modellen laut Forum geholfen hat).

Konfigurations-Optionen: Auf die Frage, welche Parameter oder Puffergrößen man in der sundtek.conf für x86_64 noch testen könnte, gab es leider auch keine Rückmeldung.

Aktuell liegt hier ein knapp 100 Euro teurer Stick ungenutzt herum, während das wesentlich günstigere Altgerät im Live-TV fehlerfrei durchläuft.

Könnt ihr mir bitte eine klare Einschätzung geben, ob an dem Problem gearbeitet wird oder wie die Modalitäten für eine Rückgabe aussehen?

Viele Grüße

Michal


Update / Zwischenstand:

Nach unzähligen Tests, stundenlangem Ausprobieren verschiedenster Parameter in der Konfiguration und allen erdenklichen Einstellungen habe ich nun testweise ein Downgrade auf den Treiber vom 24. Januar 2026 (260124.005629) vorgenommen.

Damit verhält sich der Stick bisher exakt so, wie er soll:

Nach 1,5 Stunden Dauerbetrieb: kein einziger Aussetzer mehr.

In TVHeadend bleiben sowohl Transport Errors als auch Continuity Errors dauerhaft auf 0.

Auch der kurze Ruckler wenige Sekunden nach dem Umschalten tritt aktuell nicht mehr auf.

Bevor ich ein endgültiges Fazit ziehe, lasse ich das Setup nun über die nächsten Tage im Dauerbetrieb laufen, um sicherzugehen, dass es wirklich zu 100 % stabil bleibt. Der Hauppauge-Stick hat jedenfalls erst einmal wieder Pause – hoffentlich diesmal dauerhaft.

Ich melde mich nach dem Langzeittest noch einmal mit einem abschließenden Status.


Edit 2:

Nach weiteren intensiven Tests über mehrere Stunden (inklusive gezielter Pausen, damit der Stick komplett in den Standby geht) und echtem Stresstest: Mit dem Treiber von Januar gibt es bis jetzt keine Fehler mehr mitten im Stream.

Selbst beim Umschalten läuft es extrem sauber:

Selbst beim Aufwecken aus dem Standby oder schnellem Hin- und Herschalten (3x Zappen) treten maximal 4 Continuity Errors auf – was beim initialen Synchronisieren/Einrasten des Streams völlig normal ist.

0 Transport Errors.

Sobald der Lock steht, laufen die Streams absolut fehlerfrei durch.

Mit der Januar-Version zeigt der Stick auf einem x64-System endlich wieder, was in ihm steckt – da ist Sundtek wirklich der Ferrari unter Linux. Während der neueste Treiber auf x64 leider massive Probleme bereitet hat, läuft der Stick mit dem Januar-Treiber absolut traumhaft und rock-solid!