Neueste Beiträge

Seiten: 1 [2] 3 4 ... 10
11
Treiber / mediasrv 100% CPU: poll-Busy-Loop mit POLLNVAL (net_poll) nach USB-Device-Verlus
« Letzter Beitrag von DocMAX am September 20, 2026, 10:02:43 Vormittag »
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!
12
{Single, Dual, Quad} Sundtek SkyTV Ultimate / Re: Kein Datenstrom trotz erfolgreichem Lock beim Tunen
« Letzter Beitrag von sammsoft am September 20, 2026, 07:42:34 Vormittag »
habe ein Austausch Gerät bekommen. dieses funktioniert!
13
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!
14
Hallo,

ich habe nun einen weiteren Testlauf durchgeführt und die entstandene TS-Aufnahme direkt auf Paket-Ebene analysiert.

Während der Aufnahme hat TVHeadend exakt 3 Transport Errors und 3 Continuity Errors registriert. Parallel dazu lief die Signalüberwachung per mediaclient --readsignal mit (neues Logfile hängt an).

Um TVHeadend als Fehlerquelle auszuschließen, wurden die 188-Byte-Paketheader der Datei direkt per Python-Skript geprüft:

import sys
fn = "/opt/test.ts"
cc_map, tei_cnt, cc_err, total = {}, 0, 0, 0
with open(fn, "rb") as f:
    while True:
        p = f.read(188)
        if len(p) < 188: break
        if p[0] != 0x47: continue
        total += 1
        tei = (p[1] & 0x80) >> 7
        pid = ((p[1] & 0x1F) << 8) | p[2]
        afc = (p[3] & 0x30) >> 4
        cc = p[3] & 0x0F
        if tei: tei_cnt += 1
        if pid != 0x1FFF and afc in (1, 3):
            if pid in cc_map and cc != ((cc_map[pid] + 1) & 0x0F) and cc != cc_map[pid]:
                cc_err += 1
            cc_map[pid] = cc
print(f"Analysierte Pakete : {total}")
print(f"Transport Errors   : {tei_cnt}")
print(f"Continuity Errors  : {cc_err}")

Ergebnis:
Analysierte Pakete : 1332790
Transport Errors   : 3
Continuity Errors  : 3

Das Ergebnis matcht exakt die Zähler von TVHeadend.

die Aufnahme wurde mittels

LD_PRELOAD=/opt/lib/libmediaclient.so cat /dev/dvb/adapter0/dvr0 > /opt/test.ts

angefertigt
15
Hallo,

ich habe nun einen Testlauf durchgeführt: Eine Aufnahme über TVHeadend gestartet und parallel dazu das Signal-Log per mediaclient --readsignal mitschreiben lassen (Datei anbei).

Die Beobachtung während des Tests:

Signal-Log unauffällig. Durchgehend BER: 0, stabiler Lock und SNR von 14–15 dB. (Hinweis: Das Log lief nach Beenden der Aufnahme noch eine kurze Weile weiter).

TVHeadend-Zähler: Hat exakt während dieses Log-Fensters angeschlagen und genau 2 Transport Errors sowie 6 Continuity Errors gezählt.

Ergebnis: Die in TVHeadend erstellte TS-Aufnahme weist an den entsprechenden Stellen sichtbare Aussetzer auf.


Als Nächstes werde ich noch den Rohabgriff direkt an TVHeadend vorbei testen:

LD_PRELOAD=/opt/lib/libmediaclient.so cat /dev/dvb/adapter0/dvr0 > /opt/test.ts

Habt ihr vorab bereits Hinweise oder Parameter für die /etc/sundtek.conf (z. B. Puffergrößen für den Demuxer/Transfer), um solche sporadischen USB-Drops auf einem Linux x86-System gezielt abzufangen?

Viele Grüße

Michal
16
Hallo,

ich habe den Test über /dev/dvb/adapter0/dvr0 vorhin von der Arbeit aus über VPN gestartet. Während dieses kürzeren Testfensters lief der Stream – wie es bei sporadischen Fehlern oft der Fall ist – fehlerfrei durch.

Das typische Verhalten bei mir: Es kann nach dem Start eine Weile dauern, bis die ersten Aussetzer auftreten. Sobald es jedoch anfängt, wiederholen sich die Continuity Errors (jeweils 1–2 verworfene TS-Pakete) relativ verlässlich etwa alle 10 Minuten – und das transponderübergreifend bei konstant perfektem Signal (SNR 16 dB, BER 0).

