Transedit + 2 Probleme auf Hotbird

[Scan_Speedy]

Hallo @Griga mir ist ein neues Problem aufgefallen, und zwar machen seit 3 Tagen 2 Hotbird Transponder von nc+ Probleme.

Einmal 11278 V und 11488 H.

 

Nach den 15 Sekunden SDT Timeout bricht Transedit ab, und beide Transponder haben keine Sendernamen.

Der Analyzer aber hat nach gut einer Sekunde die Namen der Sender erkannt.

Ich hab mir SDT und PAT angeschaut, finde aber nix komisches, hänge mal die XML Datei an, da ich nicht weiß, ob du Hotbird empfangen kannst.

 

Hab es mit 2 Versionen probiert.

4.2.0.5 und 4.1.2.0

Hot Bird 13.0°E 11488 H_01.xml

[Griga]

4 hours ago, Scan_Speedy said:

hänge mal die XML Datei an, da ich nicht weiß, ob du Hotbird empfangen kannst.

 

Ich kann Hotbird notdürftig empfangen, aber mit meiner 45 cm Schüssel leider die beiden Transponder nicht.

 

Was in der XML auffällt:

 

  <Hot_Bird_13.0_E_11488_H>
    <Transponder>
      <Network String="Hot Bird 13.0°E"/>
      <Frequency FValue="11488" Unit="MHz"/>
      <Polarisation String="H"/>
      <Symbolrate Value="27500"/>
      <Modulation String="QPSK DVB-S"/>
      <FEC String="5/6"/>

 

Die Parameter sind teilweise falsch. Richtig ist (auch laut anderen Quellen wie LyngSat und FlySat) Modulation 8PSK DVB-S2, FEC 3/4. Das ist das Problem mit DVB-Geräten/Treibern, die Parameter automatisch erkennen (welches bei dir?): Man merkt nicht, wenn sie falsch in der Transponderliste stehen

 

Allerdings hat dies eigentlich nichts mit der SDT zu tun. Aus der XML ist für mich nicht ersichtlich, warum der Scanner sie nicht lesen kann. Für eine weitere Analyse wäre ein Transponderdump (via WeTransfer) nützlich. 30 bis 60 Sekunden sollten reichen. Enthalten sein sollten die SI-Tabellen (PAT, PMT, SDT, NIT) sowie zumindest ein Video Stream mit PCR (z.B. der von CANAL+1 HD), damit TransEdit hier die Datei in Echtzeit lesen kann.

 

[Scan_Speedy]

ich hab 15 MB aufgenommen, und auf meinem Webspace hochgeladen, url schick ich dir per PM ;)

[Griga]

10 hours ago, Scan_Speedy said:

ich hab 15 MB aufgenommen

 

Damit ließ sich die Angelegenheit klären. Dass etwas mit der SDT nicht stimmt, sieht man auch im Analyzer: Rechtsklick auf den SDT-Eintrag in der Baumansicht -> Table Stats -> SectionNumber = 0 aufklappen -> SectionLength = 1049 Bytes. Eine so lange Section ist nach den Spezifikationen nicht zulässig (ETSI EN 300 468  V1.16.1, Abschnitt 5.2.3 Service Description Table (SDT)):

 

Quote

section_length: This is a 12-bit field, the first two bits of which shall be "00". It specifies the number of bytes of the section, starting immediately following the section_length field and including the CRC. The section_length shall not exceed 1 021 so that the entire section has a maximum length of 1 024 bytes.

 

Der Scanner arbeitet mit 1024 Byte Puffern für PAT, PMT und SDT. Deshalb droht bei der fehlerhaften SDT Section ein Pufferüberlauf. Dieser wird zwar durch Kürzen der Section auf 1024 Bytes vermieden, aber daraus resultiert gleich das nächste Problem: Nebst anderen Daten fehlt auch die Prüfumme (CRC) am Ende. Der Scanner nimmt deshalb die letzten 4 Bytes am Pufferende als Prüfsumme, die natürlich nicht stimmt. Deshalb verwirft er die gesamte Section.

 

