dvb-t2 Empfangsprobleme

Bis der Lock auf dem ARD-Transponder kommt, dauert es wirklich etwas:

09:28:47 : [ 4224.880807] si2168 4-0064: delivery_system=16 modulation=0 frequency=538000000 bandwidth_hz=8000000 symbol_rate=0 inversion=0 stream_id=0
09:28:47 : [ 4224.880809] si2157 9-0060: delivery_system=16 frequency=538000000 bandwidth_hz=8000000
09:28:47 : [ 4224.914882] si2168 4-0064: si2168_ts_bus_ctrl acquire: 1
09:28:47 : [ 4224.993975] si2168 4-0064: status=00
09:28:47 : [ 4225.107202] si2168 4-0064: status=00
09:28:47 : [ 4225.220374] si2168 4-0064: status=03
09:28:48 : [ 4225.333538] si2168 4-0064: status=03
09:28:48 : [ 4225.446713] si2168 4-0064: status=1f
09:28:48 : [ 4225.564216] si2168 4-0064: status=1f
09:28:48 : [ 4225.843202] si2168 4-0064: status=1f

4225,446713 − 4224,880807 = 0,565906s

Da zwischen den Tunig-Versuchen aber etwa eine Sekunde vergeht, sollte das trotzdem passen.

Der einzige wirklich auffällige Unterschied ist, dass bei altern Treiber stream_id=0 ist und bei Neuen stream_id=1.

Das macht jedenfalls eine Änderung in der Konfiguration den ICs aus.

Mit falsch gesetzter stream_id wird man jedenfalls wohl keinen Empfang auf dem Kanal haben. Ob das auch verhindern kann, dass ein Lock kommt, bin ich nicht sicher. Möglich wäre es aber zumindest.

Ich würde mal versuchen die stream_id auf 0 zu setzen. Das müsste eigentlich im Channels-Menü vom VDR gehen. (Ich kann das leider nicht probieren, ich habe hier nur SAT.)

Und dann mal schauen, ob das auch im Logfile ankommt.

Irgendwie ist das Ganze mit der stream_id sowieso etwas merkwürdig, zumal sie in dem channels.conf gar nicht gesetzt wurde.

Aber vielleicht weiß da einer der DVB-T-Experten mehr?

Quote from SHF

Ich würde mal versuchen die stream_id auf 0 zu setzen. Das müsste eigentlich im Channels-Menü vom VDR gehen. (Ich kann das leider nicht probieren, ich habe hier nur SAT.)

Und dann mal schauen, ob das auch im Logfile ankommt.

Irgendwie ist das Ganze mit der stream_id sowieso etwas merkwürdig, zumal sie in dem channels.conf gar nicht gesetzt wurde.

Aber vielleicht weiß da einer der DVB-T-Experten mehr?

Hiernach

@kls: Stream ID neuer Parameter in channels.conf?
ist die stream_id in der channels.conf der P-Parameter, und der ist in der in #23 geposteten channels.conf für Das Erste bereits 0:

B8C12G19128M64S1T16P0

Allerdings war das nach meiner Erinnerung eine veraltete channels.conf, die da gepostet wurde, in der die Frequenzumstellung des NDR-Paketes noch nicht berücksichtigt war.

Gehen wir mal davon aus, dass der P-Parameter richtig auf 0 konfiguriert ist und vdr das auch so an den Treiber gibt. Dann scheint der aktuelle Treiber das aus irgendwelchen Gründen zu ignorieren und stattdessen die 1 zu setzen. Geschieht das denn auch beim ZDF oder nur bei der ARD?

Gegenprobe: Was ist, wenn beim alten Treiber der P-Parameter in der channels.conf bewusst auf 1 geändert wird? Geht der Sender da dann auch nicht mehr?

Try the channelscan plugin.

I would be interested in reviews.

Das Erste HD;ARD:538000:B8D0G19128M2P1Q1S1T16X0Y0

Hier wird jetzt explizit P1 vorgegeben. Und diese channels.conf wurde auch beim Test mit dem alten Treiber verwandt, bei dem laut Analyse von SHF stream_id 0 gesetzt wurde? Das wäre dann für mich nur erklärlich, wenn der Treiber die stream_id damals gar nicht berücksichtigt hat und pauschal 0 gesetzt hat.

Was ist, wenn Du den Teil der channels.conf auf

Das Erste HD;ARD:538000:B8D0G19128M2P0Q1S1T16X0Y0

änderst? Funktioniert es dann mit dem neuen Treiber?

Und die Gegenprobe mit 16.04 und P1?

