Posts by HelmutB

    Naja, ich bin da weniger pessimistisch weil der Zusammenhang hier beschrieben ist:

    Code
    1. ETSI EN 300 468 V1.15.1 (2016-03)
    2. 5.2.1 Network Information Table (NIT)
    3. ...
    4. network_id: This is a 16-bit field which serves as a label to identify the delivery system, about which the NIT informs, from any other delivery system. Allocations of the value of this field are found in ETSI TS 101 162 [i.1].

    Helmut

    Und dann?

    Sie werden ignoriert, da sie für das aktuelle Delivery System ungültig sind. Außerdem würden damit u.U. Transponder hinzugefügt, die ohne entsprechendem Tuner nicht zu empfangen sind.

    Code
    1. ETSI EN 300 468 V1.16.1 (2019-08)
    2. 4.1.1 Network Information Table (NIT) information
    3. The Network Information Table (NIT) provides ...
    4. ...
    5. The following rules apply to the NIT:
    6. a) transmission of the NIT is mandatory for the actual delivery system;
    7. b) the NIT describing the actual delivery system is valid if and only if it contains applicable delivery system descriptors for the actual delivery system. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    8. At some transitions of broadcast delivery system boundaries, the NIT carried in a TS is allowed to be invalid, and to describe an earlier network in the broadcast chain. In this case, a different mechanism has to be selected by the IRD to obtain the relevant tuning information for the actual delivery system. More information is provided in clause 5.3;


    Viele Netzwerke übernehmen 1:1 streams aus anderen Netzwerken ohne Anpassung der NIT.

    Du meist damit wahrscheinlich den Punkt 5.3 Transitions at broadcast delivery media boundaries. Ich bin nich ganz sicher ob ich es richtig verstehe, aber um da Tuning Informationen zu bekommen müsste man - falls vorhanden - eine andere NIT-Pid auswerten oder einen Frequency-Scan durchführen.

    Helmut



    Inhaltlich muss ich den Patch noch verdauen/verstehen.

    Er ist vielleicht deshalb etwas unklar, weil nit.c nicht die richtige Stelle ist, um die Gültigkeit von Nid/Tid zu prüfen. Das geht einfacher und besser in sdt.c, da hier die Id's des tatsächlich empfangenen TransportStreams bekannt sind. Im Anhang der korrigierte und dadurch vereinfachte Patch v2.

    Zusätzlich auch ein Patch der überprüft, ob die Informationen der NIT für das aktuell getunte DeliverySystem gültig sind.

    Helmut

    Hier die Version 3 des multistream Patch mit Anzeige der DVB-S2 MULTISTREAM Info:Oct 10 22:57:12 gentoo64 vdr[14735]: [14735] frontend 0/1 provides DVB-S,DVB-S2(MULTISTREAM),DSS with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("TurboSight TBS 5520SE DVB-S/S2/S2X")


    Im Sundtek SkyTV 8 dürfte übrigens ein M88RS6060 Tuner+Demod Chip verbaut sein und kein SI2183. Einen nicht ganz vollständigen Linux Treiber (nur S+S2, kein S2X oder Multistream) gibt es bei CoreElec auf Github.

    Um Testweise PLS und Stream-ID so wie beim Si2183 an das Frontend zu übergeben, kann in Zeile 210 das #define FORCE_TBS 0 in 1 geändert werden.


    Helmut

    Ich sehe gerade, du hast im beim Sundtek Support wegen Multistream angefragt - der SkyTV 8 Stick soll es können.

    Woraus "bestehen" eigentlich diese Sundtek USB Empfänger. Ich habe jetzt etwas gesucht aber ncht klar herausgefunden welcher Fronend-Chip verbaut ist (gibt es den Teiber bei Sundtek nur binär ? etwas mystisch das ganze).

    Für S2-Multistream und PLS kenne ich Treiber für stv0910, stv091x, stv090x und stv0900 (mit chip-id 0x30), si2183, STiD135, und ddbridg-sx8. Ist einer davon im Sundtek verbaut?

    Edit:

    -- Habe hier diese Anmerkung zur SkyTV 8 von 'CrazyCat' gefunden:

    Look like another USB stick with Silabs demod, which have restricted VCM support (multistream with DTT muxes). Some upgrade option for old VU+, Dreambox and etc users.


    Könnte also der Si2183 ein. Falls es bei dir also nicht gleich läuft, dann ist wahrscheinlich so etwas wie im force_tbs.diff aus dem Post #16 notwendig.


    LG Helmut

    Ja, wäre vielleicht hilfreich zu erfahren ob das Frontend S2 Multistream kann.

    Soll es jedesmal beim Umschalten angezeigt werden? Ich würde eher nurcDvbFrontend::QueryDeliverySystems() um die caps "MULTISTREAM" ergännzen. Dann würde es beim Start von von VDR z.B. so angezeigt werden:

    Oct 6 19:26:22 gentoo64 vdr[7508]: [7508] frontend 0/1 provides DVB-S,DVB-S2, DSS (MULTISTREAM) with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("TurboSight TBS 5520SE DVB-S/S2/S2X")

    LG Helmut

    Ich sehe schon, meine TBS Erkennung stimmmt nicht bei für deine PCI Karte.

    Hier ein Patch der vorläufig immer eine TBS Karte annimmt (das diff als Ergänzung). Damit wird auch die VendorID angezeigt die ich zur Prüfung verwende (oder verwenden würde).

    LG Helmut

    Files

    Mit der TBS wirst du ja auch die Treiber von https://www.tbsdtv.com/download/index.html?path=15&id=29 verwenden, sollte also passen.

    Siehst du in deinem syslog beim start von VDR die Zeile Adapter 0 : TBS product detected wie hier:

    Code
    1. Oct 6 19:26:22 gentoo64 vdr[7508]: [7508] frontend 0/0 provides DVB-T,DVB-T2,DVB-C,ISDBT,DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("TurboSight TBS 5520SE DVB-T/T2/C/C2/ISDB-T")
    2. Oct 6 19:26:22 gentoo64 vdr[7508]: [7508] Adapter 0 : TBS product detected <<<<<<<<<<<<<<<<<<<<<<<< hier <<<<<<<<<<<
    3. Oct 6 19:26:22 gentoo64 vdr[7508]: [7508] frontend 0/1 provides DVB-S,DVB-S2,DSS with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("TurboSight TBS 5520SE DVB-S/S2/S2X")

    Diese Erkennung ist wichtig, damit der Si2183 Demodulator PLS_code, PLS_mode und ISI über DTV_STREAM_ID erhält. Falls nicht, kannst du einaml die Ausgabe von lspci -n -v für die TBS posten.


    Ich habe bei mumudvb nachgesehen. Hier werden auch alle Werte in gemeinsam in DTV_STREAM_ID übergeben - damit kommen alle Frontend Treiber des TBS media-build trees klar, also muß beim VDR multistream Patch hier irgendwo noch ein Fehler sein.

    That is the reason for why i want to detect TBS Products - the kernel driver stv090x.c can't handle a combined Pls_mode<<26 |PLS_code<<8|ISI value as DTV_STREAM_ID. This special Value is Si2183 specific.


    LG Helmut

    Auf 12534H ist ein Transponder mit 4 Streams (33,34,35,36) aber ohne PLS : Link.

    Bekommst du da einen Lock ? Ohne PLS sollte es VDR auch ohne den multistream Patch können.

    Hier 2 Kanaleinträge für die Stream-Id 33:

    ISID33:12543:HC89M5O0P33S1:S5.0W:34200:0:0:0:0:0:0:0:0

    Giallo:12543:HC89M5O0P33S1:S5.0W:34200:0:0:0:0:16:11:33:0


    Und hier noch 2 Varianten für MIS+PLS auf 12648V

    bbb:12648:VC89M5O0P1Q1212121S1:S5.0W:29500:0:0:0:0:0:0:0:0

    TF1:12648:VC89M5O0P1Q1212121S1:S5.0W:29500:0:0:0:0:2561:8442:10:0


    Helmut

    Ok, habe den Fehler gefunden. DVB-APi Version 5.11 ist gefragt - in Hex 0x50B, und nicht 0x511 wie im Patch.

    Dadurch wurde der scrambling_sequence_index '121212' nicht an das Frondend gesendet - kann daher auch nicht gehen.


    Im Anhang ein kleines diff und der ganze Patch als Version 1.

    LG Helmut

    Da die Informationen des S2 DeliverySystemDescriptors derzeit noch nicht verwertet werden, hier ein Patch der - so wie ich es mir vorstelle - DVB-S2 Multistream in den VDR bringt.


    Ich wollte ihn dieses Wochenende auch in der Praxis mit Eutelsat 5.0W testen, nur ist meine alte Selfsat Antenne die dazu verwendet habe offensichtlich nicht geeignet, da sich zw. 8.0W und 3.0W noch 4 weitere Satelliten befinden und die Selfsat, vermutlich durch einen zu großen Öffnungswinkel, alle einfängt und man daher kein stabiles Signal bekommt. Als Satempfänger war eine TBS-5520SE angeschlossen.


    Da es bis zu einem weiterem Versuch mit besserer Antenne etwas dauern wird, stelle ich den Patch einmal ungetestet hier ins Forum. Vielleicht hat ja jemand ein "Auge" auf 5.0W oder eine andere Position die Programme in Multistream/PLS aussendet.


    Helmut

    Wenn auf einem Transponder durch Programmverschiebung oder -abschaltung ein neuer Transportstream aufgeschalten wird, verbleiben die urspünglichen Kanaleinträge aber weiterhin in der channels.conf. Wenn es nur eine 1:1 Verschiebung auf einen anderen Transponder war, erkennt "MarkObsoleteChannels()" zwar irgendwann die ungültigen Programme, wenn aber Nid oder Tid nicht mehr aktiv sind klappt das so nicht mehr.

    Der Patch im Anhang überprüft nun, ob die in der NIT angegebene Netzwerk- und Transportstream-ID mit den Werten des Programms der auf diesen Transponder getuned hat noch übereinstimmen. Falls nicht, werden alle Programme mit ungültiger Nid oder Tid für diesen Transponder als "OBSOLETE" markiert.

    Damit der Eitscanner nichts übersieht, wird nun für jede Transponder/Nid/Tid Kombination ein eigener Channels Eintrag in die ScanList aufgenommen.


    Bei mir hat es doch einige "Karteileichen" zum Vorschein gebracht.

    Wer es testen will: zuvor die die channels.conf sichern, alle bereits von VDR als "OBSOLETE" markierten Programm entfernen und einen EPG Scan starten

    Helmut