dvb-t2 Empfangsprobleme

Ich habe einen meiner 5 WinTV dualHD-Sticks eben mal an meinen DEsktop-Rechner mit Xubuntu 24.04 angeschlossen und DVB-T2 mit vlc ausprobiert. Ich empfange hier in Hamburg sowohl die ARD als auch ZDF-Bouquets. Allerdings musste ich die Firmware nachinstallieren, da Ubuntu sie nicht von Haus aus mitbringt. Ich habe dazu aus dem git von CoreElec alle dvb-demod-si2168*-Dateien genommen und in /lib/firmware gepackt. Je nach Kernelversion und Hardwarerevision werden unterschiedliche Firmwaredateien geladen.

Im mainline-Kernel gab es an den Modulen si2157 (tuner) und si2168 (frontend) m.E. keine Änderungen, die einen kompletten Ausfall einer Sendergruppe erklären können. Da hätte es längst viel mehr Bugreports geben müssen. Wie machen sich denn kommerzielle Fertig-DVB-T2-Empfänger in Deiner Empfangslage? Ist da zumindest evtl. nachvollziehbar, dass das ARD-Paket schwächer reinkommt?

Den USB-Empfänger brauchst Du ja nur abziehen, damit er nicht verwandt wird. Welche Kernelmodule verwendet die TBS? Du müsstest wahrscheinlich nur das Hauptmodul blacklisten.

Die WinTV dualHD wird möglicherweise/vermutlich nicht mit dem von TBS modifizierten Paket laufen!

Da sind ja jetzt die TBS Kernel Treiber installiert. DieTBS6205 und die WinTV-dualHD haben beide den Si2168 Demodulator. Die WinTV-dualHD sollte aber mit dem Original Linux Treiber laufen.

Da müssen mal die DVB Treiber aufgeräumt werden.

Zitat von fhg

Das Lock-Feld flackert nicht.

Evtl. sind die Änderungen einfach zu schnell, dass sie angezeigt werden.

Beim ZDF ist das Feld aber noch immer aktiv und bei der ARD nicht?

Zitat von fhg

Kann ich Die PCI-Karte bzw. die USB-Karte für die wechselnden Tests "abschalten"?

Da die TBS nicht vom Standard-Kernel unterstützt wird, ist es recht einfach:

Installiere einen zweiten Kernel, dann kann man im Bootmenü einfach umschalten. (die USB-Karte kann man ja einfach abziehen)

Die USB-Karte mit einem frischen Kernel zu testen ist sowieso dringend notwendig, um auszuschließen, dass die Fehler von TBS kommen.

Welchen Kernel Du verwendest ist eigentlich egal. Am praktischsten ist einfach eine Sicherheitsaktualisierung (so mache ich das unter Debian auch). Alternativ einen aus den Backports.

Genaue Versionen musste aber jemand empfehlen, der auf Ubuntu arbeitet.

Zitat von fhg

Wenn das Problem tatsächlich mit dem verbauten IC und meiner (warum auch immer) speziellen Konfiguration zu tun hat, was wäre die Lösung?

Den Treiber reparieren. Generell geht die Karte ja.

Mit alternativen Karten sieht es eher schlecht aus, alles von Hauppauge scheint diesen Tuner drauf zu haben.

Wenn die Treiber im mainline-Kernel sein sollen, damit man nicht wieder diese Scherereien beim nächsten Update hat, waren das schon die Alternativen, die mir einfallen.

Zitat von Dr. Seltsam

Je nach Kernelversion und Hardwarerevision werden unterschiedliche Firmwaredateien geladen.

Ich habe nur Abhängigkeiten von der Hardware-Version gesehen.

Die soll bei beiden Karten "B40" und somit identisch sein.

Die Tuner brauchen wohl auch, je nach Version eine Firmware oder nicht.

Die verbaute Version "A30" braucht wohl eine.

Die Definition da ist aber irgendwie merkwürdig, da sind zwei Firmwares "A30" und "A50" angegeben.

Unter Umständen hängt da doch irgendwo das Problem, in dem die falsche Firmware geladen wird.

Stell doch bitte mal den Syslog vom Laden des(der beiden) Treiber hier rein. Die Zeilen mit si2157 und si2168 sollten eigentlich reichen. Da müsste auch irgendwas von der Firmware erwähnt werden.

Man könnte auch mal probieren, die debug-Ausgaben der beiden Module zu aktivieren.

Dann müssten bei jedem Umschalten Angaben zu Frequenz Lockverhelten usw. im Syslog erscheinen.

