ts-Videos bleiben hängen, auch nach TS-Doctor-Reparatur

[dbenn]

Hallo,
Ich mache viele Aufnahmen mit einer Macrosystem Enterprise in HD und exportiere sie dann auf eine NAS oder Festplatte im nativen Format (ts). Seit neuestem bleiben viel davon nach ein paar Minuten hängen, wenn ich sie von Festplatte oder Stick abspiele, auch wenn ich die Files über einen WD TV Live-Player abspiele (mein TV kann keine ts lesen) - der WD TV Live bleibt einfach stehen und schaltet den File dann ab, auch beim Vorlauf.
Das gleiche passiert, abgespielt über BD-Player (via USB). Und selbst abgespielt mit dem VLC am PC oder Mac spinnen die Filme nach exakt der gleichen Zeit, auch nach schnellem Vorlauf. Sie spielen dann zwar noch (mit VLC), die angezeigte Zeit spinnt aber (zeigt stets "0:00:00") und der Vorlauf geht nur langsam.
Genauere Analyse der Files zeigte, dass dies wohl bei den Werbungs-Ausschnitten passiert, die ich ebenfalls mit der Enterprise mache (geht super-einfach), allerdings wohl erst, seitdem deren Festplatte ziemlich voll war.
Mit Power-DVD laufen die Filme danach zwar weiter, es zeigt sich aber an der Problem-Stelle ein starker Zeitsprung, etwa von 0:08:11 auf 0:17:26, also ca. 9 min., was tatsächlich etwa dem "ausgeschnittenen" Werbeblock entsprechen kann.
Auch nach ts-Doctor-Reparatur ändert sich daran nichts, obwohl ich diesen - nach einer Empfehlung des Administrators - bereits auf "Immer Patchen" eingestellt habe (war wegen eines anderen Fehlers).
Während der TS-D.-Korrektur zeigt sich im Lauf-Diagramm ein gelber und roter Strich, zudem startet der File bereits bei 19 Min.; bei erneuter Korrektur des korrigierten Files startet er zwar richtig, es zeigt sich nur noch ein gelber Strich, aber die Zeit spring ebenso von 8 min. auf 17 min., sie wurde also nicht angepasst !
Auch die Analyse der .log-Datei, die der TS-Doctor erzeugte, zeigt ähnliches: "TS Warning: ..for ... 0:08:11.475 TS packet.. packet discontinuity..." - siehe Anhang.
Er erkennt also den "Zeitsprung" im Stream, korrigiert die Zeiteinstellsprünge aber nicht.
Durch Zufall fand ich gerade heraus, dass die Files wieder problemlos und mit RICHTIGER Zeitanzeige auch mit z.B. dem VLC laufen, wenn ich sie mit dem tsMuxer erneut in eine ts-Datei "wandele".

Was mache ich oder der TS-Doctor da falsch?

Ich hänge mal die log-Datei des unkorrigierten (...fixed) und des TS-Doctor-korrigierten (...fixed_fixed) Files an (sollte jedenfalls geklappt haben).

[Djfe]

versuche mal erst zu fixen und dann in einem zweiten Durchlauf zu schneiden
eventuell läuft da was mit nicht ganz richtig was erst korrigiert werden sollte

[Cypheros]

Die Receiver von Technisat produzieren ähnliche Fehler, da sie beim Schneiden auch einfach nur Bereiche weglassen ohne die dahinterliegenden Timer zu korrigieren. Das bringt die meisten Player aus dem Konzept.

Probier mal die aktuelle Beta-Version, die hat einen Detektor für solche Sprünge und kann diese dann korrigieren:
[attachimg=1]


Allerdings wird immer nur ein Sprung pro Durchlauf korrigiert. Hast Du mehrere Sprünge, sind evtl. mehrere Durchläufe nötig. Falls Du mir mal so eine Aufnahme (mit allen dazugehörenden Dateien) zukommen lassen könntest, würde ich versuchen diese Aufnahmen zu identifizieren und wie die Technisat-Aufnahmen separat zu handhaben.

