MovieCutter

[chris86]

Da du ja beim strippen sowieso eine Kopie anlegst, dachte ich mir, ob es möglich wäre, dass man diese Kopie optional gleich auf die externe HD schreiben könnte?

Wie gut, dass es für genau diesen Zweck in MC 3.6c bereits neu die patentierte All-in-one-Lösung gibt...
Ist von der Bedienung her vielleicht (noch) ein wenig umständlich - aber wenn dir da Möglichkeiten zur Vereinfachung einfallen, sind sie herzlich willkommen!
1.) Aufnahme beschneiden

• Aufnahme wiedergeben und Schnittmarken für Vorlauf, Nachlauf, sowie Werbepausen setzen.
• Menü -> Markieren (2x für "Gerade Segmente")

2.) Zielverzeichnis fürs Kopieren festlegen

• Menü -> Teile kopieren... -> Ziel -> auswählen mit [<] / [>]
• Dann [OK], und den (absoluten!) Pfad des gewünschten Zielverzeichnisses eingeben
  (z.B. "/mnt/sdb1/DataFiles" für externe HDD. Ob auch UNC-Pfade unterstützt werden, weiß ich nicht.)
• Die Eingabe in der eigens in MovieCutter integrierten Tastatur kann erfolgen per Fernbedienung (Pfeiltasten oder Zahlentasten mit T9-Code), per Funktastatur oder per TMS-Remote.

Das hier eingestellte Zielverzeichnis gilt allerdings nur für die Funktionen unter "Teile kopieren". Es hat keinen Einfluss auf die Funktion "Aufnahme strippen".

Schneller geht es übrigens, wenn das NAS-Verzeichnis bereits vorher in der MovieCutter.ini hinterlegt wird.

Code: Alles auswählen

# Alternatives Ausgabeverzeichnis für die Funktion "Teile kopieren" (Standard: Verzeichnis der Aufnahme)
CopyOutDir=/mnt/sda2/DataFiles

3.) Strippen

• Checkbox "mit Strippen" aktivieren.
• Dann die Funktion "Gemeinsam in eine Aufnahme" starten.
  (Das sollte eigentlich auch ohne markierte Segmente funktionieren...)

4.) Ausschalt-Automatik

• Während des Strip-/Kopierprozesses einfach einmal die [PowerOff]-Taste drücken. Es erscheint ein Dialog, der fragt, ob der Vorgang abgebrochen werden soll.
• Lässt man den Dialog stehen, so wird der Vorgang zu Ende geführt, und der Receiver anschließend abgeschaltet.

Tipp:
Über die ini lässt sich auch festlegen, ob beim Strippen zusätzlich auch die EPG-Spur (default: ja) oder die Teletext-Spur (default: nein) entfernt werden soll.
Wenn der Teletext entfernt werden soll, dann werden eventuell vorhandene Untertitel während des Strippens extrahiert und in eine (menschenlesbare) *.srt-Datei geschrieben.
(Bei nachträglichem Schneiden der Aufnahme werden die TimeStamps in der srt-Datei dann aber nicht mehr angepasst...)

Code: Alles auswählen

# Beim Strippen nur die Fülldaten entfernen [0], auch die EPG-Spur entfernen [1], auch die Teletext-Spur entfernen [2], beides entfernen [3]
StripMode=1

Und hier nochmal die Erläuterung zu den zwei Zusammenfüge-Modi:
"Anfügen an gemerkte Rec":
Fügt die gewählten Segmente der aktive Aufnahme an die vorher gemerkte an.
Die vorher gemerkte Aufnahme wird dabei verändert (allerdings nur verlängert - sie wird dabei nicht geschnitten oder gestrippt).
Nur die kopierten Segmente aus der aktiven Aufnahme werden (auf Wunsch) gestrippt.

"Mit gemerkter in neue Rec":
Kopiert die selektierten Segmente aus erst der gemerkten, dann der aktiven Aufnahme gemeinsam in eine neue Datei.
Keine der Original-Aufnahmen wird verändert.
Beim Kopieren werden aus beiden Aufnahmen nur die selektierten Segmente kopiert.
Alle kopierten Teile werden dabei (auf Wunsch) gestrippt.