Ob das Folgende bei Ubuntu schon reicht bin ich aber nicht sicher, evtl. muss man vorher noch was aktivieren.

echo 'file 2157.c +p'>/sys/kernel/debug/dynamic_debug/control
echo 'file 2168.c +p'>/sys/kernel/debug/dynamic_debug/control

Zitat von Dr. Seltsam

Den USB-Empfänger brauchst Du ja nur abziehen, damit er nicht verwandt wird. Welche Kernelmodule verwendet die TBS?

Irgendwas mit "tbs" im Namen, die haben mehrere.

Ich bin jetzt zu faul zum nachschauen, aber lsmod | grep tbs sollte es finden.

Zitat von Dr. Seltsam

Die WinTV dualHD wird möglicherweise/vermutlich nicht mit dem von TBS modifizierten Paket laufen!

Die WinTV sollte mit dem TBS-Paket laufen.

Das ist ein modifiziertes media-build und sollte alles unterstützen, was der entsprechende Kernel (6.5) auch unterstützt.

Ich habe noch ein Bisschen im Log des si2157 Treiber gestöbert und vielleicht was gefunden:

Kürzlich (nach dem Kernel 5.15 von ubuntu 22.04) wurde die Funktion, die die Frimware lädt, komplett umgekrempelt.:

media: si2157: use a different namespace for firmware

Und dabei zumindest ein dicker Bug rein gehauen:

media: si2157: unknown chip version Si2147-A30 ROM 0x50

Die Log-Meldungen vom laden der Treiber wären jetzt wirklich aufschlussreich.

Es wird anscheinend immer versucht eine Firmware zu laden, obwohl der Tuner auch ohne zu funktionieren scheint.

Was aber anscheinend bei einigen Modellen zu Problemen führt:

Zitat

Loading a firmware file should not be mandatory, as devices
could work with an eeprom firmware, if available.

Yet, using the eeprom firmware could lead into unpredictable
results, so the best is to warn about that.

Hi,

Warum testest du nicht mal mit einer Distribution, so wie sie gedacht ist? Also yavdr ansible oder MLD. Ersteres ist wohl sinnvoller.

Ist Ubuntu basiert, nur Server halt.

MfG Stefan

Zitat von fhg

Ich habe noch versucht, direkt über vlc testweise mal ARD oder ZDF zu sehen, aber das funktioniert bei mir beides nicht. Nach Eingaben von : TV-digital, DBV-T2, 538000 oder 586000 kHz unter Aufnahmegerät öffnen, läuft ein gelber Balken unter dem Anzeigefeld hin und her. Ich kann nirgends einen Sender wählen. Da schien ic noch irgend etwas wesentliches zu vergessen.

Ob das so ohne weitere Parameter bei Digital-TV klappt, weiss ich nicht. Ich habe mir dazu eine xspf-Playlist erstellt. Auf

VLC › Wiki › ubuntuusers.de

wird beschrieben, wie man diese oder eine m3u-playlist aus einer channels.conf erstellen kann. Es steht aber nicht dabei, ob es eine channels.conf im vdr-Format ist. Auch ist nicht sicher, ob die Anleitung noch aktuell ist.

Unter Ubuntu 22.04 sollte die WinTV eigentlich laufen.

Zitat von Dr. Seltsam

Ich habe dazu aus dem git von CoreElec alle dvb-demod-si2168*-Dateien genommen und in /lib/firmware gepackt.

Ich würde es mal mit der dvb-tuner-si21* Firmware zusätzlich versuchen.

2016 gab es da noch keine Firmware, eventuell wird mit dem aktuellen Kernel aber benötigt.

Und stell doch bitte endlich mal den syslog vom laden der Treiber rein, damit das Rätselraten aufhört. Man kann einfach nicht effektiv helfen, wenn man nicht weiss, was da passiert.

Einmal von alten Ubuntu 16.04 und dann vom neuen 22.04, dass man einen Vergleich hat.

Die Zeilen mit si2157 und si2168 sollten eigentlich reichen.

Welche Karte ist eigentlich erstmal auch nicht so wichtig, da die Probleme ja beide betreffen.