Welchen Kernel verwendest Du unter Ubuntu 16.04.? Stammen die dvb-Treiber darin aus einem TBS-Paket? Hast Du dazu noch die Sourcen? Ich würde mir da gerne mal eine Stelle anschauen, ob die da schon so wie im aktuellen si2168-Treiber war.

Es gab da 2015 ein möglicherweise ähnliches Problem mit dem Vorschlag des Treiberentwicklers, testweise mit einem Hack die stream_id fix auf 0 zu setzen. Anscheinend kam danach aber nichts mehr vom User.

Ich bin dann noch auf einen Post von HelmutB (R.I.P.) gestoßen, der eine Modifikation des vdr-Codes in dvbdevice.c vorschlägt. Das passt auch für vdr-2.6.7 noch.

Kannst Du vdr selbst kompilieren? in dvbdevice.c wird aus

     if (frontendType == SYS_DVBT2) {
        // DVB-T2
        SETCMD(DTV_INNER_FEC, dtp.CoderateH());
        if (DvbApiVersion >= 0x0508) {
           SETCMD(DTV_STREAM_ID, dtp.StreamId());
           }
        else if (DvbApiVersion >= 0x0503)
           SETCMD(DTV_DVBT2_PLP_ID_LEGACY, dtp.StreamId());
        }

dann

     if (frontendType == SYS_DVBT2) {
        // DVB-T2
        SETCMD(DTV_INNER_FEC, dtp.CoderateH());
        // user defineable StreamId autodetection: StreamId == -1
        int streamId = (dtp.StreamId() == -1) ? NO_STREAM_ID_FILTER : dtp.StreamId();
        if (DvbApiVersion >= 0x0508) {
           SETCMD(DTV_STREAM_ID, streamId);
           }
        else if (DvbApiVersion >= 0x0503)
           SETCMD(DTV_DVBT2_PLP_ID_LEGACY, streamId);
        }

Quote from Dr. Seltsam

Hiernach[...] ist in der in #23 geposteten channels.conf für Das Erste bereits 0:

Da hatte ich gestern wohl Tomaten auf den Augen.

Quote from Dr. Seltsam

Es gab da 2015 ein möglicherweise ähnliches Problem mit dem Vorschlag des Treiberentwicklers, testweise mit einem Hack die stream_id fix auf 0 zu setzen.

Ich denke eher, dass der Filter ganz abgeschaltet wird.

Das Register cmd.args[1] enthält die stream_id.
Das Nächste cmd.args[2] scheint den Filter zu aktivieren, da es nur auf "0" gesetzt wird, wenn die stream_id "NO_STREAM_ID_FILTER" ist.
Der Hack setzt cmd.args[2] fest auf "0", damit müsste der Filter abgeschaltet sein.

Die Idee das notfalls genau so mal zu versuchen, war mir auch schon gekommen. Ich wollte nur erstmal versuchen, ob man es auch einfacher hin bekommt.

Quote from Dr. Seltsam

Ich bin dann noch auf einen Post von HelmutB (R.I.P.) gestoßen, der eine Modifikation des vdr-Codes in dvbdevice.c vorschlägt. Das passt auch für vdr-2.6.7 noch.

Man könnte es auch einfach mal so probieren P-1 zu setzen.

Anhand der Definition könnte das jetzt schon gehen, falls das nirgendwo abgefangen wird.