Die erste Option ist natürlich schneller, da die gemerkte Aufnahme nicht verarbeitet werden muss - jedoch auch unwiderruflich.
Will man viele Dateien (inkl. Strippen) hintereinander kopieren, dann empfiehlt es sich, erst die beiden ersten mit Option 2 zu kopieren, und an diese neue Datei nach und nach die weiteren Aufnahmen anzuhängen.

[chris86]

Vor dem Ausprobieren sollte MovieCutter 3.6c aber nochmal über TAPtoDate komplett neu installiert werden, um den zuletzt hinzugefügten Bugfix für RecStrip mit einzuspielen!!

Oder MovieCutter und RecStrip aus dem zip-Archiv manuell nochmal auf den Topf kopieren. (mit TTD habe ich da im Moment Probleme...)

(Edit: mit TAPToDate sollte es nun wieder funktionieren.)

[chris86]

Es wurden noch ein paar Bugs u.a. im Zusammenhang mit dem Anfügen einer Aufnahme an eine bereits bestehende (Appending) gefixt. Im schlimmsten Fall konnte es passieren, dass falsche Segmente an die Aufnahme angefügt wurden, und die inf der bestehenden Aufnahme konnte überschrieben werden...

Ihr solltet daher RecStrip auf die neue Version 2.2 updaten!!!

Am einfachsten geht das durch Neuinstallation des aktuellen MovieCutter 3.6c Installationspakets (vom 31.08.2017) mittels TAPtoDate. Darin ist die neue RecStrip-Version bereits enthalten.

(Bei manuellem Update bitte auch die MovieCutter.tap ersetzen, da sich der RecStrip-Aufruf leider verändert hat...)

Wie immer freue ich mich über Feedback (funktioniert / funktioniert nicht mit Aufnahmen von xyz, in HD/SD, usw.) und natürlich auch über Fehlerberichte (am besten mit Logfile)...

Und jetzt... viel Spaß!

[macfan]

Gruß, Horst

[Twilight]

twilight

[db1]

Was sagt mir das, das File wurde nach dem Abbruch (reines strippen) als verschlüsselt markiert.

2017-09-07 17:34:20 Attaching to /mnt/hd/DataFiles/external/SciFi/Alien Predator/Alien Vs. Predator.rec
2017-09-07 17:34:20 ----------------------------------------
2017-09-07 17:34:20 Inode Nr = 1341
2017-09-07 17:34:20 File size = 6180151296 Bytes (684857 blocks)
2017-09-07 17:34:20 PacketSize = 192
2017-09-07 17:34:20 Reported total blocks: 684742
2017-09-07 17:34:20 Type of recording: HD
2017-09-07 17:34:21 .nav-file loaded: 4486 I-Frames found.
2017-09-07 17:34:21 First Timestamp: Block=98, Time=0:00:00,002
2017-09-07 17:34:21 Playback Duration (from nav): 1:24:43,613
2017-09-07 17:34:21 Playback Duration (from inf): 1:24:44
2017-09-07 17:34:21 HDD free space = 9116004352 Bytes
2017-09-07 17:34:34 [Action 'Strip movie' started...]
2017-09-07 17:34:35 TAP_EventHandler: State=ST_ActiveOSD, !isPlaybackRunning --> CutFileSave()
2017-09-07 17:34:35 Checking list of suspect inodes (Device=/dev/sdb1, ListFile=/mnt/hd/DataFiles/external/FixInodes.lst):
2017-09-07 17:34:35 -> No ListFile present.
2017-09-07 17:34:37 RecStrip finished.
2017-09-07 17:34:37 RecStrip returned error code 9!

[chris86]

RecStrip macht u.a. das gleiche wie RebuildNav/RecCopy:
Es scannt die Datei nach verschlüsselten Paketen (und kann die Aufnahme ggf. als "verschlüsselt" markieren, um eine Entschlüsselung anzustoßen).

Der Fehlercode 9 besagt, dass RecStrip die Aufnahme als verschlüsselt eingestuft hat.
(Möglicherweise könnte das aber natürlich auch fälschlicherweise geschehen sein.)

