Kaputte Aufnahme heilen

Ist kommerziell, aber TS-Doctor könnte da der komfortabelste Weg dafür sein. Lässt sich 30 Tage in Ruhe ausprobieren...

mit mkvtoolnix gehts auch ohne kosten Blödsinn! AVI Demux ist das richtige Tool das ich meine sry

aber Frage wäre glaube besser: Was kann man tun, damit das nicht passiert seitens TVH?

Also ich kann nur aus meiner Erfahrung sagen: Schwierig bis unmöglich.

TS Doctor kostet und ist immer ein Behandeln der einzelnen Datei, also aufwändig.

h265 noch schwieriger.

Alle meine Reparaturversuche sind in Dateien geendet, die nicht besser waren als vorher - oder, wie schon beschrieben, die nicht spulbaren Stellen einfach herausgeschnitten wurden.

Zu TVH: Ja, das produziert bei "Pass" fast schon zwangsläufig defekte Dateien, weil man ja einfach reinschluckt was über z. B. SAT reinkommt.

Ich habe teils einfach on the fly encodet, oder später mit besseren Einstellungen nachträglich encodet, das führt insgesamt zu besseren Ergebnissen, aber letztendlich... kann man da Stunden und Tage investieren.

Richtig zufrieden war ich nie.

omg da hat mein Hirn aber Blödsinn verzapft! Ich meinte AVI Demux - damit kann man die Aufnahmen schneiden oder auch einfach speichern und dann funzt das Spulen wieder.

Avidemux - Main Page

Mich wuerde so eine kapute Datei mal interessieren. Ich habe ja kein TVH, kann mir also im Moment nicht vorstellen, was da "kaputt" gehen kann.

Bei meinem VDR habe ich ja das Problem das da wirklich TV Pakete verloren gehen koennen. Ich vermute das ist PCI Bus Problem, aber noch nich dazu gekommen, das zu diagnosizieren. Solle wohl aehnlich sein, als wenn ich eine SA-IP Kiste haette und da UDP Pakete im Netz verloren gehen wuerden.

Auf jeden Fall sortiere ich die Dateien aus indem ich nach Discontinuity counter fehlern suche und wenn mich die Aufnahme wirklich interessiert gucke ich wie schlimm das ist. Wenn da halt zuviele Pakete fehlen bringt es ja nix. ffmpeg kann die zwar inzwischen prima konvertieren, aber da ist dann halt das Bild zu den Stellen, wo was fehlt muellig. Aber zumindestens scheint ffmpeg seit einigen Jahren (3?) jetzt wenigsten Bild und Ton nach solchen Fehlern richtig zu resynchronisieren.

Waere auch interessant zu wissen, was TS-Doctor da besser machen koennen sollte. Ist ja keine AI, die sich Ersatzbilder ausdenken koennte...

TS ist nicht gleich TS. Diesen Teil (er)kennen viele Nutzer nicht und melden dann "Mein Player XY spielt die Aufnahme nicht ab", " Die Aufnahme ruckeln..." o.ä. Auch "Meine Aufnahmen sind kaputt..." habe ich da schon gelesen.
An der Stelle setzt TS-Doctor als erstes an und bringt es in einen konformen TS-Datenstrom. Welche Sonderlocken die Receiver beim Aufnehmen durch manipulierte Zeitstempel, Metadaten u.ä. verursachen kann ich jetzt nicht im Detail fundiert wiedergeben.
Für SD-Aufnahmen konnte man früher Cuttermaran mit entsprechendem Toolset aus ProjectX und tsmuxer verwenden um Aufnahmen framegenau zu schneiden. Bei dem Prozess fielen automatisch auch defekte TS-Aufnahmen auf und die Metadaten wurden korrigiert. HD Datenströme kodiert als H.264/H.265 sind für solche framegenauen Manöver nicht geeignet und man muss den gesamten Datenstrom re-encoden. Daher wurde Cuttermaran da wohl auch nie mehr weiterentwickelt.
Dennoch versucht der Autor von TS-Doctor die Eingriffe so wenig invasiv wie möglich zu gestalten. Dazu gehört auch die Korrektur von Metadaten die das Abspielen verhindern, Ausgleich von Zeitversatz und Korrektur von defekten Blöcken. Manches sind anscheinend "Lunker" im Audiostream durch die Sender selbst verursacht. Wenn es ein oder mehrere kostenlose Tools gibt, welche dies adäquat genauso können, spricht doch nichts dagegen dabei zu bleiben.
Die Frage war "Wie kann ich am einfachsten ..." - nicht "Wie kann ich für Lau ..."

Bei Eurer Grundsatzdiskussion über TS-Aufnahmen, dürft ihr den Empfangsweg nicht außer Acht lassen. TS-Datenströme in sich sollten normalerweise fehlerfrei und genauso fehlerfrei auf dem Aufnahmegerät abspielbar sein. Beim Transfer zum und späterem Abspielen am PC o.ä. spielen die restlichen Gimmicks wie Zeitstempel und Metadaten meist eine Rolle. Netzwerk kommt aus meiner Erfahrung erst zum tragen, wenn die Aufnahme direkt aufs File Share (NFS/SMB) erfolgt.
Sollte SAT als Empfangsart in Verwendung sein, ist das viel häufiger auftretende Problem, dass ein 2. Tuner der an der selben SAT-Verkabelung (gleicher LNB/Switch) angeschlossen ist beim Zu/Wegschalten "Pixelgewitter" verursacht. Ursache ist die schlechte Entkopplung der verschiedenen Ausgänge am Quad-LNB oder MultiSwitch untereinander. An diesen Stellen sind die TS-Datenströmen unweigerlich korrupt und Tvheadend würde entsprechend nur "Datenmüll" auf die Platte schreiben.