[dbenn]

Hallo, Cypheros,
Erst mal danke für die prompte Antwort. Ich habe den File jetzt mal mit der neuen Beta 1.2.94 repariert, das Ergebnis ist eher gemischt: abgespielt mit dem VLC (mein Standard, neueste Version 2.1.0) spinnt er beim Vorlauf ab der Problemstelle nach wie vor rum, die Zeitanzeige zeigt nur "0:00:00" und der Vorlauf/Rücklauf funktioniert kaum noch. In Play macht der VLC den gleichen Zeitsprung wie zuvor (8min -> 17 min.), spielt aber immerhin ab.
Power-DVD zeigt zwar nicht die genaue Spielzeit an (ca. 1 min. zuviel), spielt aber jetzt OHNE Zeitsprung den File ab.
Das Schlimmste aber: Abgespielt mit meinem Mediaplayer (WD-TV Live) bleibt der korrigierte File genauso hängen wie zuvor, im Vorlauf und in Play, und der Player schaltet ihn ab. Das passiert, wie gesagt, nicht mit einem per tsMuxer korrigiertem File. Ich würde zwar lieber meine ts-Files mit dem Doctor reparieren, denn ich habe lifetime-lang dafür bezahlt, frage mich aber langsam, was er mir in der Praxis bringt, wenn er schon Zeitfehler im Stream nicht zuverlässig korrigiert, die ein kostenloses Set wie der Muxer problemlos behandelt.  Aber noch gebe ich die Hoffnung nicht auf.
Angehängt ist nun die log der neuesten Korrektur.
M.f.G. 
Dietrich Benn,
Tester UE

[Cypheros]

Hi, da ist immer noch ein Sprung drin laut Log:

Strange PCR Jump: 19:42:08.076 -> 19:52:19.575

Kommt da nicht auch die Meldung mit dem Timer-Sprung?

[dbenn]

Hallo, Admin,
In dem File waren womöglich mehrere Sprünge, da ich ja auch mehrfach Werbung rausschnitt. Aber um spätere Fehler geht es hier nicht, sondern um den Sprung nach 8:11 Min. nach 17 Min., der nach wie vor drin ist, wie ja auch der Log-File zeigt:
"T

[Cypheros]

Schau Dir bitte nochmal mein erstes Post an, da habe ich erwähnt, dass nur ein Sprung pro Durchlauf entfernt wird. Wenn Du 3 mal die Werbung rausgeschnitten hast, dann musst Du die Datei 3 mal fixen.

Sorry für die Umstände aber bisher kenn ich solche Fehler nur von Technisat-Receivern und für die habe ich eine spezielle Erkennung mit anschließendem Fix eingebaut. Dein Receiver macht das offenbar noch etwas anders und der TS-Doctor kennt diese Art von Problemdateien noch nicht.

Kommt beim erneuten Öffnen der gefixten Datei nicht wieder dieser Dialog? Du musst solange weiter machen bis alle Sprünge beseitigt sind.

[dbenn]

Leider wurde der grösste Teil meiner Antwort nicht übertragen, alles nach dem "T". Da hatte ich einfach den entsprechenden Teil des log-Files einkopiert. Aber offenbar geht das nicht (nach der Übertragung) wegen wechselnder Schriftarten. Ich probiere es jetzt nochmal, ohne log-Kopie:
Es geht mir nicht um spätere Zeitsprünge, nur um den ersten, den bei 8:11->17:26 (wie unten erklärt, gibt es gar keine weiteren).

