dvb-t2 Empfangsprobleme

Bei fnu finde ich die Version nicht mehr mehr, aber in den vdr-Sourcen der 2.4.1 von kls ist der Codeabschnitt aus #68 unverändert so wie heute. Beim Treiber ist dann nun schwieriger zu rekonstruieren, da man dazu den von Dir ausgecheckten git-Stand kennen müsste. Am si2168.c kann es eher nicht liegen, den hattest Du ja schon gepostet. NO_STREAM_ID_FILTER ist in include/uapi/linux/dvb//frontend.h definiert, und das ist auch im tbsdtv-git schon seit mindestens 8 Jahren mit

Zitat

#define NO_STREAM_ID_FILTER (~0U)

definiert, was laut SHF ja für -1 steht.

Ich also verstehe weiterhin nicht, warum es unter 16.04 nicht auch zu einem fälschlichen Überschreiben der stream_id mit 1 kommt. Wenn ich mich richtig erinnere, hatten wir auch schon abgeklärt, dass sowohl unter 16.04 als auch 22.04 die gleiche Firmware-Version B 4.0.25 von dvb-demod-si2168-b40-01.fw verwandt wird.

Hi,

Wie wäre neues System mit altem VDR testen?

MfG Stefan

... und auch altes System mit neuem VDR.

Ich habe bei mir jetzt das gleiche Problem! Einziger Unterschied ist, dass t2scan (frisch aus dem git kompiliert) die stream_id richtig mit 0 erkennt.

• channels.conf wurde mit neu kompiliertem t2scan erzeugt und weist durchgehend P0 aus
• vdr wird gestartet und auf einen ARD-Kanal gewechselt.
• changing transponder data of channel 1 (Das Erste HD) from 490000:B8D0G19128P0Q1S1T16X0Y0:T to 490000:B8D0G19128P1Q1S1T16X0Y0:T
  
• retuning due to modification of channel 1 (Das Erste HD)
• das Bild ist weg
• Kanäle aktualisieren deaktiviert
• per OSD stream-id für den Kanal auf 0 geändert
• Kanal neu angewählt - Bild kommt

Deine t2scan-Version hatte P1 erkannt, meine richtigerweise P0. Jetzt wäre die Frage: welche t2scan-Version hast Du verwandt?

Meine sagt

root@CoreELECTanixTX3 ~ # t2scan -V
t2scan -V 
20201027

Da gab es eine Änderung in scan.c am 03.05.2020 mit der Beschreibung "fix handling of non-multistream capable T2 hardware"

fix handling of non-multistream capable T2 hardware (the first approa… · mighty-p/t2scan@7eaafbd

…ch really did not make a lot of sense...)

github.com

Der vdr-Patch aus #88 hilft nicht.

Das device liefert als capability u.a. CAN_MULTISTREAM. Aber offenbar kann vdr damit nicht richtig umgehen.

Eine stream_id -1 kann man übrigens nicht setzen. vdr akzeptiert nur 0-255

Bei SAT bin ich relativ sicher, dass die Kanal-Informationen ausschließlich aus dem TS selber stammen. AFAIK ist das ganze auch Transponder übergreifend.

Sofern das bei DVB-T2 nicht anders ist, müsste der Fehler irgendwo im NIT-Scanner vom VDR liegen. Oder die ARD oder ein anderer Transponder senden defekte Kanaldaten.

Edit:

Könnte das die Ursache sein?

Fixed handling parameters in the S2SatelliteDeliverySystemDescriptor and T2DeliverySystemDescriptor that were overwritten when parsing the SatelliteDeliverySystemDescriptor or TerrestrialDeliverySystemDescriptor, respectively.

Zitat von fhg

Liegt das evtl. daran, daß ich den heutigen Scan nicht als root gemacht habe?

Eher nein.

Zitat von fhg

VDR-Version unter 16.04, Kernal 4.8.0-58-generic ist von fnu die Version 2.4.1-0fnu0-xenial.

Ich frage mich, ob fnu in diesen vdr vielleicht einen Patch eingebaut hat, der zu einer funktionierenden multistream-Behandlung führte. HelmutB hatte damals allerlei Patches erstellt, von denen fnu vielleicht vorab eine Lösung integriert hatte, die so dann später nicht von kls übernommen wurde.

Frank, kannst Du bitte mal nachschauen, ob Du die Sourcen für dieses vdr-Paket noch findest? Bei launchpad bin ich nicht fündig geworden, das älteste dort war ein 2.4.8

richtig, die Frage richtete sich an den Paketbauer fnu, der auch auf den Namen Frank hört

Dr. Seltsam

Martin, konnte tatsächlich noch prüfen was ich seinerzeit mal an Patches in dieses Paket gepackt habe:

vdr:/stable/vdr2040x> git branch
* (HEAD losgelöst bei debian/2.4.1-0fnu0_xenial)

vdr:/stable/vdr2040x> ll debian/patches
-rw-r--r-- 1 root root  1282 Jan 20  2022 04_newplugin.patch
-rw-r--r-- 1 root root  2299 Dez 23  2021 81_Make_config.patch
-rw-r--r-- 1 root root   480 Mai 24 11:17 99_ncursesw-include.patch
-rwxr-xr-x 1 root root   218 Dez 23  2021 list_uncritical_patches
-rw-r--r-- 1 root root  9996 Mai 24 11:17 opt-10_vdr-2.4.0-editrecording.patch
-rw-r--r-- 1 root root  3345 Mai 24 11:17 opt-10_vdr-2.4.0-menuselection.patch
-rw-r--r-- 1 root root  1058 Mai 24 11:17 opt-10_vdr-2.4.0-resumereset.patch
-rw-r--r-- 1 root root  9009 Mai 24 11:17 opt-37-x_menuorg.patch
-rw-r--r-- 1 root root  7210 Mai 24 11:17 opt-42-x_MainMenuHooks-v1.0.3.patch
-rw-r--r-- 1 root root 11682 Mai 24 11:17 opt-55_wareagleicon.patch
-rw-r--r-- 1 root root   445 Mai 24 11:17 series

Aber wie man sehen kann nichts aussergewöhnliches und m.E. kein Patch der irgendwas an den Empfangsmethoden verändert. Nach Prüfung der anderen Branches auch sonst nicht.

commit 2a02fb9c9139af36b51548863759886639d50263 (HEAD, tag: debian/2.4.1-0fnu0_xenial)
Author: Frank Neumann <fnu@yavdr.org>
Date:   Wed Jun 19 17:20:13 2019 +0200

    VDR Stable Version
    
    * VDR Stable Version
    * contains following patches:
      -04_newplugin.patch
      -81_Make_config.patch
      -99_ncursesw-include.patch
      -opt-10_vdr-2.4.0-resumereset.patch
      -opt-10_vdr-2.4.0-menuselection.patch
      -opt-10_vdr-2.4.0-editrecording.patch
      -opt-37-x_menuorg.patch
      -opt-42-x_MainMenuHooks-v1.0.3.patch
      -opt-55_wareagleicon.patch
    * VDR Stable 2.4.x doesn't provide
      dvbsddevice or dvbhddevice anymore

Danke! Schade, ich hatte gehofft, es sei vielleicht einer der Patches aus [Patch] DVB-S2 Multi Input Stream (ungetestet) DVB-T2 MPLP+Scan enthalten.

Dann bleibt als Erklärung für das Funktionieren unter Ubuntu 16.04 wohl nur eine Anpassung von TBS in deren Treiber. Das muss nicht zwingend die si2168.c gewesen sein.

Zitat von fhg

Die von mir gepostete channels.conf war evtl. schon durchprobiert und dadurch auf P1 für ARD geändert. Meine t2scan-Version ist:

Code

fhg@ubuntu-tv:~$ t2scan -V
t2scan -V
20200628

Ich habe eben noch einen Scan gemacht, der sieht gut aus, alle Kanäle haben P0, hier ein Ausschnitt:

Code

Das Erste HD;ARD:538000:B8D0G19128S1T16Y0P0:T:27500:4369=36:4370=deu@17,4371=mis@17,4373=qks@17:4372:0:769:8468:2562:0
arte HD;ARD:538000:B8D0G19128S1T16Y0P0:T:27500:4385=36:4386=deu@17,4387=fra@17,4389=mul@17,4393=mis@17:4388:0:770:8468:2562:0
phoenix HD;ARD:538000:B8D0G19128S1T16Y0P0:T:27500:4401=36:4402=deu@17,4403=mul@17:4404:0:771:8468:2562:0
tagesschau24 HD;ARD:538000:B8D0G19128S1T16Y0P0:T:27500:4417=36:4418=deu@17,4419=mis@17:4420:0:772:8468:2562:0
ONE HD;ARD:538000:B8D0G19128S1T16Y0P0:T:27500:4433=36:4434=deu@17,4435=mis@17:4436:0:773:8468:2562:0
BR Fernsehen Süd HD*;ARD:546000:B8D0G19128S1T16Y0P0:T:27500:4689=36:4690=deu@17,4691=mis@17:4692:0:802:8468:5122:0
hr-fernsehen HD*;ARD:546000:B8D0G19128S1T16Y0P0:T:27500:4673=36:4674=deu@17,4675=mis@17:4676:0:833:8468:5122:0
MDR S-Anhalt HD*;ARD:546000:B8D0G19128S1T16Y0P0:T:27500:4657=36:4658=deu@17,4659=mis@17:4660:0:866:8468:5122:0
WDR HD Köln;ARD:546000:B8D0G19128S1T16Y0P0:T:27500:4641=36:4642=deu@17,4643=mis@17:4644:0:1030:8468:5122:0
ZDF HD;ZDFmobil:586000:B8D0G19128S1T16Y0P0:T:27500:2110=36:0;2120,2121,2122:2130;2131:0:2001:8468:515:0
ZDFinfo HD;ZDFmobil:586000:B8D0G19128S1T16Y0P0:T:27500:2210=36:0;2220,2221,2222:2230;2231:0:2002:8468:515:0
zdf_neo HD;ZDFmobil:586000:B8D0G19128S1T16Y0P0:T:27500:2310=36:0;2320,2321,2322:2330;2331:0:2003:8468:515:0
3sat HD;ZDFmobil:586000:B8D0G19128S1T16Y0P0:T:27500:2410=36:0;2420,2421,2422:2430;2431:0:2004:8468:515:0
KiKA HD;ZDFmobil:586000:B8D0G19128S1T16Y0P0:T:27500:2510=36:0;2520,2521,2522:2530;2531:0:2005:8468:515:0
Radio Bremen HD;ARD:674000:B8D0G19128S1T16Y0P0:T:27500:5649=36:5650=deu@17,5651=mis@17,5653=qks@17:5652:0:929:8468:3330:0

Alles anzeigen

Seltsamerweise ist der Parameterstring kürzer als in der letzten geposteten Version, die ich aber definitiv mit der selben Version erzeugt habe. Liegt das evtl. daran, daß ich den heutigen Scan nicht als root gemacht habe?

In dem t2scan-Thread wurde ja mehrfach berichtet, dass bei jedem neuen Scan die Anzahl gefundener Sender und ich glaube auch ihre Parameter unterschiedlich waren. Dieses Multistream-Zeug ist saukompliziert. Ich glaube HelmutB war der einzige, der da richtig durchgeblickt hat. Zu schade, dass er nicht mehr unter uns weilt.

Zitat von Dr. Seltsam

Dieses Multistream-Zeug ist saukompliziert.

Prinzipiell ist es erstmal gar nicht so kompliziert.

Eigentlich werden nur mehrere TS verschachtelt auf einem Transponder ausgestrahlt.

Das Frontend extrahiert daraus den gewählten TS und das dann geht es weiter wie gehabt .

(Die weiteren Details zur Übertagung sind eigentlich nicht relevant, da das Frontend die ganze Arbeit erledigt. Auch die Probleme, die theoretisch auftreten könnten, weil der TS jetzt in größeren Blöcken und nicht mehr kontinuierlich kommt, kann erstmal ignorieren, denke ich.)

Gemacht wird das Ganze um Programme mehrerer Anbieter auf einem Transponder unter zu bringen, ohne die ganzen Programme in einen neuen TS muxen zu müssen. Und mit dieser Sparlösung fangen jetzt für uns die Probleme an.

Da der/die TS nicht neu erstellt werden, kann die stream_id nicht in der NIT übertragen werden.

(Die stream_id kann theoretisch, je nach Übertrgungsweg/Sender unterschiedlich sein und außerdem ist sie beim muxes des TS nicht zwingend bekannt.)

Ob man man die Rohdaten aller Streams überhaupt gleichzeitig ran kommt, wenn man NO_STREAM_ID_FILTER setzt, bin ich nicht sicher. So wie ich es verstanden habe, können sich die Modulationsparameter der einzelnen (Multi-)Streams eines Transponders unterscheiden.