Nähere Aufschlüsse könnte hoffentlich die RecStrip.log geben (befindet sich bei der aktuellsten Version im MovieCutter-Verzeichnis, bei früheren im Ordner Settings/RecStripper). Magst du mir diese zukommen lassen?

Super wäre auch, wenn du mir vllt den Anfang der rec-Datei (das erste Megabyte) zukommen lassen könntest? (Bei Bedarf gebe ich gern Hilfestellung beim "Abschneiden") - Zur Not würde es evtl. sogar ein Screenshot von der rec im Hex-Editor (z.B. HxD) tun...

[db1]

Ich habe vor Start des MC die neueste Version von TapToDate aus installiert.

In meinem /ProgramFiles/ gibt es trotzdem kein MovieCutte Verzeichnis.
Die log war hier: /ProgramFiles/Settings/MovieCutter

2017-09-07 17:33:54 *** MovieCutter V3.6c started! (FBLib 2013-02-24+) ***
2017-09-07 17:33:54 =======================================================
2017-09-07 17:33:54 Receiver Model: SRP-2100 (TMS) (22010), System Type: TMS-S (5)
2017-09-07 17:33:54 Firmware: TF-TEST 1.15.77
2017-09-07 17:33:54 Hard disk: WDC WD20EZRX-00D8PB0, FW 80.00A80, Serial: WD-WCC4M6JC7047
2017-09-07 17:33:54 Options: SpecialEnd=only_safe, DoiCheckTest=3, CheckFSAfterCut=1, InodeMonitoring=1
2017-09-07 17:33:54 Checking list of suspect inodes (Device=/dev/sda2, ListFile=/mnt/hd/FixInodes.lst):
2017-09-07 17:33:54 -> No ListFile present.
2017-09-07 17:34:20 ========================================

2017-09-07 17:34:20 Attaching to /mnt/hd/DataFiles/external/SciFi/Alien Predator/Alien Vs. Predator.rec
2017-09-07 17:34:20 ----------------------------------------
2017-09-07 17:34:20 Inode Nr = 1341
2017-09-07 17:34:20 File size = 6180151296 Bytes (684857 blocks)
2017-09-07 17:34:20 PacketSize = 192
2017-09-07 17:34:20 Reported total blocks: 684742
2017-09-07 17:34:20 Type of recording: HD
2017-09-07 17:34:21 .nav-file loaded: 4486 I-Frames found.
2017-09-07 17:34:21 First Timestamp: Block=98, Time=0:00:00,002
2017-09-07 17:34:21 Playback Duration (from nav): 1:24:43,613
2017-09-07 17:34:21 Playback Duration (from inf): 1:24:44
2017-09-07 17:34:21 HDD free space = 9116004352 Bytes
2017-09-07 17:34:34 [Action 'Strip movie' started...]
2017-09-07 17:34:35 TAP_EventHandler: State=ST_ActiveOSD, !isPlaybackRunning --> CutFileSave()
2017-09-07 17:34:35 Checking list of suspect inodes (Device=/dev/sdb1, ListFile=/mnt/hd/DataFiles/external/FixInodes.lst):
2017-09-07 17:34:35 -> No ListFile present.
2017-09-07 17:34:37 RecStrip finished.
2017-09-07 17:34:37 RecStrip returned error code 9!
2017-09-07 17:42:31 ========================================

Im Anhang noch ein zip vom Screenshot vom Anfang des rec-files.

Vielen Dank für deine unermüdliche Hilfe!

[db1]

Uups oben war ja wieder das MovieCutter.log
Hier das RecStrip.log auch aus dem Verzeichnis /ProgramFiles/Settings/MovieCutter

=========================================================
*** RecStrip started Thu Sep 7 17:34:35 2017

Called: RecStrip -s -e "/mnt/hd/DataFiles/external/SciFi/Alien Predator/Alien Vs. Predator.rec" "/mnt/hd/DataFiles/external/SciFi/Alien Predator/Alien Vs. Predator_strip.rec"