Ich vergleiche mal beide log-Files, also den beim ersten Durchlauf ("...fixed-neu") und den bei der Korrektur des korrigierten ("...fixed-neu_fixed"):
Im ersten log-File erkenne ich 3 "TS Warnings":
1. "For 00:08:11 TS packet... packet discontinuity";
2. Ein "PCR Timing"-Problem bei 19:42:08 -> 19:52:19 Std.;
3. For 00:17:26 TS packet... packet discontinuity".
Die erste Warnung bezieht sich offenbar auf den "echten" Anfangszeitpunkt der Schnittstelle und die 3. auf den Endzeitpunkt des Schnittes; die 2. "Warning" ist der falsche Startzeitpunkt des Streams von 19:34:09 Stunden statt 00:00:00. Soweit ich das verstehe, gibt es also überhaupt nur diesen einzigen Zeitsprung im Stream.

Dieser steht aber auch nach der Korrektur noch immer im log, jetzt ist er allerdings "nur" noch ein "PCR Timing"-Problem und nicht mehr eine 2-malige "Packet discontinuity" wie zuvor. Ebenso ist bei der 2. Korrektur im Durchlaufbild immer noch der gelbe Strich zu sehen an dieser Stelle (bei 8:11 min.), was auch immer heir gelb bedeutet.

Man sieht also, dass im ersten Durchlauf schon einiges korrigiert wurde, u.a. wurde der falsche Anfangszeitpung von 19:34:09 Stunden auf 0 gesetzt. Dadurch verschob sich die Zeitangabe des von Ihnen oben erwähnten Zeitsprungs bei 19:42:08 -> 19:52:19 auf den (auch von anfang an erkannten) von 00:08:11 -> 00:17:26.
Allerdings ist der eben immer noch drin, auch nach der Korrektur, wie das erneute "TS Warning" zeigt. Und das ist das Problem.

Ich hänge mal beide logs an, vielleicht hilft das bei der Analyse und eventuellen Korrektur weiter. Danke nochmals für Ihre Hilfe.

[Djfe]

Da hatte ich einfach den entsprechenden Teil des log-Files einkopiert. Aber offenbar geht das nicht

beim nächsten Mal versuch einfach für einzelne Log-Ausschnitte, die du nicht als Datei hochladen möchtest den Code Tag zu verwenden ;-) (sorgt auch für Übersichtlichkeit) ->#-Button zwischen Tabelle und Zitat

Die erste Warnung bezieht sich offenbar auf den "echten" Anfangszeitpunkt der Schnittstelle und die 3. auf den Endzeitpunkt des Schnittes; die 2. "Warning" ist der falsche Startzeitpunkt des Streams von 19:34:09 Stunden statt 00:00:00. Soweit ich das verstehe, gibt es also überhaupt nur diesen einzigen Zeitsprung im Stream.

Das ist kein Zeitsprung, sondern ein zurücksetzen der Uhrzeit
für dich als Filmeschauer ist es vollkommen belanglos, dass der Film um 19:34 Uhr aufgenommen wurde
Deswegen setzt der TSD die Zeit zurück
Du musst dir das Programm das gesendet wird als einen endlos langen TS-Stream vorstellen, indem immer durch die Uhrzeit synchronisiert wird, weswegen es logischerweise wichtig ist, dass durchgängig die synchronisierte Uhrzeit mitgesendet wird
(Halbwissen: Hilft eventuell später auch dem Abspielprogramm oder Konverter, wenn dort nicht so komische Zeitpunkte verwendet werden)

Kannst du auch deaktivieren (eventuell wichtig wenn du aufeinander Folge Aufnahmeteile eines Senders zusammenfügen willst)
Optionen->Korrekturverhalten->Timer-Korrekttur (Patchen um bei 0 zu starten)->hier ist vermutlich der Haken per Standard auf "bei PCR Wrap ohne weitere Fragen (empfohlen)" gesetzt

[Cypheros]

Sehe gerade, Du benutzt nocht die Beta 1.2.94. Nimm mal die aktuelle Release-Version 1.2.96, da ist die Erkennung von Sprüngen nochmal verbessert worden.

[dbenn]