Dann bitte noch mal Ubuntu 22.04 mit aktivierten Debug-Ausgaben (siehe Beitrag #65).

Da ein paar mal die Kanäle umschalten, um zu sehen, ob da Fehler kommen und wie das Timing aussieht.

Am si2157 Treiber wurde in den letzten Jahren größere Änderungen vorgenommen und das hatte schon mehrfach zu Fehlern geführt.

Auch wurden da die Firmware-Dateien verändert (oder nur umbenannt?):

/* Old firmware namespace */
#define SI2158_A20_FIRMWARE "dvb-tuner-si2158-a20-01.fw"
#define SI2141_A10_FIRMWARE "dvb-tuner-si2141-a10-01.fw"
#define SI2157_A30_FIRMWARE "dvb-tuner-si2157-a30-01.fw"

/* New firmware namespace */
#define SI2141_60_FIRMWARE "dvb_driver_si2141_rom60.fw"
#define SI2141_61_FIRMWARE "dvb_driver_si2141_rom61.fw"
#define SI2146_11_FIRMWARE "dvb_driver_si2146_rom11.fw"
#define SI2147_50_FIRMWARE "dvb_driver_si2147_rom50.fw"
#define SI2148_32_FIRMWARE "dvb_driver_si2148_rom32.fw"
#define SI2148_33_FIRMWARE "dvb_driver_si2148_rom33.fw"
#define SI2157_50_FIRMWARE "dvb_driver_si2157_rom50.fw"
#define SI2158_50_FIRMWARE "dvb_driver_si2178_rom50.fw"
#define SI2158_51_FIRMWARE "dvb_driver_si2158_rom51.fw"
#define SI2177_50_FIRMWARE "dvb_driver_si2177_rom50.fw"

Die Firmware bei CoreElec scheint also noch die "alte" zu sein.

Die neuen Dateien konnte ich bislang aber nirgends finden.

Die Firmware Dateien bei CoreElec wurde aber inzwischen mehrfach geupdated.

Man könnte es auch mal mit einem älteren Stand , zB. von 2016, versuchen.

Zitat von fhg

Mache ich doch, ich muß das alles doch erst lernen :-). Ich hänge die Dateien hier ran.

Es ist natürlich kein Problem, wenn es nicht sofort klappt oder noch Fragen bestehen, bitte nicht falsch verstehen.

Ohne Logfile ist es halt nur extrem frustrierend, weil man nicht mal sicher weiss, ob es sich wirklich um die vermutete Hardware handelt. (Die Infos im Netz sind gelegentlich veraltet oder einfach falsch.)

Die Anhänge sind übrigens sehr Aufschlussreich, danke!

Es handelt sich, wie vermutet, wirklich um den selben Tuner/Demodulator auf beiden Karten.

Und zwar wirklich 100% identisch inklusive Rom- und Firmware-Versionen.

Auch scheint die Version der Demodulator-Firmware ebenso identisch zu sein B 4.0.2 ohne -> B 4.0.25 nach Firmware download.

Das Laden der Tuner-Firmware ändert die angezeigte Version nicht, was mich etwas wundert. Entweder die Firmware ist mit der im Rom identisch, oder das laden geht schief.

Zumindest wundert mich jetzt endgültig nicht mehr dass die beiden Karten die gleichen Empfangsprobleme zeigen.

Das Problem müsste demnach also wirklich in einem der beiden Treiber liegen.

Da der Lock ausbleibt, würde ich auf den Tuner si2157 tippen.

Wo dieses ???/dynamic_debug/control liegt, scheint unterschiedlich zu sein.

Bei meinem Debian geht jedenfalls das Folgende: cat /proc/dynamic_debug/control | grep dvb

(Es könnte auch /sys/dynamic_debug/control sein.)

Da kommt dann eine lange Liste, unter anderem:

...
dvb_frontend.c:2451 [dvb_core]dvb_frontend_handle_ioctl =p "%s: properties.props = %p\012"
dvb_frontend.c:2449 [dvb_core]dvb_frontend_handle_ioctl =p "%s: properties.num = %d\012"
dvb_frontend.c:2442 [dvb_core]dvb_frontend_handle_ioctl =p "%s:\012"
dvb_frontend.c:2373 [dvb_core]dvb_get_property =p "%s: properties.props = %p\012"
dvb_frontend.c:2371 [dvb_core]dvb_get_property =p "%s: properties.num = %d\012"
dvb_frontend.c:2076 [dvb_core]dvb_frontend_do_ioctl =p "%s: (%d)\012"
...

Ich habe jetzt einfach mal das Debug für dvb_frontend.c komplett aktiviert:

echo 'file dvb_frontend.c +p' | sudo tee /sys/kernel/debug/dynamic_debug/control

(Man braucht dazu root rechte, zum lesen nicht.)

Sobald man den VDR startet quillt der Syslog dann mit derartigen Meldungen über:

...
av7110 0000:05:01.0: dvb_frontend_do_ioctl: (69)
av7110 0000:05:01.0: dvb_frontend_handle_ioctl:
av7110 0000:05:01.0: dvb_frontend_do_ioctl: (69)
av7110 0000:05:01.0: dvb_frontend_handle_ioctl:
av7110 0000:05:01.0: dvb_frontend_do_ioctl: (69)
av7110 0000:05:01.0: dvb_frontend_handle_ioctl:
av7110 0000:05:01.0: dvb_frontend_do_ioctl: (69)
av7110 0000:05:01.0: dvb_frontend_handle_ioctl:
av7110 0000:05:01.0: dvb_frontend_swzigzag_update_delay:
av7110 0000:05:01.0: dvb_frontend_swzigzag_autotune: drift:3436 inversion:0 auto_step:2 auto_sub_step:0 started
...

Hier alle Meldungen zu aktivieren ist also keine so gute Idee gewesen, aber das war ja erstmal nur ein Test.

(Mein Tuner/Demod hat dieses Interface nicht, daher kann ich es da nicht probieren.)

Man kann line 123-456 auch nur Bereiche aktivieren. Da schaue ich die Tage mal.

Eigentlich sollte das so auch mit 2157.c und 2168.c gehen.

si2157 hat auch einen Parameter:

parm:           tuner_lock_debug:if set, signal lock is briefly waited on after setting params (int)

Damit der beim Laden berücksichtigt wird, müsste man in /etc/modprobe.d/ eine Datei anlegen, z.B. si2157.conf mit dem Inhalt

options si2157 tuner_lock_debug=1

vielleicht hilft das?

Zitat von Dr. Seltsam

si2157 hat auch einen Parameter

Danke für den Hinweis, das hatte ich glatt vergessen zu erwähnen.

Das zu Aktivieren ist wichtig. Dann sollte man Informationen bekommen, wie lange das tunen gedauert hat und die Zeit bis zum "lock". Allerdings nur, wenn vorher die Debug-Meldungen aktiviert wurden.

Wenn der Tuner Schwierigkeiten auf einigen Kanälen hat, sollte man da eigentlich was sehen.

Zitat von fhg

Anbei hänge ich auch das auf "vdr:" gefilterte syslog mit einigen Umschaltversuchen an.

das hilft nicht weiter. Wir wollen ja die Kernel-Meldungen des Treibers sehen.Lieber einmal ein komplettes Syslog vom fehlgeschlagenen Umschaltvorgang. Eventuell können wird das dann später mit einem anderen grep-Begriff eingrenzen.

Zitat von fhg

Ich nehme an, hierdurch werden die 2 Zeilen an die Datei .../control angehängt.

Fast.

Die "Datei" ist keine echte Datei, sondern eine Schnittstelle zum Kernel und da schreibst Du die 2 Zeilen rein.

(Unter UNIX/Linux ist quasi alles wie eine Datei anzusprechen!)

Zitat von fhg

Reicht das schon, um debug-Meldungenanzuzeigen? Und dadurch wird das Log ausführlicher?

Ja und Ja.

Wenn es klappt, sollten im Syslog ein Haufen Meldungen mit si2157 und si2168 kommen.

Das müsste so viel sein, das kann man eigentlich nicht übersehen.

Ich sehe aber gerade, dass das "si" im Dateinamen irgendwie verschwunden sind.

Korrekt müsste es so lauten:

echo 'si2157.c +p' | sudo tee /proc/dynamic_debug/control
echo 'si2168.c +p' | sudo tee /proc/dynamic_debug/control

(Das sudo wird benötigt, da nur root Schreibrechte auf die "Datei" hat.)

Es könnte (je nach Kernelversion ???) auch dort liegen:

/sys/kernel/debug/dynamic_debug/control

Die "Datei" muss schon vorhanden sein, sonst klappt es nicht!

Überprüfen kann man das mit:

sudo ls /proc/dynamic_debug/
sudo ls /sys/kernel/debug/dynamic_debug/

Wenn da "control" angezeigt wird, sollte es gehen.

Falls was beim Reinschreiben schief geht, Dateinamen unbekannt usw. sollte es auch eine Fehlermeldung geben.

Zitat von fhg

Das ist dann nach jedem Neustart durchzuführen?

Nein, nach einem Neustart ist die Einstellung wieder weg!

Zitat von fhg

Anbei hänge ich auch das auf "vdr:" gefilterte syslog mit einigen Umschaltversuchen an.

frontend 1/0 timed out while tuning to channel 13 (Das Erste HD), tp 538