RecStrip for Topfield PVR v2.2
(C) 2016/17 Christian Wuensch
- based on Naludump 0.1.1 by Udo Richter -
- based on MovieCutter 3.6 -
- portions of Mpeg2cleaner (S. Poeschel), RebuildNav (Firebird) & TFTool (jkIT)

Parameters:
DoCut=0, DoMerge=0, DoStrip=yes, RmEPG=yes, RmTxt=no, RbldNav=no, RbldInf=no, PkSize=0

Input file: /mnt/hd/DataFiles/external/SciFi/Alien Predator/Alien Vs. Predator.rec
File size: 6180151296, packet size: 192
TS: PMTPID=0x0065, SID=0xef15, PCRPID=0x05ff, Stream=0x1b, VPID=0x05ff, HD=1
TS: TeletxtPID=0x0025
TS: Teletext date: mdj=56985, 02:52:58
TS: EvtStart = Mon Nov 24 01:13:00 2014
TS: EventName = Alien Vs. Predator
TS: EventDesc =
TS: ExtEvent = Forscher entdecken im Eis der Antarktis eine antike Pyramide. In ihrem Inneren treffen sie auf zwei verfeindete Alien-Rassen...
TS: SvcName = RTLII HD
TS: Duration = 84 min 43 sec
TS: StartTime = Mon Nov 24 01:12:00 2014

Inf file: /mnt/hd/DataFiles/external/SciFi/Alien Predator/Alien Vs. Predator.rec.inf
Determine SystemType: DVBs = 0, DVBt = -2, DVBc = -2 Points
-> SystemType=ST_TMSs
INF: VideoStream=0x1b, VideoPID=0x05ff, HD=1

Nav file: /mnt/hd/DataFiles/external/SciFi/Alien Predator/Alien Vs. Predator.rec.nav

Cut file: /mnt/hd/DataFiles/external/SciFi/Alien Predator/Alien Vs. Predator.cut


Output rec: /mnt/hd/DataFiles/external/SciFi/Alien Predator/Alien Vs. Predator_strip.rec
Inf output: /mnt/hd/DataFiles/external/SciFi/Alien Predator/Alien Vs. Predator_strip.rec.inf
Nav output: /mnt/hd/DataFiles/external/SciFi/Alien Predator/Alien Vs. Predator_strip.rec.nav
Cut output: /mnt/hd/DataFiles/external/SciFi/Alien Predator/Alien Vs. Predator_strip.cut


WARNING: Scrambled TS - Scrambling bit at position 1845312 -> packet ignored.
cNaluDumper: TS continuity offset 1 (pos=1845508)
DEBUG: Problem! pos=2600452, offset=507456, Orig-Nav-PHOffset=2590462, Rebuilt-Nav-PHOffset=2083198, Differenz= 1 * 192 + 0
WARNING: Scrambled TS - Scrambling bit at position 2869440 -> packet ignored.
cNaluDumper: TS continuity offset -15 (pos=2870020)
WARNING: Scrambled TS - Scrambling bit at position 2924736 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2925312 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2925888 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2926656 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2927424 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2928192 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2928960 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2929728 -> packet ignored.
ERROR: Too many ignored packets: 10 -> aborted.

[chris86]

Vielen Dank für die ausgiebige Debugging-Info!
Damit lässt sich etwas anfangen...

Wie sich zeigt, enthält deine Aufnahme eine Reihe von TS-Paketen, die als verschlüsselt markiert sind.
Darunter scheinbar mindestens zwei Pakete des Video-Streams und 8 aus anderen Streams. (ab 10 bricht RS seine Arbeit ab)

Die Beobachtung ist insofern plausibel, dass es sich hier um eine HDplus-Aufnahme handelt. Möglicherweise ist diese nicht vollständig entschlüsselt worden?

Ob das normal ist, und was man da macht, kann ich leider nicht sagen, da ich selbst keine verschlüsselten Sender nutze...
Aber das Prinzip ist dasselbe, wie bei RebuildNav / RecCopy.
Vielleicht kann Firebird dazu etwas sagen, wie solche teil-verschlüsselten Aufnahmen zustande kommen, ob das wirklich verschlüsselt oder nur ein falsches Flag ist, und was man da am besten machen kann...?