Zitat von Commerzpunk

TS Doctor kostet und ist immer ein Behandeln der einzelnen Datei, also aufwändig.

Ich habe das (für meine Umgebung) so automatisiert:

set DSTDIR=e:\Videos
mkdir ots
for %%f in (*.ts) do (
"c:\Program Files (x86)\Cypheros\TSDoctor3\TSDoctor.exe" "%%f" Autofix "%DSTDIR%\%%f"
move "%%f" "ots\%%f"
)

Man befindet sich grade in dem Verzeichnis mit kaputten ts. TS Doctor soll versuchen, die alle zu fixen und schreibt sie in das Verzeichnis das in der ersten Zeile mit DSTDIR gesetzt wird.

Tlws. andere Fehler kann ffmpeg selbst korrigieren. Nicht sicher, ob du das oben so probiert hast - du hast ja gleich auch mkv erstellt. Ich hoffe, ich kriege die Kommandozeile auf Anhieb hin ... Idee ist halt, die kaputte Datei zu lesen, und ohne Recodierung neu zu schreiben. Ohne Automatisierung als Kommando zum testen.

ffmpeg -y -i kaputt.ts -map 0 -c copy repariert.ts

Leicht kann man das ähnlich wie TS Doctor Beispiel oben weiter automatisieren. Fürchte allerdings, nach deinem Eingangspost, brandtan, dass es in deinem Fall nicht geht.

Es gibt eine fiese Regression im Linux Kernel das CIFS-Modul betreffend:
[REGRESSION] Corruption on cifs / smb write on ARM, kernels 6.3-6.9 - James Young

Ich vermute Du hast ein aktuelles LE im Einsatz und damit einen 6.6er Kernel oder ggf. eine andere betroffene Kernel Version > 6.2.16 und < 6.10.9. Das dort beschriebene Phänomen ist nicht auf die ARM-Plattform (RPi) beschränkt, sondern nur zufällig die Testplattform. Auf meinem Desktop-System konnte ich ein ähnlich gelagertes Verhalten nachstellen, bevor ich den Eintrag aus dieser Mail-Liste gefunden habe. Keine Angst, gibt noch mehr davon. https://lore.kernel.org/linux-cifs/9bc…p.fastmail.com/
Bei mir sorgte dieser Bug für ca. 1 halbes Jahr lang für korrupte Downloads mehrerer ca. 2GiB Firmware-ZIPs (Offline-Update) für unseren Fernseher beim direkten Speichern auf das NAS via SMB-Mount. Lokales Speichern und nachträgliches Kopieren mit cp oder mv hat den Fehler nie nachvollziehbar getriggert. Diese Downloads (Rechner- und Browser-unabhängig) allerdings schon. Der gleiche Download via Windows durchgeführt war wiederholbar fehlerfrei. Testdownloads mit anderen großen Dateien wie ISOs waren nicht geeignet um es regelmäßig zu provozieren.

Also bevor sich Meldungen häufen: "Habe es gerade probiert, bei mir geht es ohne Probleme." Reicht nicht als Testcase.

Wen es interessiert was in den Dateien verändert war: Die korrupten Stellen in den ZIP-Files waren an unterschiedlichen Stellen immer durch 0x00 Bereiche ersetzt. Bei jedem Downloadversuch an anderen Stellen. Für einen TS-Stream ist sowas natürlich Gift.

In meinem Fall mit 6.5 und 6.8 Kernel hatte ich mir einen Workaround erarbeitet. Den Cache für das Mount abschalten. Das kannst Du ja mal probieren und in Deinen Mount-Optionen unterbringen "cache=none". Wenn Du diesen Mountpoint nur zum Herausschreiben der Aufnahmen verwendest, sollte der Performanceverlust nicht ganz so ins Gewicht fallen. Beim Auflisten von großen Verzeichnisstrukturen mit vielen Ordner/Dateien ist es allerdings spürbar.

Auf meinem Desktop bin ich auf Kernel 6.11. gewechselt, seitdem komme ich wieder ohne diesen Workaround aus. Daher meine Annahme, es handelt sich um die selben Bugs die James Young und Zack Weinberg dort ausführlich beschreiben.

NFS ist auch nicht zwingend fehlerfrei, könnte aber dieses SMB-Problem umschiffen. Ob eine schnelle SD-Karte mit genügend Kapazität für mindestens 2 Aufnahmen auf einem RPi3 für eine Gegenprobe ohne File-Share schnell genug angebunden ist, kann ich gerade nicht einschätzen ...

Da ist ja echt heilige Scheisse! Danke!

brandtan Du solltestest versuchen, herauszufinden, woher die Aussetzer in Deinen Dateien kommen. Es kann sein, das diese Aussetzer gar nicht unvermeidbar sind, sondern auf ein Problem mit Linux und SMB zurückzuführen sind.

Wie genau wurden die Aufnahmen mit den Problemen gemacht:

Auf welchem Linux/Kernel-Version laeuft dein TVH ?

Wurden die Dateien bloss auf lokale Filesystem auf dem TVH geschrieben, oder wurden die auf ein Filesystem geschrieben, was SMB ist und z.b. Platten auf einer NAS sind ?

Und das wäre nur die Fehlerquelle, die HarryH aufgetan hat. Auch andere Fehlerquellen fuer Aussetzer sind häufig vermeidbar.

Außer halt, Dir geht es bloss um alte existierende Aufnahmen, aber so hat sich das bei Dir für mich nicht angehört...