dvb-t2 Empfangsprobleme

Zitat von fhg

Gibt es auch etwas empfehlenswertes als PCI-Lösung?

Hatte nicht auch eine PCIe vierfach DVB-C/T Karte, sogar mit Treiber im Kernel?

Beim si2168-Treiber wurde zwar einiges geändert (unter anderem wurde die Funktion zu setzen der Register umbenannt) die für den Empfang relevanten Änderungen scheinen aber recht überschaubar zu sein.

Die ganzen Empfangspatches machen immer nur Änderungen an der zweiten Stelle.

Mal hin, mal zurück, mal in Abhängigkeit von irgendwas.

Nach dem Patch sollte diese Stelle aber funktionell wie 2016 sein, wenn ich nichts übersehen habe.

Zitat von fhg

Ich war schon froh, daß ich einen Treiber nach Anleitung kompilieren konnte (wenn auch erst im 2. Anlauf). Jetzt bin ich aber überfordert.

Also das Kompilieren eines TBS-Treibers ist doch nun wirklich kein Zauberwerk:

• Aktuellen Treiber von hier auf den VDR-Linux-PC runterladen: TBS Open Source Linux Driver Offline Package V20230829
  
• Entpacken und auf der Konsole in das Verzeichnis "media_build" gehen.
• Wenn man im Verzeichnis "media_build" ist, dann einfach ./install.sh eingeben
• Warten bis alles kompiliert ist, dabei werden auch die zugehörigen Firmware-Dateien kopiert und dann 1x reboot machen
• Das wars

Oder so machen wie es in der Readme.txt steht:

make sure that you have installed gcc then use these command

 wget http://www.tbsdtv.com/download/document/linux/media_build-2023-08-29.tar.bz2
 sudo rm -rf /lib/modules/`uname -r`/kernel/drivers/media/
 tar jxvf media_build-2023-08-29.tar.bz2
 cd media_build
 ./install.sh
 reboot

Mehr ist da nicht zu tun.

WICHTIG ist noch, nach einem Kernelupdate muss man den Treiber wieder neu kompilieren.

Dazu nicht das "alte" Verzeichnis "media_build" nehmen, da gibt es meistens Probleme.

Ich habe mir deshalb das Verzeichnis "media_build" an eine anderen Ort als sozusagen "Original" hinkopiert

und kopiere es dann bei Bedarf nach /usr/src/media_build und mache da das ./install.sh

Danach lösche ich dan das Verzeichnis "/usr/src/media_build" (ca. 1,5GB).

Wenn dann das nächste Kernelupdate kommt, dann wird wieder das "Original" dahin kopiert und das Kompilieren kann beginnen.

Das ist eigentlich recht leicht, den Patch wendet man nach dem Runterladen und vor dem Kompilieren an:

[...]
git clone --depth=1 https://github.com/tbsdtv/linux_media.git -b latest ./media


# Patch in dieses Verzeichnis herunter laden. 
cd media
patch -p1 < ../si2168_tbs6205_v1.diff.txt
cd ..


cd media_build
[...]

Alternativ kann man man die Änderungen auch per Hand machen, es sind nicht viel:

diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c
index 9dc02f7c30c4..f134fba9ed55 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -393,15 +393,15 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
         goto err;
 
     /* that has no big effect */