(Ich gehe mal davon aus, dass sich die Aufnahme - auch ohne CI-Modul - ohne Aussetzer abspielen lässt, oder? - Ansonsten wäre es ja klar, dass sie erst entschlüsselt werden muss...)

[FireBird]

Ich habe mir bisher nicht angesehen, ob so einzeln als verschlüsselt markierte Pakete wirklich verschlüsselt sind. Da in dem Fall aber auch Discontinuities gemeldet werden, nehme ich an, dass zu dem Zeitpunkt ein Senderwechsel stattgefunden hat und der Topf die internen Pfade umgeschaltet hat.

[chris86]

Nein, die Discontinuities entstehen nur, weil die verschlüsselten Pakete ausgelassen werden, und dann natürlich beim nächsten Paket der Counter nicht mehr stimmt...
Aber es ist doch richtig, dass Aufnahmen, die mehrere Pakete enthalten, die als verschlüsselt markiert sind, erstmal durch die Entschlüsselung gejagt werden sollten, oder?

[FireBird]

Wenn alles so funktioniert, wie vorgesehen... db1 kann ja versuchen, eine Kopie anzulegen. Vielleicht sind dann die verschlüsselten Pakete entschlüsselt.

[db1]

Also das ganze ich schon sehr merkwürdig.

Ich fange einmal von vorne an. Normalerweise entschlüssle ich verschlüsselte Sendungen, bevor ich sie auf die externe HD kopiere, außer sie werden unverschlüsselt aufgenommen. Ich verlasse mich da aber auf das gelbe Verschlüsselungs-Symbol in SF und lasse nicht jedes Mal RebuildNAV laufen. Das heißt meiner Ansicht nach war die Aufnahme auf der externen HD entschlüsselt und ich konnte sie auch sicher normal ansehen (habe es aber nicht ohne Modul versucht).

Wann es zu der Verstümmelung kam (siehe 6), weiß ich nicht.

Die Schritte, die ich nachvollziehen kann.
1) Start von MC, Meldung, dass die Nav (oder inf?) rep. wurde (wenn ich mich richtig erinnere).
2) Start von Strippen in MC.
3) Sofortiger Abbruch mit der Fehlermeldung die oben behandelt wurde.
4) Verschieben von der externen HD ins Root der interen HD (Background Copy).
5) Start von RebuildNAV (ich lasse nur das root der internen scannen), keine Wirkung (also kein Verschieben in AutoDescramble) auf diese Datei (sie hat nun aber neben dem gelben $ Zeichen auch das grüne RbN Zeichen).
6) Dummer Weise habe ich nun erstmals versucht die Datei anzusehen und sie ist nun vollkommen "zerstört". Es tritt nach jedem Start oder auch nach einem beliebigen Sprung nach wenigen s eine komplette Verpixelung auf bis es auch zur Verschlüsset Meldung kommt. Die Stellen sind aber wohl nicht verschlüsselt, da egal wohin ich springe, das Bild immer wenige Sekunden normal läuft, und dann erst die Probleme auftreten.
Dass die Datei nicht verschlüsselt ist kann ich auch dadurch sehen, dass ich mir die *.rec am PC mit dem VLC Player ohne Störungen ansehen kann.

Mein Verdacht: MC hat beim reparieren der nav etwas zerstört, das dieses Problem nun verursacht? Die rec Datei scheint unverschlüsselt und OK zu sein.

Wenn ihr an einer weiteren Fehleranalyse interessiert seid, kann ich versuchsen, Euch die ganzen Dateien (>6GB) irgendwo zum Download zur Verfügung zu stellen (bitte per PN).

[Homer]

Das liest sich so ähnlich wie der Fehler "Klötzchenbildung", wenn du nicht geschrieben hättest:
[quote="db1"]Dass die Datei nicht verschlüsselt ist kann ich auch dadurch sehen, dass ich mir die *.rec am PC mit dem VLC Player ohne Störungen ansehen kann.[/quote]Ist der Ton auch störungsfrei? Oder hast du alle -zig Sekunden eine Tonstörung?