Ich habe das Gleiche versucht mit der neuen Beta - es bleibt alles gleich: Bei der ersten Korrektur startet die Zeit bei 19min. und es gibt den besagten Zeitsprung in der Zeitanzeige von 0:08:11 auf 0:17:26.; danach erscheinen noch 3 gelbe Striche im neuen "Fehlerverlauf", den ich als Abbildung ansonsten sehr hilfreich finde.
Lasse ich den korrigierten File nochmals durchlaufen, sind diese zwar weg im "Fehlerverlauf", nur noch einer ganz am Anfang (bei 00:00:00); aber der Zähler zeigt beim Korrektur-Durchlauf immer noch den gleichen Zeitsprung von 0:08:11 auf 0:17:26, ebenso bleiben die Meldungen "Strange PCR jump: 00:07:55 -> 00:18:06" und "TS Warning: PCR Timing last PCR: 0:08:11 current PCR 0:17:26" bestehen, die es im log der 1. Korrektur auch gab.
Der korrigierte File bleibt mit dem VLC im Vorlauf nach wie vor hängen an der Stelle und die Zeit spinnt danach rum (zeigt nur 0:00:00), dasselbe Problem bleibt weiterhin mit den erwähnten Playern.
Auch weitere Durchläufe ändern nichts darein, auch nicht in den log-Files.
Schade, die Sprungstellen werden also erkannt, aber nicht korrigiert.
Auch jetzt hänge ich den log-File der ersten Korrektur wieder an.

[Cypheros]

Hmmm, offenbar wiedersetzt sich diese Aufnahme allen Versuchen einer Reparatur. Gibt es eine Möglichkeit, dass Du mir diese Datei zur Verfügung stellst (am Besten die originale Datei vor der ersten Reparatur)?

Könnte Dir einen FTP-Server zum Upload zur Verfügung stellen oder Dir einen USB-Stick zuschicken.

[dbenn]

Danke für die Antwort und Bereitschaft zu helfen, Cypheros.
Ja, können wir machen per ftp-Server. Ich habe ebenfalls einen (brauche ihn wohl nicht dafür). Ich würde aber einen kleineren Videofile senden (Geschichte Amerikas, Teil 9), der nur 1,2MB hat statt der 2,4MB des erwähnten Files, der aber genau die gleichen Probleme aufweist, wie ich gerade getestet habe:
Im Original sind 2 Zeitsprünge drin und ein Startzeitpunkt bei 21:22:45. Nach der Korrektur stehen die Zeitsprünge auch im log mit "Strange Jumps" und 4 TS Warnings, je eine für Video (00A9) und für Audio (0049).
In der zweiten Korrektur startet der File richtig mit 0:00:00, es sind aber immer noch beide gelbe Linien im Durchlauf drin und Zeitsprünge an den Stellen; im log stehen nur noch 2 "TS Warnings", jetzt nur noch mit "Timing...last PCR ... current PCR." Die Zeitsprung-Probleme sind also geblieben, genau wie bei dem oben beschriebenen File. 
Wie sollen wir's machen? Schreiben Sie mir eine Mail mit der ftp-Adresse oder geht das hier?

Danke und Gruß
Dietrich Benn

[Cypheros]

Hab Dir ne PM geschickt mit den Zugangsdaten.

[Cypheros]

OK, ich weiß nun warum es nicht so funktioniert wie erhofft.

Die Schnitte sind recht kurz und dadurch ist das Delta zwischen den 100 PCR-Testpunkten nicht groß genug um als Sprung identifiziert zu werden.

Mittels RegEdit unter dem Key: "HKEY_CURRENT_USER\Software\Cypheros\TSDoctor\Settings" ein Wert (DWord) anlegen mit dem Namen "PCRScanFactor" und dem Wert 2. Dadurch wird die Anzahl der PCR-Testpunkte verdoppelt und somit auch die Genauigkeit. Dann werden die Zeitspünge auch garantiert gefunden.

Danke für die Beispieldatei, konnte diese mit den genannten Einstellungen reparieren und beide Sprünge beseitigen.

Alte Dauer der Aufnahme: 00:44:24.000 und die Dauer mit den reparierten Sprüngen ist nur noch 00:38:51.503!