(#define NO_STREAM_ID_FILTER (~0U) entspricht int -1.)

Im Logfile wird man dann ja sehen, was ankommt.

Das Erste HD;ARD:538000:B8D0G19128M2P1Q1S1T16X0Y0:T:27500:4369=36:4370=deu@17,4371=mis@17,4373=qks@17:4372:0:769:8468:2562:0

Die Kanäle sind sowieso etwas merkwürdig, wenn man es mit diesen (offiziellen ?) Angaben vergleicht:

Quote from https://www.ndr.de/der_ndr/empfang_und_technik/dvbtzweidatenblattnds100.pdf

Parameter ARD_NDR und NDR_NDS

16k extended, 19/128 Guard-Intervall, PP2

64-QAM, Coderate 1/2 (Datenrate 18,2 Mbit/s)

Ich hätte da eher sowas wie "B8D0G19128M64P1Q1S1T16X0Y0" erwartet.

"M2" steht für QPSK, das kann eigentlich nicht passen.

Die Werte werden vom Treiber anscheinend aber eh nicht ausgewertet.

Verwendet werden, soweit ich das sehen konnte, nur:

delivery_system, bandwidth_hz, frequency beim Tuner und

delivery_system, bandwidth_hz, stream_id (symbol_rate nur bei DVB-C) beim Demod .

Quote from Dr. Seltsam

Welchen Kernel verwendest Du unter Ubuntu 16.04.? Stammen die dvb-Treiber darin aus einem TBS-Paket? Hast Du dazu noch die Sourcen? Ich würde mir da gerne mal eine Stelle anschauen, ob die da schon so wie im aktuellen si2168-Treiber war.

Das müsste auch damals schon ein Treiberpaket von TBS gewesen sein.

Ein paar Infos dazu könnten aber nicht schaden, falls man da noch ran kommt.

Wenn es auch schon aus dem Git kam, reicht die letzte commit-id.

Also das, was bei git log direkt rechts nach dem obersten commit kommt.

schalte mal in Einstellungen - DVB - Kanäle aktualisieren auf 'nein'. Kannst Du den P-Parameter danach über das OSD auf 0 ändern? Wenn nicht, muss vdr gestoppt und die channels.conf anschließend händisch editiert werden. Danach sollte keine automatische Aktualisierung und auch kein Überschreiben mehr erfolgen. Ich hoffe, dass der der Parameter dann so nicht nur beim Treiber ankommt, sondern auch tatsächlich gesetzt wird.

Aus dem TBS-Treiberpaket interessiert mich nur die Datei si2168.c - sie sollte in /drivers/media/dvb-frontends liegen.

das ist wirklich aus dem funktionierenden Treiber, der unter 16.04 läuft?

Der Code ist an der möglicherweise entscheidenden Stelle genauso wie aktuell

    if (c->delivery_system == SYS_DVBT2) {
        /* select PLP */
        cmd.args[0] = 0x52;
        cmd.args[1] = c->stream_id & 0xff;
        cmd.args[2] = c->stream_id == NO_STREAM_ID_FILTER ? 0 : 1;
        cmd.wlen = 3;
        cmd.rlen = 1;
        ret = si2168_cmd_execute(client, &cmd);
        if (ret)
            goto err;
    }

Ich verliere leider den Durchblick. Vielleicht kann SHF nochmal erläutern, wie sein Vorschlag

Quote

Man könnte es auch einfach mal so probieren P-1 zu setzen.

Anhand der Definition könnte das jetzt schon gehen, falls das nirgendwo abgefangen wird.

(#define NO_STREAM_ID_FILTER (~0U) entspricht int -1.)

Im Logfile wird man dann ja sehen, was ankommt.

zu verstehen ist.

Quote from Dr. Seltsam

Der Code ist an der möglicherweise entscheidenden Stelle genauso wie aktuell

Ausgerechnet an der Stelle scheint schon ewig nichts geändert worden zu sein.

Anscheinend ist irgendwann DTV_DVBT2_PLP_ID_LEGACY durch DTV_STREAM_ID ersetzt worden.

Da könnte unbeabsichtigt auch eine Änderung im Verhalten rein gekommen sein.

Wenn man es aber irgendwie schafft, dass 0 oder -1 im Log auftaucht, sollte das egal sein.

Das blöde ist, dass ich nicht mal sicher bin, ob nun P1 oder P0 richtig wäre.

Bei falschem Wert sollte es jedenfalls keinen Empfang geben, wenn alles korrekt funktioniert.

Interessant ist, dass der VDR bei ARD-Transponder P0 in P1 umschreibt, beim ZDF aber nicht.

Das ist etwas merkwürdig, weil die neuen Daten zum ARD-Transponder ja irgendwo her gekommen müssen.

Unter Umständen tunt der VDR den ARD-Transponder genau ein mal ganz kurz, zerstört die channels.conf und das was's dann. Das wäre echt ein blöder Fehler.

Quote from Dr. Seltsam

schalte mal in Einstellungen - DVB - Kanäle aktualisieren auf 'nein'.

Das sollte man wirklich mal machen und dann mit der alten channels.conf versuchen.

fhg Nur zur Sicherheit und weil das Problem noch immer so merkwürdig ist:

Bitte schau bei Ubuntu 22.04 noch mal nach, ob da wirklich keine Reste vom TBS-Treiber mehr vorhanden sind.

ls /lib/modules/$(uname -r)/updates/extra/media/dvb-frontends sollte nichts anzeigen, oder eine Fehlermeldung, dann ist alles o.k..

Wenn da eine lange Liste mit .ko Dateien kommt, ist der TBS-Treiber noch drauf.

Dann bitte den Kernel erneut installieren sudo apt install --reinstall linux-image-....

(evtl. ist vorher ein purge notwendig, falls die Module nach dem --reinstall noch immer nicht weg sind.)

Quote from Dr. Seltsam

Vielleicht kann SHF nochmal erläutern, wie sein Vorschlag

zu verstehen ist.

Einfach P0 oder P1 (was halt drin steht) in der channels.conf in P-1 ändern.

Dann muss man im Log schauen, ob es auch im Treiber ankommt.

(Erklärung:

Das könnte gehen, weil NO_STREAM_ID_FILTER als (~0U) definiert ist.

~0U und entspricht Binär 11111111111111111111111111111111 (bitweise Negation von 0).

Unsigned entspricht das 4294967295 Dezimal, bei einem int mit Vorzeichen, und das verwendet der VDR hier, aber -1.)

Also hast Du jetzt die P0 in der channels.conf und ein ungewolltes Überschreiben durch vdr mittels Deaktivierung der Kanalaktualisierung verhindert?

Oder bist Du SHF's Vorschlag gefolgt und hast -1 als Wert für P eingetragen (ich weiss gar nicht, ob das überhaupt geht)

Das löst das eigentliche Problem aber ja nicht. Warum finden t2scan und vdr anhand der Transponderinfo den Parameter P1, wenn damit kein Empfang möglich ist? Wenn die ARD ihre Transponderdaten falsch deklariert, müssten ja auch andere Empfänger Probleme haben. Ich vermute eher, dass hier entweder vdr oder der Treiber die Hardware nicht richtig ansprechen und die plp autodetection deshalb nicht richtig funktioniert.

Hattest Du den Test unter 16.04 eigentlich mit der gleichen vdr-Version gemacht? Nicht dass das Abändern der Stream-ID erst durch Änderungen in einer späteren vdr-Version entstanden ist.

Wenn Du den TBS-Treiber neu kompilierst, kannst Du ja mal diesen Vorschlag des Treiberentwicklers zu einem ähnlichen Problem ausprobieren:

Could you hack si2168.c file and test?

if (c->delivery_system == SYS_DVBT2) {
    /* select PLP */
    cmd.args[0] = 0x52;
    cmd.args[1] = c->stream_id & 0xff;
//    cmd.args[2] = c->stream_id == NO_STREAM_ID_FILTER ? 0 : 1;
    cmd.args[2] = 0;
    cmd.wlen = 3;
    cmd.rlen = 1;
    ret = si2168_cmd_execute(client, &cmd);
    if (ret)
        goto err;
}

Quote from fhg

Unter 16.04 habe ich noch die alte VDR-Version von 2018, vermutlich eine 2.4er Version.

Sollte sich eigentlich raus finden lassen: VDR aus fnu-repository

Viel interessanter wäre, was da zur Kanalaktualisierung eingestellt ist.

Quote from Dr. Seltsam

Das löst das eigentliche Problem aber ja nicht. Warum finden t2scan und vdr anhand der Transponderinfo den Parameter P1, wenn damit kein Empfang möglich ist? Wenn die ARD ihre Transponderdaten falsch deklariert, müssten ja auch andere Empfänger Probleme haben. Ich vermute eher, dass hier entweder vdr oder der Treiber die Hardware nicht richtig ansprechen und die plp autodetection deshalb nicht richtig funktioniert.

Irgendwie ist es schon merkwürdig, was passiert, zumal es anscheinend ja auch t2scan betrifft.

Das mit t2scan sollte man bitte noch mal verifizieren.

Man könnte es mal mit einem anderen Scan-Tool versuchen, aber da kenne ich mich nicht aus. (Als SAT-User habe ich noch nie scannen müssen.)

Ich würde aktuell am ehesten auf einen Bug im VDR tippen.

Da die channels.conf-Zeile jetzt anders aufgebaut ist, muss in dem Bereich was geändert worden sein.

Dem Problem sollte man jedenfalls mal nach gehen.

Quote from fhg

Daran wollte ich so lange nichts ändern, bis der neue läuft.

Dazu würde ich auch dringend raten !

Es würde jetzt doch sehr helfen, wenn Du angeben könntest, welche vdr-Version unter 16.04. (Ubuntu Xenial) funktioniert. fnu hat ja diverse repositories, aber in keinem finde ich Pakete für Xenial.

Und welche Treiber wurden jetzt unter 16.04. für die Tests mit WinTV dualHD benutzt? Die vom Kernel (welcher? oder ein TBS-Paket? Falls letzteres: Sind das proprietäre Treiber von der TBS Webseite oder Open Source Treiber von https://github.com/tbsdtv/media_build? Ich vermute ersteres, denn laut https://linuxtv.org/wiki/index.php/TBS_driver_installation läuft die 6205 nur mit Closed Source Treibern. Das muss aber nicht aktuell sein.

Wie auch immer, wenn man das Problem jetzt mit dem Treiberentwickler des si2168 aufnehmen will, wäre es besser, ein komplettes Treiberpaket inklusive der Header zu haben. Ist das eines von hier?

https://www.tbsdtv.com/download/index.html?path=6&id=27