Eigentlich nicht viel neues, aber der VDR ist der gleichen Meinung wie dvblast .

Zitat von fhg

Das Syslog ist allerdings jetzt gigantisch und wächst auch ohne daß irgendetwas am Rechner gemacht wird permanent an.

Gratuliere!

Ich sagte doch, das ist nicht zu übersehen .

Man kann auch weniger von den Meldungen aktivieren, das müsste ich mir aber auch erst mal ansehen.

Zitat von fhg

Ich hänge einen Ausschnitt des Logs an, in dem ich vom funktionierenden ZDF auf Das Erste umgeschaltet habe.

Das sieht auf den ersten Blick auch hervorragend aus. Da müsste alles nötige drin sein.

Wenn ich es schaffe schaue ich mir das heute Abend noch mal genau an.

Bei der Menge an Information dauert das etwas.

Also, die Masse an Meldungen scheint zumindest teilweise daher zu rühren, dass dauernd versucht wird den ARD-Transponder neu zu tunen.

Man sieht eigentlich recht schön, was da passiert. Die einzelnen Tuner/Frontends kann man anhand der Ziffer (Busadresse) nach dem si21.. unterscheiden, wobei immer ein Tuner und ein Frontend fest zusammen gehören. Tuner 12 gehört zu Frontend 10, zw.B 11 zu 8.

Das Tunen läuft immer wie folgt ab und ist anscheinend auch erfolgreich:

si2168 8-0064: delivery_system=16 modulation=0 frequency=538000000 bandwidth_hz=8000000 symbol_rate=0 inversion=0 stream_id=1
si2157 11-0060: delivery_system=16 frequency=538000000 bandwidth_hz=8000000
[...]
si2157 11-0060: tuning took 24 ms, status=0x85
si2157 11-0060: tuning+lock took 24 ms, status=0x85

In der ersten Zeile bekommt das Frontend den Tuning-Befehl.

In der Zweiten wird das notwendige an den eigentlichen Tuner weitergeleitet.

Der tunt dann die Frequenz und bekommt auch sofort einen lock.

Das sieht für mich auch soweit alles korrekt aus. delivery_system=16 steht für DVB-T2 und frequency und bandwidth_hz passen.

Auch geht das tunen schnell und die Zeiten sind recht konstant 20-28ms. Das spricht dafür, dass der Tuner mit dem Signal keine Probleme hat.

Jetzt zum Frontend(Demodulator):

Bei der 0 bei modulation und symbol_rate muss ich noch mal nach schauen, AFAIK steht 0 aber meist für auto.

Bei der inversion wird sowohl 0 als auch 1 probiert, das ist auch normal, falls das tunen mit 0 scheitert.

Und das tut es anscheinend auf Ebene des Demodulators:

si2168 8-0064: si2168_ts_bus_ctrl acquire: 1 
[...] 
si2168 8-0064: status=00 args=80 00 08 dc 00 00 42 ff 43 1b 00 00 01 01

Die erste Meldung kommt nach dem der Demod nach dem Tunen aktiviert wurde.

Die mit status, wenn der Zustand des Demod. abgefragt wird. (0b das jetzt durch den VDR oder DVB-core passiert, bin ich momentan nicht sicher, das ist aber erstmal egal.)

Die Werte, die status haben kann, sind hier definiert: frontend.h

Wobei der si2168 nur 3 Werte kann:

00 -> kein Signal

03 -> Signal aber kein Lock

1f -> Signal und Lock

Und die Werte werden vom Frontend/Demod si2168 geholt, nicht vom Tuner.

Der Fehler müsste also doch im si2168-Treiber liegen.

Nach dem Tunen fängt es immer mit 00 an und springt dann gleich auf 03.

Es entspricht also genau den, was der VDR/femon anzeigt.

Da der Lock ausbleibt, wird dann (von irgendwo her) ein erneutes tunen des Kanals angestoßen und der Vorgang wiederholt sich.

Das geht auch recht schnell, bis das passiert, nicht mal eine Sekunde wird gewartet. Das Problem könnte also der Timeout irgendwo anders (vermutlich dvb-core) sein.

Weiter oben im Log sind noch Meldungen mit status 1f. Die kommen immer von einem Frontend, dass muss da erfolgreich auf einem anderen Kanal getunt haben.

Da wäre es hilfreich mal den Log vom erfolgreichen tunen des ARD-Transponders mit dem alten Treiber/Karte zu sehen. (Aktivieren der Log-Funktionen sollte auch da genau so funktionieren.)