Wenn es geht müsste man alle gültigen stream_ids eines Transponders eigentlich irgendwie extrahieren können, wenn nicht, ist raten angesagt.

PLS hat mit Multistream(PLP) nichts zu tun, das ist wohl eher eine Modulations-Geschichte bei DVB_S2. Das ist nur überall in den Patches, da es dort praktisch alle Multistream-Transponder verwenden. Den PLS-Code wohl vorher wissen, da man ohne gar nicht erst an den Datenstrom kommt. (Die Codes durch probieren ginge natürlich, aber das dauert.)

Ein Teil der Patches sieht mir aber so aus, als ob es auch für DVB-T2 sinnvoll wäre. Die streamId in der channels.c zB., da müsste man mal schauen, was da bislang übernommen wurde.

Die Problemantik an der Multistream-Geschichte ist wohl primär das scannen. Wenn man den Kanaleintrag hat, sollte das Frontend den Rest erledigen.

Wo die stream_id 1 her kommt die der VDR beharrlich setzt, konnte ich heute aber immer noch nicht raus finden. Da muss ich die Tage mal weiter suchen.

Zum Abschluss noch etwas Literatur zum Thema:

Multistream - OpenPLi Wiki

DVB-T2 - Wikipedia

>> Eigentlich werden nur mehrere TS verschachtelt auf einem Transponder ausgestrahlt.

Na eher zeitversetzt mit jeweils eigenen physikalischen Parametern. Normalerweise mit Parametern für hohe Reichweite, periodisch wechselnd mit Parametern für hohe Bitrate. Bei knappen Frequenz Ressourcen.

>> Gemacht wird das Ganze um Programme mehrerer Anbieter auf einem Transponder unter zu bringen, ohne die ganzen Programme in einen neuen TS muxen zu müssen.

Wenn man ein HDTV Programm mit hoher Bitrate, aber kleiner Reichweite mit einem SDTV/Radio Programm && großer Reichweite kombinieren möchte, dann landet man genau dabei. Oder mehrere räumlich nahe Transmitter entkoppeln möchte.

Danke für die Ergänzungen, ich hatte mich bislang erst 2 Stunden mit dem Thema beschäftigt und das mit dem Fokus auf die Bestimmung der Frontend-Parameter.

Da sind die physikalischen Details zur Übertragung erstmal nicht wirklich relevant, daher hatte ich das etwas vereinfacht dargestellt.

Von Seiten des Empfängers muss ich eigentlich nur die richtige stream_id setzen (neben den anderen Daten) und bekommen dann einen normalen Transportstrom geliefert. Aktuell sehe ich da nicht wirklich einen Unterschied zB. zur Polarisation bei SAT.

Bis auf, dass hier der Wert nicht im Transportstrom geliefert wird.

Zitat von wirbel

Na eher zeitversetzt mit jeweils eigenen physikalischen Parametern.

So kann man es auch ausdrücken.

Wer es genau wissen will, im folgenden Link ist das unter "frame structure" schön grafisch dargestellt:

DVB-T2 - Enensys

(Zu dem Artikel war ich gestern nicht mehr gekommen.)

Weiter unten sieht man, dass die TS-Pakete in "BaseBand frames" verpackt sind. Irgendwo in deren Header müsste dann wohl die stream_id sitzen.

Meine Frage, ob man bei setzen von "NO_STREAM_ID_FILTER" die ganzen Rohdaten bekommt, konnte ich aber noch immer nicht klären.

Im VDR bin ich auch nur bedingt weiter gekommen.

Die stream_id wird hier im Frontend gesetzt.

D.h. gespeichert ist die in cDvbTransponderParameters und wird mit SetStreamId() gesetzt.

Wenn man jetzt danach sucht bekommt man mehrere Treffer in der nit.c .

Also, der VDR hat die Informationen wohl aus dem T2DeliverySystemDescriptor.

EN 300 468 - V1.11.1 - Digital Video Broadcasting (DVB) - ETSI

Der ist, wenn ich das beim Überfliegen nicht völlig falsch verstanden habe, Teil der NIT.

D.h. er wird genau wie bei DVB-S im TS geliefert.

Also von da her alles wie bisher, bis auf, dass man die stream-id braucht, um überhaupt an den TS zu kommen.

Warum es bei älteren VDR-Versionen funktioniert, liegt vermutlich an diesem Patch:

Fixed handling parameters in the S2SatelliteDeliverySystemDescriptor and T2DeliverySystemDescriptor that were overwritten when parsing the SatelliteDeliverySystemDescriptor or TerrestrialDeliverySystemDescriptor, respectively.

Wobei, ich glaube, ich habe eben zumindest mal einen Fehler gesehen:

Fehlt in der einen Zeile nicht ein "c"???

--- a/nit.c
+++ b/nit.c
@@ -257,6 +257,6 @@ void cNitFilter::Process(u_short Pid, u_char Tid, const u_char *Data, int Length
                            cDvbTransponderParameters dtpc(Channel->Parameters());
                            dtp.SetSystem(dtpc.System());
                            dtp.SetStreamId(dtpc.StreamId());
-                           dtp.SetT2SystemId(dtp.T2SystemId());
+                           dtp.SetT2SystemId(dtpc.T2SystemId());
                            dtp.SetSisoMiso(dtpc.SisoMiso());
                            dtp.SetBandwidth(dtpc.Bandwidth());
                            dtp.SetGuard(dtpc.Guard());

Kurioser Weise aber bei der T2SystemId nicht StreamId.

Ob es daran liegt, müsstet ihr mal probieren.

Zitat von SHF

Warum es bei älteren VDR-Versionen funktioniert, liegt vermutlich an diesem Patch:

Fixed handling parameters in the S2SatelliteDeliverySystemDescriptor and T2DeliverySystemDescriptor that were overwritten when parsing the SatelliteDeliverySystemDescriptor or TerrestrialDeliverySystemDescriptor, respectively.

Wobei, ich glaube, ich habe eben zumindest mal einen Fehler gesehen:

Fehlt in der einen Zeile nicht ein "c"???

Diff

--- a/nit.c
+++ b/nit.c
@@ -257,6 +257,6 @@ void cNitFilter::Process(u_short Pid, u_char Tid, const u_char *Data, int Length
                            cDvbTransponderParameters dtpc(Channel->Parameters());
                            dtp.SetSystem(dtpc.System());
                            dtp.SetStreamId(dtpc.StreamId());
-                           dtp.SetT2SystemId(dtp.T2SystemId());
+                           dtp.SetT2SystemId(dtpc.T2SystemId());
                            dtp.SetSisoMiso(dtpc.SisoMiso());
                            dtp.SetBandwidth(dtpc.Bandwidth());
                            dtp.SetGuard(dtpc.Guard());

Alles anzeigen

Kurioser Weise aber bei der T2SystemId nicht StreamId.

Ob es daran liegt, müsstet ihr mal probieren.

Alles anzeigen

Ich habe die vorgeschlagene Änderung in nit.c mal in vdr-2.6.7 übernommen. Und siehe da, jetzt überschreibt vdr die korrekte stream-id 0 nicht mehr mit 1, wenn Kanäle aktualisieren in den DVB-Einstellungen aktiviert ist.

Allerdings berichtigt er eine falsch eingetragene 1 bei nächster Kanalwahl auch nicht auf 0. Löscht man den Kanal aber aus der Kanalliste, wird er korrekt mit 0 neu erkannt und ans Ende der Kanalliste angefügt. (Kanäle aktualisieren steht bei mir auf 'neue Kanäle hinzufügen')

Sieht also so aus, als wenn das tatsächlich ein Tippfehler ist. Wenn kls das auch so sieht, könnte das ja in die Version vdr-2.6.8 einfließen.

O.k., das erklärt einiges, da muss wohl noch irgendwo anders ein Fehler sein.

EDIT:

Nicht zwingend. Wenn die falsch eingetragene 1 verhindert, dass der Transponder getunt wird, kann der Eintrag nicht korrigiert werden.

Evtl. klappt es, wenn man beim Ersten die 1 einträgt und dann auf ein drittes Programm schaltet?

An der geänderten Stelle werden lediglich die T2-Parameter vom bisherigen Kanaleintrag "gerettet" (erste Zeile in meinem Patch) und dann erneut gesetzt. Das verhindert, dass die Werte mit den Default-Werten überschrieben werden.

Die T2-Parameter werden direkt darunter im Block mit T2DeliverySystemDescriptorTag ermittelt und gesetzt. Das ist auch die einzige Stelle im Code, wo der T2DeliverySystemDescriptorTag auftaucht.

Warum jetzt das Update nicht funktioniert, aber die Kanäle korrekt neu erkannt werden, ist mir momentan aber auch unklar.