Ich schreibe seit einiger Zeit an einem Java-Programm, das solche und andere Fehler einer Aufnahme frühzeitig erkennen kann. Damit könnte ich natürlich deine Datei testen - oder du testest diese mit meinem Programm auf deinem PC. Das Programm kennt allerdings nur unverschlüsselte Aufnahmen. Verschlüsselte, teilentschlüsselte und entschlüsselte Aufnahmen sind ungetestet und werden nicht unterschiedlich verarbeitet.

Viele Grüße
Homer

[chris86]

Ja, natürlich bin daran interessiert diesem Problem auf die Spur zu kommen, damit es nicht wieder auftritt!!

[quote="db1"]Mein Verdacht: MC hat beim reparieren der nav etwas zerstört, das dieses Problem nun verursacht?[/quote]
Das kann ich nahezu ausschließen. Bei diesem "Reparieren" werden nur die Millisekunden-Angaben geprüft (und ggf. gefixt) - diese werden aber vom Topf scheinbar nicht ausgewertet.

[quote="db1"]Die rec Datei scheint unverschlüsselt und OK zu sein.[/quote]
Das ist eine wichtige Info!
Möglicherweise war es eine dumme Idee von mir, in der inf das Verschlüsselungs-Flag zu setzen. Vielleicht kommt der Topf damit jetzt nicht klar, weil er versucht, die Pakete nochmal zu entschlüsseln, obwohl sie es schon sind?
- Dies würde sich jedoch sehr leicht wieder beheben lassen ;-)

[quote="db1"]Wenn ihr an einer weiteren Fehleranalyse interessiert seid, kann ich versuchsen, Euch die ganzen Dateien (>6GB) irgendwo zum Download zur Verfügung zu stellen (bitte per PN).[/quote]

Vielen Dank für das Angebot! Ich werde erstmal versuchen, das mit deiner Anleitung haargenau bei mir zu reproduzieren.
Aber falls das nicht gelingen sollte, dann wäre es natürlich gut, deine Aufnahme in Augenschein nehmen zu können...


@Homer: Was genau analysiert denn dein Programm? Prüfung der Paket-Counter auf Konsistenz? - Das ist nämlich in RecStrip schon drin, und braucht daher nicht erneut getestet zu werden...

[Anthea]

"Pseudoverschlüsselte" Dateien werden von den Töpfen seit jeher noch mal durch das CI gejagt. Ich hatte sowohl in den 5000ern als auch in den HD-Receivern Probleme mit Aufnahmen, die als Verschlüsselt markiert waren, obwohl sie es nicht waren. Auffällig war dann, dass die Wiedergabeprobleme verschwanden, sobald ich das CI gezogen habe. Nicht etwa, dass die Datei dann nicht mehr abgespielt wurde oder so, sie lief dann problemlos. Das war aber auch noch vor "Reparaturmöglichkeiten" im Topf, die Töpfe haben das hin und wieder also ganz alleine hingekriegt.

[db1]

Möglicherweise war es eine dumme Idee von mir, in der inf das Verschlüsselungs-Flag zu setzen. Vielleicht kommt der Topf damit jetzt nicht klar, weil er versucht, die Pakete nochmal zu entschlüsseln, obwohl sie es schon sind?
- Dies würde sich jedoch sehr leicht wieder beheben lassen ;-)

Gut das können wir gleich testen

Ich habe jetzt eine weitere Datei "zerstört". Es ist/war wieder eine HD+ Aufnahme (RTLII HD).

Aber dieses Mal benötigte es nur 1 Schritt: starten von Strippen in MC.

Die Datei war vorher OK und abspielbar, nach Start des Strippen -> Fehlermeldung, gelbes Verschlüsselungssymbol und die Datei war unbrauchbar (wie oben, pixelbildung).
Eine zuvor gestrippte ORF Aufnahme funktioniert tadellos.

MovieCutter.log