Durch Ausschalten von Settings -> General -> Drop SI table sections with wrong CRC kannst du das verhindern. Dann zeigt der Scanner die Sendernamen an, außer beim letzten Eintrag (ServiceID = 5199 - Eleven Sports 2 HD). Der Name passt nicht mehr in den Puffer.

 

Der Fehler liegt hier also beim Anbieter CANAL+ bzw. bei dem von ihm verwendeten Encoder. Er müsste die SDT auf zwei Sections verteilen. Der Analyzer kommt aufgrund eines anderen Funktionsprinzips mit dem Fehler zurecht. Gut wäre, wenn er auf solche Fehler aufmerksam machen würde. Das wäre jedoch eine Heidenarbeit, da es sehr viel gibt, das (theoretisch) falsch sein kann.

 

[Scan_Speedy]

ok danke für die Erklärung

 

Gehe ich richtig in der Annahme, das wenn dort z.b. 1 Sender gelöscht werden würde, das dann die Länge des Eintrages sich reduzieren würde ?

Ich hab erstmal den Haken wie oben beschrieben raus genommen, mal sehen ob dadurch nun woanders neue Fehler entstehen

[Griga]

20 minutes ago, Scan_Speedy said:

Gehe ich richtig in der Annahme, das wenn dort z.b. 1 Sender gelöscht werden würde, das dann die Länge des Eintrages sich reduzieren würde ?

 

Wenn der Anbieter einen Sender aus der SDT rausnimmt, reduziert sich die Länge der Section. Oder wie meinst du das?

 

21 minutes ago, Scan_Speedy said:

Ich hab erstmal den Haken wie oben beschrieben raus genommen, mal sehen ob dadurch nun woanders neue Fehler entstehen

 

Ohne den Haken sind Scanner und Analyzer nicht mehr so gut gegen Datenmüll geschützt, der z.B. durch Empfangs- oder sonstige Störungen eintreffen könnte. Das könnte zu verfälschten Scanergebnissen und schlimmstenfalls zum Absturz führen. Es hängt auch davon ab, wie DVB Hardware und Treiber mit nicht korrigierbaren Paketen umgehen, d.h. ob sie sie einfach an die Anwendung weitergeben oder weglassen oder markieren (dann lässt sie TransEdit weg) - kleinere Störungen kann die Hardware ja mit Hilfe der FEC ausgleichen.

 

[Scan_Speedy]

vor 12 Minuten schrieb Griga:

Wenn der Anbieter einen Sender aus der SDT rausnimmt, reduziert sich die Länge der Section. Oder wie meinst du das?

ja das war meine Vermutung, und der Scan eben bestätigt meine Vermutung.

Nach dem Haken entfernen und scannen sind auf dem einem nc+ TP 7 weitere Clone drauf.

Vermutlich ist dadurch die SDT so angewachsen, das die Datenmenge die 1048 überschritten hat.

Zumindest passt das nun gut zusammen.

[intell]

Hallo, habe testhalber diese 2 Transponder via Client gescannt,

bei mir alles einwandfrei (4.3.0.0)

Preview geht auch.

Beste Grüße

11488.ini 11278.ini

[Scan_Speedy]

vor 20 Stunden schrieb intell:

Hallo, habe testhalber diese 2 Transponder via Client gescannt,

bei mir alles einwandfrei (4.3.0.0)

 

hi, ich hab die Version mal runter geladen, und kann bestätigen das es damit klappt

danke für den Hinweis

[MaDu]

Bei meinem Testscan am 08.08.2022 mit TranEdit 4.3.0.0 trat bei mir der gleiche Fehler auf, wie bei deinem Scan vom 07.08.2022 mit TranEdit 4.2.0.5 und 4.1.2.0, d. h. die unterschiedlichen TransEdit Versionen haben in diesem Punkt offensichtlich kein unterschiedliches Verhalten.

 

Es scheint vielmehr so zu sein, daß zwischenzeitlich die senderseitigen Fehler behoben worden sind.

 

MaDu

 

[Scan_Speedy]

vor einer Stunde schrieb MaDu:

Es scheint vielmehr so zu sein, daß zwischenzeitlich die senderseitigen Fehler behoben worden sind.

du hast recht, ich hab es mal untersucht, nc+ hat es gefixt, indem es nun 2 Einträge gemacht hat