Ich werde heute Abend zu Hause einen längeren Testlauf ansetzen, um das System über eine längere Zeitspanne zu beobachten und den Fehler gezielt in der Aufnahme abzufangen.
17
Kannst Du readsignal mal so lange laufen lassen bis der Fehler auftritt.

1. Schalte einen Sender ein
2. öffne ein Terminal und nimm den Sender auf
cat /dev/dvb/adapter0/dvr0 > $HOME/test.ts
3. öffne ein weiteres Terminal und lass den readsignal Befehl laufen.
4. Beobachte wann das Problem auftritt und stoppe dann die cat Aufnahme, versuche diese dann mit mplayer abzuspielen und schau ob das Problem dort auch vorhanden ist.
18
beim SkyTV eLight handelt es sich um einen reinen Single-Tuner; unter /dev/dvb/ ist entsprechend nur adapter0 vorhanden.
Das Problem mit den sporadischen Continuity Errors ist zudem nicht auf einen bestimmten Transponder beschränkt, sondern tritt transponderübergreifend auf allen Frequenzen/Sendern auf.
Hier ist beispielhaft die Ausgabe von readsignal während des laufenden Betriebs (auf 11.508 V):


SIGNAL: [.............................    ] ( 88%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 87%) SATQUALITY:  88%  SNR:  16  BER:      0 FREQ: 11508000   Hz LOCKED: YES SYS: DVB-S2 SYM: 27500000 FEC: FEC_3_4 MOD: PSK_8 VOLTAGE: V(13V)




Vielen Dank
19
Hallo,

Hast Du beide Adapter getestet?

was zeigt denn folgender Befehl an, wenn der Betroffene Sender auf Adapter0 empfangen wird?
/opt/bin/mediaclient --readsignal=0 --band=universal -d /dev/dvb/adapter0/frontend0

(eventuell auch adapter1 testen)
20
allo Sundtek-Team,

ich nutze einen Sundtek SkyTV eLight (DVB-S/S2, Serial: U260809161412) an einem x86_64-System unter Linux mit TVHeadend.

Leider treten im laufenden TV-Betrieb alle paar Minuten sporadisch Continuity Errors (1-2 Pakete) und vereinzelt Transport Errors auf.

Um alle externen Fehlerquellen absolut sicher auszuschließen, habe ich folgende Tests durchgeführt:

Empfangsanlage gegengetestet: Eine Dreambox DM920 am exakt selben Sat-Kabel / Spaun-Multischalter empfängt dieselben Transponder (z. B. 11.508 V und 12.264 V) über 10 Minuten mit über 2,1 Millionen Paketen zu 100 % fehlerfrei (0 TE, 0 CC, 0 BER bei 13,8 dB SNR). Schüssel und Multischalter sind also nachweislich absolut perfekt.

Masse / Potenzial: Der F-Stecker am Sundtek-Stick wurde zusätzlich direkt geerdet, um Potenzialunterschiede zwischen Schaltnetzteil und Multischalter auszuschließen.

USB-Ports & Energiesparen: Sowohl an nativen USB 2.0 als auch an USB 3.0 Ports getestet. autosuspend steht auf -1, power/control steht fest auf on.

System-Priorität: mediasrv und tvheadend wurden per chrt -r -p 50 in die Linux-Echtzeit-Klasse (SCHED_RR) gehoben. Die CPU-Auslastung liegt unter 6 %.

Ein früher genutzter Hauppauge-Stick hatte an demselben System keinerlei Continuity Errors.


root@Router:/tmp/home/root# uname -a
Linux Router 6.12.94 #1 SMP PREEMPT_DYNAMIC Fri Jul 10 16:36:11 UTC 2026 x86_64 GNU/Linux

root@Router:/tmp/home/root# lsusb -t
unable to initialize usb spec/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/9p, 480M
    |__ Port 004: Dev 005, If 0, Class=[unknown], Driver=usbfs, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/7p, 5000M

Auch wenn es nur einzelne Fehler sind, macht sich das leider durch Mikro-Ruckler in Aufnahmen sowie im Live-TV bemerkbar.


Seiten: 1 [2] 3 4 ... 10