2017-09-11 15:04:06 *** MovieCutter V3.6c started! (FBLib 2013-02-24+) ***
2017-09-11 15:04:06 =======================================================
2017-09-11 15:04:06 Receiver Model: SRP-2100 (TMS) (22010), System Type: TMS-S (5)
2017-09-11 15:04:06 Firmware: TF-TEST 1.15.77
2017-09-11 15:04:06 Hard disk: WDC WD20EZRX-00D8PB0, FW 80.00A80, Serial: WD-WCC4M6JC7047
2017-09-11 15:04:07 Options: SpecialEnd=only_safe, DoiCheckTest=3, CheckFSAfterCut=1, InodeMonitoring=1
2017-09-11 15:04:07 Checking list of suspect inodes (Device=/dev/sda2, ListFile=/mnt/hd/FixInodes.lst):
2017-09-11 15:04:07 -> No ListFile present.
2017-09-11 15:04:07 ========================================

2017-09-11 15:04:07 Attaching to /mnt/hd/DataFiles/external/SciFi/Looper.rec
2017-09-11 15:04:07 ----------------------------------------
2017-09-11 15:04:07 Inode Nr = 1181
2017-09-11 15:04:07 File size = 8120500224 Bytes (899878 blocks)
2017-09-11 15:04:07 PacketSize = 192
2017-09-11 15:04:07 Reported total blocks: 899841
2017-09-11 15:04:07 Type of recording: HD
2017-09-11 15:04:08 .nav-file loaded: 6831 I-Frames found.
2017-09-11 15:04:08 First Timestamp: Block=36, Time=0:00:02,257
2017-09-11 15:04:08 Playback Duration (from nav): 2:04:45,231
2017-09-11 15:04:08 Playback Duration (from inf): 2:04:47
2017-09-11 15:04:08 HDD free space = 15149355008 Bytes
2017-09-11 15:04:21 [Action 'Strip movie' started...]
2017-09-11 15:04:22 TAP_EventHandler: State=ST_ActiveOSD, !isPlaybackRunning --> CutFileSave()
2017-09-11 15:04:22 Checking list of suspect inodes (Device=/dev/sdb1, ListFile=/mnt/hd/DataFiles/external/FixInodes.lst):
2017-09-11 15:04:22 -> No ListFile present.
2017-09-11 15:04:24 RecStrip finished.
2017-09-11 15:04:24 RecStrip returned error code 9!
2017-09-11 15:04:35 ========================================

2017-09-11 15:04:35 Attaching to /mnt/hd/DataFiles/external/SciFi/Looper.rec
2017-09-11 15:04:35 ----------------------------------------
2017-09-11 15:04:35 Inode Nr = 1181
2017-09-11 15:04:35 File size = 8120500224 Bytes (899878 blocks)
2017-09-11 15:04:35 PacketSize = 192
2017-09-11 15:04:35 Reported total blocks: 899878
2017-09-11 15:04:35 File is crypted!
2017-09-11 15:05:08 Checking list of suspect inodes (Device=/dev/sdb1, ListFile=/mnt/hd/DataFiles/external/FixInodes.lst):
2017-09-11 15:05:08 -> No ListFile present.
2017-09-11 15:05:20 Checking list of suspect inodes (Device=/dev/sda2, ListFile=/mnt/hd/FixInodes.lst):
2017-09-11 15:05:20 -> No ListFile present.
2017-09-11 15:05:20 MovieCutter Exit.

RecStrip.log

=========================================================
*** RecStrip started Mon Sep 11 15:04:22 2017

Called: RecStrip -s -e /mnt/hd/DataFiles/external/SciFi/Looper.rec /mnt/hd/DataFiles/external/SciFi/Looper_strip.rec

RecStrip for Topfield PVR v2.2
(C) 2016/17 Christian Wuensch
- based on Naludump 0.1.1 by Udo Richter -
- based on MovieCutter 3.6 -
- portions of Mpeg2cleaner (S. Poeschel), RebuildNav (Firebird) & TFTool (jkIT)

Parameters:
DoCut=0, DoMerge=0, DoStrip=yes, RmEPG=yes, RmTxt=no, RbldNav=no, RbldInf=no, PkSize=0