-    //if (c->delivery_system == SYS_DVBT)
-    //    cmd_init(&cmd, "\x89\x21\x06\x11\xff\x98", 6, 3);
-    //else if (c->delivery_system == SYS_DVBC_ANNEX_A)
-    //    cmd_init(&cmd, "\x89\x21\x06\x11\x89\xf0", 6, 3);
-    //else if (c->delivery_system == SYS_DVBT2)
-    //    cmd_init(&cmd, "\x89\x21\x06\x11\x89\x20", 6, 3);
-    //ret = si2168_cmd_execute(client, &cmd);
-    //if (ret)
-    //    goto err;
+    if (c->delivery_system == SYS_DVBT)
+        cmd_init(&cmd, "\x89\x21\x06\x11\xff\x98", 6, 3);
+    else if (c->delivery_system == SYS_DVBC_ANNEX_A)
+        cmd_init(&cmd, "\x89\x21\x06\x11\x89\xf0", 6, 3);
+    else if (c->delivery_system == SYS_DVBT2)
+        cmd_init(&cmd, "\x89\x21\x06\x11\x89\x20", 6, 3);
+    ret = si2168_cmd_execute(client, &cmd);
+    if (ret)
+        goto err;
 
     if (c->delivery_system == SYS_DVBT2) {
         /* select PLP */
@@ -480,9 +480,9 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
         goto err;
 
     cmd_init(&cmd, "\x14\x00\x08\x10\xd7\x05", 6, 4);
-    //cmd.args[5] |= dev->ts_clock_inv ? 0x00 : 0x10;
-    cmd.args[4] = dev->ts_clock_inv ? 0xd7 : 0xcf;
-    cmd.args[5] = dev->ts_clock_inv ? 0x05 : 0x33;
+    cmd.args[5] |= dev->ts_clock_inv ? 0x00 : 0x10;
+//     cmd.args[4] = dev->ts_clock_inv ? 0xd7 : 0xcf;
+//     cmd.args[5] = dev->ts_clock_inv ? 0x05 : 0x33;
     ret = si2168_cmd_execute(client, &cmd);
     if (ret)
         goto err;

Zeilen mit "-" kommen raus, die mit "+" rein.

Zeilennummern stehen zwischen den "@@" und der Dateiname ist ganz oben (das "a" und "b" sind nur Platzhalter für das "media")

In unserem Fall hier müssen aber nur die "//" verändert werden, die aus der Zeile ein Kommentar machen.

Das ist nicht von mir und war so im Code drin!

Die zweite Stelle wurde über die Jahre auch verdächtig oft hin und her geändert:

2015
    memcpy(cmd.args, "\x14\x00\x08\x10\xd7\x05", 6);    0xd7    0x05
    cmd.args[5] |= dev->ts_clock_inv ? 0x00 : 0x10;             0x15
?
    memcpy(cmd.args, "\x14\x00\x08\x10\xcf\x33", 6);    0xcf    0x33
    // ohne!
2017
    memcpy(cmd.args, "\x14\x00\x08\x10\xcf\x33", 6);    0xcf    0x33
    cmd.args[4] = (dev->ts_mode==3)?0xd7:0xcf;          0xd7
    cmd.args[5] = (dev->ts_mode==3)?0x05:0x33;                  0x05
2018
    memcpy(cmd.args, "\x14\x00\x08\x10\xdf\x17", 6);    0xdf    0x17
    cmd.args[4] = dev->ts_clock_inv ? 0xdf : 0xcf;      0xcf
    cmd.args[5] = dev->ts_clock_inv ? 0x17 : 0x33;              0x33
?
    cmd_init(&cmd, "\x14\x00\x08\x10\xd7\x05", 6, 4);   0xd7    0x05
    cmd.args[5] |= dev->ts_clock_inv ? 0x00 : 0x10;             0x15
2020
    cmd_init(&cmd, "\x14\x00\x08\x10\xd7\x05", 6, 4);   0xd7    0x05
    //cmd.args[5] |= dev->ts_clock_inv ? 0x00 : 0x10;
    cmd.args[4] = dev->ts_clock_inv ? 0xd7 : 0xcf;      0xcf
    cmd.args[5] = dev->ts_clock_inv ? 0x05 : 0x33;              0x33

Und das sind nur die Änderungen, die ich beim schnellen durchblättern gesehen habe!

Eine Frage noch:

Wird beim ARD-Transponder ein "lock" angezeigt?

(Beim ZDF müsste das der Fall sein, sonst hätten man kein Signal.)

Zitat von fhg

ZDF bekommt ein "lock", ARD nicht.

Dann müsste es doch schon am Tuner liegen.

Auf die Frage hätte ich früher kommen sollen, das wäre ein anderes IC und anderer Treiber .

Du könntest mal versuchen die Frequenz in mehreren kleinen Schritten etwas höher oder niedriger einzustellen.

Wenn Du Glück hast , kannst Du den Kanal so "fangen".

Eventuell ist irgend was in der Frequenz leicht daneben und die Karte mit dem neuen Treiber da nicht so gutmütig.

Zitat von fhg

OK... jetzt wirds theoretisch, aber müßten dann beim Senderscan nicht schon Abweichungen erkennbar sein? Der scan zeigte jedenfalls immer die gleichen Frequenzen an.

Ich würde es eher praktisches rumprobieren nennen .

Ob der Scan bei DVB-T2 wirklich die Frequenz ermittelt, oder ob die aus einer empfangenen Tabelle kommt, kann ich nicht sagen.

Ich habe nur SAT und noch nie einen Scan gemacht. Da kommen die Transponder-Frequenzen aus dem DVB-Datenstrom und können durchaus etwas daneben liegen.

(Den Fall hatte ich wegen eines defekten LNB selber und es hatten nur einige der Empfänger im Haus Probleme damit.)

Ich habe mir trotzdem noch mal schnell die Änderungen im Tuner-Treiber angesehen (das komplette TBS-git mit 3,8GiB hatte ich ja eh schon runtergeladen) und da hat sich eigentlich nicht viel getan.

Auffällig ist eigentlich nur, dass da ein Timeout für den "lock" eingeführt wurde. Eventuell ist der für deine Empfangsbedingungen/Tunermodell einfach zu knapp bemessen.

Ich habe den man großzügig vergrößert, das könnte noch einen Versuch wert sein.

Zumal die Änderung minimal ist:

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 4217a34d08f5..1b52aa83de32 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -357,9 +357,9 @@ static int si2157_sleep(struct dvb_frontend *fe)
 
 static int si2157_tune_wait(struct i2c_client *client, u8 is_digital)
 {
-#define TUN_TIMEOUT 40
-#define DIG_TIMEOUT 30
-#define ANALOG_TIMEOUT 150
+#define TUN_TIMEOUT 140
+#define DIG_TIMEOUT 130
+#define ANALOG_TIMEOUT 250
     struct si2157_dev *dev = i2c_get_clientdata(client);
     int ret;
     unsigned long timeout;

Einzuspielen ist der Patch genau wie der Letzte.

Hast du mit der WinTV-dualHD nochmal neu gescannt? Das geht ja schnell, siehe #2.

Welche Werte werden dann mit femon angezeigt?

Ist die WinTV schon von isoc auf bulk umgestellt? Hat zwar keine direkten Auswirkungen auf den Empfang, wird für störungsfreien Betrieb aber benötigt.

Funktioniert ARD auch aktuell noch mit Ubuntu 16.04 und alten TBS Treibern?

Wie sieht die Antenne aus? Zimmerantenne? Dach-/Dachbodenantenne? Wird ein Verstärker benutzt? Gibt es eine Antennensteckdose?

Welche Frequenzen gehen, welche nicht?

Höhere Frequenzen unterliegen einer höheren Kabeldämpfung.

Und um auszuschließen, dass das Problem auf der Wiedergabeseite liegt: funktionieren die ARD-Sender mit vlc oder bei vdr mit einem anderen Ausgabeplugin wie softhddevice?

Die Meldung „no data in 8 seconds“ muss m.E. nicht unbedingt auf ein Empfangsproblem hindeuten.

Zitat von fhg

Und jetzt wird's richtig schräg, ich habe die selben Probleme, ZDF funktioniert, ARD nicht.

So schräg auch wieder nicht, wenn das hier stimmt, haben die Karten den selben Tuner .

Bitte aber noch mal hier überprüfen, ob die UDB-ID auch stimmt und es sich wirklich um die Karte handelt:

Wenn bei sudo lsusb -v -d 2040:8265 etwa die gezeigte Ausgabe (Link) kommt, passt es.

Ich vermute, da ist wohl irgendwas im si2168 oder si2157 Treiber "verbessert" worden, was bei deinen Empfangsbedingungen Probleme bereitet

Das blöde ist, dass man um diese ICs (das ist eine ganze Serie), bei DVB-T2 und -C momentan praktisch nicht herum kommt.

Zumindest wissen wir jetzt, dass es nicht auf die eine Karte begrenzt ist.

Sicherheitshalber solltest Du den Kernel (Paket: linux-image-amd64) mal neu installieren, um auszuschliessen, dass der TBS-Treiber da Schaden angerichtet hat.

Du könntest auch mal versuchen, was die WinTV-dualHD unter Ubuntu 16.x macht.

Wenn sie da schon unterstützt wird, würde ich fast wetten, dass sie da auch geht .

Auch den dvblast-Test könnte man noch mal mit der neuen Karte machen, geht ja schnell.

Ich vermute, das wird da genau so aussehen: ZDF verliert den Lock öfters und ARD bekommt ihn nicht mal.

Der Kernel 4.4 von Ubuntu 16.04 ist zu alt für die WinTV dualHD!

Hauppauge WinTV-dualHD - LinuxTVWiki

Zitat

Only the first tuner on Model 01590 device is supported since Kernel 4.7 (see commit https://git.linuxtv.org/media_…d9823f0c45fa476743d9e462b).

Only the first tuner on Model 01595 device is supported since Kernel 4.11 (see commit https://git.kernel.org/pub/scm…53f9a926b2e238d2175b9f5b5).

Both tuners on Model 01590 device and Model 01595 device are supported since Kernel 4.17 (see commit https://git.kernel.org/pub/scm…cbc69f887ca961df5e68cf6f0).

Zitat von fhg

Manchmal erhalte ich nach dem Umschalten das korrekte Bild mit einem kurzen Knacken aus den Lautsprechern, es friert dann aber ein. Vielleicht liegt das Problem doch an anderer Stelle.

Den Verdacht habe ich immer mehr.

Was sagt denn das femon-Plugin, wenn Du auf einen ARD Sender umschaltest?

ok, verstehe. Das hatte ich nicht mehr drauf. Dann liegt das Problem wirklich auf der Empfängerseite. Du schriebst:

Zitat

Alles, was mit ZDF zu tun hat, funktioniert, alles andere nicht.

Deine channels.conf enthält ARD-Sender auf 538 und 746 MHz (NDR) sowie ZDF-Sender auf 586 MHz. Du hast in Deiner Tabelle aber nur ARD und ZDF aufgeführt.

Was mir auffällt ist, dass es laut https://tvhelfer.de/location/76 gar keine Sender auf 746 MHz in Bremerhaven gibt. Das NDR-Paket wird danach auf 546 MHz ausgestrahlt. Das entspricht auch den Angaben des NDR:https://www.ndr.de/der_ndr/emp…tzweidatenblattnds100.pdf

Das erklärt aber nicht, warum Du die ARD-Sender auf 538 MHz nicht reinkriegst. Es sei denn, Du hast die Antenne ganz falsch ausgerichtet und empfängst auf 586 MHz einen ganz anderen Standort, von dem es keinen ARD-Mux auf 538 MHz gibt.

Was ist mit Radio Bremen TV auf 674 MHz? Funktioniert der Sender denn auch nicht?

Könnte es sein, dass dein Ausgabe-Plugin einfach das Videoformat nicht kann?

Nach den bisherigen Informationen sieht es mir eher danach aus, als ob das Frontend den Lock verliert, oder ihn nur sporadisch bekommt.

Im OSD vom femon-Plugin müsste man das aber eigentlich sehen, dass das "Lock"-Feld flackert.

Wenn das der Fall ist, muss man mal überlegen, woran das liegen kann.