Gert Deutschsprachiger Support > TS-Doctor 2.x

Probleme beim Verarbeiten einzelner 192er-m2ts-Streams

(1/2) > >>

tsduser:
Moin,
nach Jahren der TSDoctor-Nutzung in diversen Versionen ist auch mir nun ein kleineres Problem aufgefallen. Entdeckt habe ich es in der aus bereits erwaehnten Gruenden weiterhin verwendeten Version 2.1.44; es existiert aber identisch noch immer in der momentan aktuellen 3.1.11 (zumindest bei der Trial in einer VM; ich habe aber nicht den geringsten Zweifel, dass eine lizensierte Version die gleichen Falschmeldungen produzieren wuerde).

Betroffen sind einzelne m2ts-Aufnahmen (entgegen dem Namen sowohl SD wie auch HD) mit 192 Byte Packet Size:

Wenn die vier zusaetzlichen m2ts-Bytes am Anfang der ersten Pakete in der Datei mit 0x47 (eigentlich ja der Hinweis auf einen Paketstart) beginnen, kommt der Doctor komplett aus dem Tritt, und mit ihm ebenso die enthaltenen Raw Cutter und Packet Viewer.

Der Doctor meint zu einer solchen Datei beispielsweise, dass die PMT fehle, und eine neue nicht erstellt werden koenne, oder bleibt bei 99% PCR-Check "ohne Rueckmeldung" haengen.
Der Packet Viewer in 2.1.44 bricht beim Laden mit der Meldung ab, dass nicht ausreichend Hauptspeicher zur Verfuegung sei.
Der Packet Viewer in 3.1.11 laedt die Datei, aber mit 188 Byte Packet Size, und damit sind natuerlich alle Pakete "rot" (bis er sich irgendwo irgendwie auf 192 Bytes synchronisiert).
Der Raw Cutter meint, dass die Datei nicht "mir" (dieser Tippfehler in der 2.1.44 ist auch in der 3.1.11 noch nicht korrigiert) gueltigen TS-Daten beginnen wuerde, und will auf TS-Packetgroesse von 188 Bytes zu"recht"schneiden.

Der Doctor an sich verhaelt sich leider auch noch unterschiedlich; je nach dem, was sonst in der Datei so vorhanden ist. Die Packet Viewer und Raw Cutter sind dagegen verhaltens-konsistent.

Wenn man (wie es ja auch im Wikipedia-Artikel zum TS-Datenstrom beschrieben steht) in den ersten 5 Paketen der Datei die 0x47 in z.B. 0x46 aendert, ist die Datei ploetzlich komplett fehlerlos. (Die restlichen 0x47-Anfaenge duerfen dann gerne drinbleiben, und verursachen keine Probleme.)
Auf demselben Wege laesst sich selbstverstaendlich auch eine "fehlerbehaftete" Testdatei erstellen: Einfach ein paar 192er-m2ts-Pakete am Anfang mit 0x47 beginnen lassen -> Bumm!

Vielleicht verhalten sich ja auch meine Billig-Xoro-Receiver falsch, und die 30 Timer-Bits in 192er-m2ts-Packets duerften laut Spezifikation ueberhaupt nicht mit 0x47 beginnen. Dazu habe ich allerdings bisher nix gefunden.

OK, ich sehe ein, dass das Problem wahrscheinlich VU+-Verwender (fuer die der Doc zumindest in letzter Zeit leider hauptsaechlich entwickelt zu werden scheint) nicht betrifft, aber so einer bin ich halt nicht.
Ebenso betrifft es nur Aufnahmen, die aus mehreren Teilen bestehen, denn sonst beginnen die vier zusaetzlichen Timer-Bytes in den 192er-Packets ja immer mit "00 00 00 00", und wenn irgendwann spaeter im Verlauf laengerer Aufnahmen dann doch mal 0x47-Packets auftreten, sind die Entscheidungen zum erkannten Format lange schon in Stein gemeisselt.

Mir ist auch klar, dass eine Korrektur, so sie denn vorgenommen wuerde, nicht in den Code von 2.1.44 einfliessen wuerde, aber wenn ich bedenke, wie viele Dateien ich in der Vergangenheit als defekt verworfen habe, obwohl nur der Doc ueber so eine winzige Lappalie gestolpert ist, wollte ich's zumindest mal berichten.
Und jetzt habe ich ja auch eine "Q&D"-Loesung.

Danke fuer's Lesen bis hierher.

Cypheros:
Welcher Xoro ist denn das?

tsduser:
Beobachtet habe ich es sowohl auf HRK8772Twin wie auf HRK7672Twin; die verwenden beide dasselbe Aufzeichnungsformat (5-stellige numerische Ordnernamen in Vaterordner "REC", 4GiB-Dateien .ts, .ts1, .ts2, ... und ein paar kleinere weitere inkl. Beschreibungs-.txt).
Ein HRK8750 speichert zwar auch 4GiB-Dateien, aber im 188-Byte-Format (ALi3).
Ein HRK7520 duerfte ebenfalls nicht betroffen sein; der speichert auf NTFS Dateien auch groesser als 4GiB.
Ein HRK8910 (oder so; ich habe zwei entsprechende Techwood-"Clones") verwendet ganz andere Formate (und kein NTFS).
Mein Samsung-Fernseher legt ebenfalls 188er-Dateien groesser 4GiB "en bloc" auf NTFS ab.

Kiraly-Cutter:
Der HRK8772Twin wird bei https://www.xoro.de/downloads nicht angegeben.
Soll das vielleicht der HRT 8772 TWIN sein ?

tsduser:
Jepp, stimmt, sorry, ein Tippfehler.
Beide (der HRT8772 und der HRK7672) sind sozusagen "Zwitter": Sie verwenden dieselbe (aktuelle) Firmware-Version, und lassen sich zwischen Kabel-Empfang und DVB-T2 umschalten. Ich verwende aber die "Kabel"-Einstellung. Es waere zwar moeglich, dass die je nach Einstellung unterschiedliche Aufzeichnungsformate fuer die abgelegten Dateien verwenden, aber ich vermute: eher wohl nicht.

Und mit dem Verhalten des Doc hat die exakte und korrekte Bezeichnung des verwendeten Receivers doch auch nicht soooo viel zu tun, nahm ich an, und hatte es in meinem Eingangspost nicht explizit erwaehnt ;-)
Selbstverstaendlich kann ich auf Anfrage auch gerne noch weitere Details liefern.

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln