Sundtek SkyTV eLight – Sporadische Continuity Errors und Transport Errors

[Micha_123]

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.

[Sundtek]

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)

[Micha_123]

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

[Sundtek]

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.

[Micha_123]

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.

[Micha_123]

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

[Micha_123]

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:

Code: [Auswählen]

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