Input file: /mnt/hd/DataFiles/external/SciFi/Looper.rec
File size: 8120500224, packet size: 192
TS: PMTPID=0x0060, SID=0xef10, PCRPID=0x00ff, Stream=0x1b, VPID=0x00ff, HD=1
TS: TeletxtPID=0x0020
TS: Teletext date: mdj=57251, 00:29:41
TS: EvtStart = Sun Aug 16 21:25:00 2015
TS: EventName = Looper
TS: EventDesc =
TS: ExtEvent = Wiederholung vom Sonntag, 20:15 Uhr. Schon ein paar Jahrzehnte in der Zukunft sind Zeitreisen ohne Probleme möglich, aber verboten. Doch für die großen Verbrecherorganisationen ist dieses Verbot kein Hindernis: Sie schicken ihre auserwählten Opfer
TS: ExtEvent = Wiederholung vom Sonntag, 20:15 Uhr. Schon ein paar Jahrzehnte in der Zukunft sind Zeitreisen ohne Probleme möglich, aber verboten. Doch für die großen Verbrecherorganisationen ist dieses Verbot kein Hindernis: Sie schicken ihre auserwählten Opfer in die Vergangenheit, um sie dort töten und beseitigen zu lassen. Doch die sogenannten 'Looper' müssen nicht nur Fremde töten, sondern auch ihr eigenes zukünftiges Ich, um ihre Spuren zu verwischen. Das sorgt häufig für große Probleme...
TS: SvcName = RTL HD
TS: Duration = 124 min 59 sec
TS: StartTime = Sun Aug 16 22:27:00 2015

Inf file: /mnt/hd/DataFiles/external/SciFi/Looper.rec.inf
Determine SystemType: DVBs = 0, DVBt = -4, DVBc = -5 Points
-> SystemType=ST_TMSs
INF: VideoStream=0x1b, VideoPID=0x00ff, HD=1

Nav file: /mnt/hd/DataFiles/external/SciFi/Looper.rec.nav

Cut file: /mnt/hd/DataFiles/external/SciFi/Looper.cut


Output rec: /mnt/hd/DataFiles/external/SciFi/Looper_strip.rec
Inf output: /mnt/hd/DataFiles/external/SciFi/Looper_strip.rec.inf
Nav output: /mnt/hd/DataFiles/external/SciFi/Looper_strip.rec.nav
Cut output: /mnt/hd/DataFiles/external/SciFi/Looper_strip.cut


WARNING: Scrambled TS - Scrambling bit at position 1680960 -> packet ignored.
cNaluDumper: TS continuity offset 1 (pos=1681348)
WARNING: Scrambled TS - Scrambling bit at position 2912256 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2912640 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2912832 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2913216 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2913408 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2913792 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2913984 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2914176 -> packet ignored.
WARNING: Scrambled TS - Scrambling bit at position 2914560 -> packet ignored.
ERROR: Too many ignored packets: 10 -> aborted.

[db1]

Nachtrag: Ich muss in ein paar Stunden zum Flughafen und bin dann 10 Tage weg, wenn es noch was braucht muss es bald sein.

[Homer]

[quote="chris86"]@Homer: Was genau analysiert denn dein Programm? Prüfung der Paket-Counter auf Konsistenz?[/quote]Nein, so in die Tiefe geht es (noch) nicht - würde ich aber gerne machen können. Mit meinem Analyseprogramm, mit dem ich meine Schnelltests verifiziere, teste ich jeden Satz (192 Bytes Länge) auf das Vorhandensein der PCR-Info. Falls vorhanden, merke ich mir PCR und TS und bilde mit der vorherigen Info die Differenz. Dabei dürfen die Differenzen nicht größer als 50 ms und der Unterschied zwischen PCR-Differenz und TS-Differenz nicht größer als 1 ms sein. Falls zu groß, schreibe ich die Laufzeitposition und Länge der Lücke raus, damit ich sie bei der Wiedergabe finden kann. (Dadurch kann ich einzelne Fehler im Vor- und Nachlauf oder Werbeunterbrechung akzeptieren.) Klötzchenbildung erkenne ich damit auch nach einer Reparatur durch RebuildNAV oder nach dem Trimmen mit TFtool.

Viele Grüße
Homer