MovieCutter

[macfan]

Das klappt, danke!

Gruß, Horst

[db1]

@chris86: Ich hab dir logs von 2 erfolgreichen Versuchen mit der Version 22a-dbg gesendet.

Weitere wollte ich nun über Nacht im Job durch Verschieben in das Verzeichnis RecStrip und starten von RecStripper .tap machen. Da werden aber anscheinend die logs nicht vollständig geschrieben?
Geht das nur über Start vom MC aus?

[chris86]

@chris86: Ich hab dir logs von 2 erfolgreichen Versuchen mit der Version 22a-dbg gesendet.

Die sind leider nicht bei mir angekommen...

Weitere wollte ich nun über Nacht im Job durch Verschieben in das Verzeichnis RecStrip und starten von RecStripper .tap machen. Da werden aber anscheinend die logs nicht vollständig geschrieben?
Geht das nur über Start vom MC aus?

Eigentlich sollten dabei auch Logs geschrieben werden (in den Settings/RecStripper Ordner).
Leider ist der RecStripper hoffnungslos veraltet, und wird von mir aktuell auch nicht gepflegt. (Kann leider nicht alles gleichzeitig machen...)
Theoretisch sollte er aber auch mit der neuen RecStrip-Version problemlos zusammenarbeiten, und somit ein "korrektes" Stripping-Resultat (nach dem aktuellen Stand) liefern...
Wichtig ist dabei halt nur, dass (a) MC nach RecStripper installiert wurde, oder (b) manuell die aktuelle Version von RecStrip auf den Topf kopiert wurde.

Langfristig würde ich den Stripper gern in RebuildNav integrieren, welches ähnliches tut, und bereits ausgereifte Filesystem-Traversierungs- und GUI-Funktionalitäten bietet.
Idee der Bedienung wäre dann: Eine Aufnahme per SmartFiler zum Strippen markieren, und beim nächsten Durchlauf von RbN wird das dann automatisch erledigt.
Aber das ist noch etwas Zukunftsmusik...

[db1]

OK, habe die logs nochmals gesendet (SPAM-Ordner?).
Zusätzliche 4 logs vom Stripper tap sind aber nur spärlich (aber er hat die richtige Version verwendet, da *.scr generiert wurden).

Alle gestrippten Dateien waren danach in Ordnung.

edit: Habe gerade gesehen, dass die E-Mail geblockt wurde.
Hänge die Daten jetzt hier an.

Im root der zip die logs von gestern (Contact_strip.rec.scr hatte 0 Byte), gestartet aus dem MC.
Die MovieCutter.log habe ich nicht bereinigt, da sind auch andere Aktionen von Filmstarts drinnen.

Zusätzlich 4 Dateien (im Unterverzeichnis), die im Batch abgearbeitet wurden mit spärlichem log. Bei 3 der 4 Dateien hatte die *.scr 0 Byte.
(Mir ist allerdings überhaupt nicht klar wie das Stripper-tap gestartet wurde, da ich es meiner Erinnerung nach abgebrochen hatte, nachdem ich keinen Fortschritt in den standard logs gesehen habe???).

Alle Dateien scheinen normal abspielbar zu sein (spulen, testweise Szenen angesehen).

[db1]

Hallo Chris,

ich habe jetzt noch einige weitere Dateien mit der 22a-dbg entschlüsselt. Das waren aber nicht nur HD+ Sendungen sondern auch andere.

2 Sachen sind mir aufgefallen:
1) Es bleiben regelmäßig irgendwelche *.rec.nav.bak Dateien übrig (das war bei mir aber schon immer so ).
2) Es gab einen reboot (Serenity, erster Versuch)! Zuerst dachte ich an einen Zufall, da das bei mir schon hin und wieder vorgekommen ist, aber das log lässt doch das Stripen als Ursache vermuten.
Zehntausende DEBUG Einträge dürften irgendetwas zum Überlaufen gebracht haben (ich habe im log > 20000 Zeilen gelöscht, da im Original sogar das zip für einen upload zu groß war). Vor diesem Strip wurde von MC die nav repariert. Ein neuerlicher Strip Versuch der Datei führte dann aber zum Erfolg (Reboot nicht reproduzierbar, im log ersichtlich).

[chris86]

Hi Dieter,

der Fehler mit der Mail liegt übrigens in den *.scr-Dateien. Diese gelten unter Windows als ausführbar, und somit als "gefährlich". Log-Dateien kannst du mir problemlos per E-Mail schicken. Und wenn es nochmal *.scr sein sollten, dann einfach die Dateierweiterung ändern

Im root der zip die logs von gestern (Contact_strip.rec.scr hatte 0 Byte), gestartet aus dem MC.

Zusätzlich 4 Dateien (im Unterverzeichnis), die im Batch abgearbeitet wurden mit spärlichem log. Bei 3 der 4 Dateien hatte die *.scr 0 Byte.
(Mir ist allerdings überhaupt nicht klar wie das Stripper-tap gestartet wurde, da ich es meiner Erinnerung nach abgebrochen hatte, nachdem ich keinen Fortschritt in den standard logs gesehen habe???).

Alle Dateien scheinen normal abspielbar zu sein (spulen, testweise Szenen angesehen).

Also die Logs im ersten Archiv sehen ja alle super und einwandfrei aus!
Keine Debug-Fehler, und die "verschlüsselten" Pakete in den *.scr-Dateien bestehen (soweit ich sehen kann), wieder nur aus diesen merkwürdigen riesigen Adaptation Fields plus 1 Byte (angeblichem) Payload...

Das zweite Archiv ist schon komplizierter...

Hallo Chris,
1) Es bleiben regelmäßig irgendwelche *.rec.nav.bak Dateien übrig (das war bei mir aber schon immer so ).

Das kommt, wenn MC meint, die nav "reparieren" zu müssen, sprich, wenn die Länge der nav von der Länge der inf abweicht.
Ich hatte da ja mal die "Toleranzgrenze" deutlich erhöht. Womöglich müsste man die nochmal erhöhen? (Aber mir ist nicht ganz klar, wieso die beiden Werte bei manchen Personen soo stark voneinander abweichen können )

2) Es gab einen reboot (Serenity, erster Versuch)! Zuerst dachte ich an einen Zufall, da das bei mir schon hin und wieder vorgekommen ist, aber das log lässt doch das Stripen als Ursache vermuten.

Vom ersten Strip-Versuch sehe ich gar keinen Eintrag im Log. (noch nichtmal die Zeile mit dem RecStrip-Start). Das heißt eigentlich, dass der Crash schon in MC entstanden sein muss.
Hast du das Log da auch gekürzt?
Oder mal das MC-Log von dieser Stelle für mich?

Zehntausende DEBUG Einträge dürften irgendetwas zum Überlaufen gebracht haben (ich habe im log > 20000 Zeilen gelöscht, da im Original sogar das zip für einen upload zu groß war). Vor diesem Strip wurde von MC die nav repariert. Ein neuerlicher Strip Versuch der Datei führte dann aber zum Erfolg (Reboot nicht reproduzierbar, im log ersichtlich).

Das ist wirklich ein sehr komischer Fall! Scheint fast so, als hätte jemand vorne an die Aufnahme 8 Byte angefügt oder sowas... Das hab ich jedenfalls noch nie gesehen...
Könntest du mir von dieser (Original-)Aufnahme evtl. bei Gelegenheit mal das erste Megabyte der rec und die nav/inf schicken? Womöglich handelt es sich um irgendeine Besonderheit einer Timeshift-Aufnahme oder sowas? Die müsste man RS dann eben noch beibringen...

Bei der letzten Aufnahme in deinem Log scheint dagegen an zwei Stellen eine Reihe von Frames in der Original-nav zu fehlen. Wie das passieren kann, ist mir auch schleierhaft - aber das würde ich jetzt mal nicht als großes Problem einstufen...

[db1]

Vom ersten Strip-Versuch sehe ich gar keinen Eintrag im Log. (noch nichtmal die Zeile mit dem RecStrip-Start). Das heißt eigentlich, dass der Crash schon in MC entstanden sein muss.
Hast du das Log da auch gekürzt?
Oder mal das MC-Log von dieser Stelle für mich?

Ich habe dir nochmals die kompletten logs gesendet (bzw. einen link). Ich habe gesehen, dass ich da falsch geschnitten habe.

Das ist wirklich ein sehr komischer Fall! Scheint fast so, als hätte jemand vorne an die Aufnahme 8 Byte angefügt oder sowas... Das hab ich jedenfalls noch nie gesehen...

Das war Serenity, wie oben bereits gesagt, wurde die nav vom MC beim ersten Aufruf geändert, dann erfolgte gleich das Strippen mit reboot. Kann es sein, dass da durch die aktuelle Änderung der nav irgendetwas faul ist?
Nach dem reboot wollte ich den reboot reproduzieren, da hat es dann aber geklappt (sieht man auch im log).

Könntest du mir von dieser (Original-)Aufnahme evtl. bei Gelegenheit mal das erste Megabyte der rec und die nav/inf schicken? Womöglich handelt es sich um irgendeine Besonderheit einer Timeshift-Aufnahme oder sowas? Die müsste man RS dann eben noch beibringen...

Wie zerkleinere ich die Datei? Sie ist außerdem in einem Zustand, in dem sie dann ja erfolgreich gestrippt wurde? Die Original *.nav.bak dürfte ich gelöscht haben

[chris86]

Ich habe dir nochmals die kompletten logs gesendet (bzw. einen link). Ich habe gesehen, dass ich da falsch geschnitten habe.

Vielen Dank für die vielen Debugging-Infos!

Das war Serenity, wie oben bereits gesagt, wurde die nav vom MC beim ersten Aufruf geändert, dann erfolgte gleich das Strippen mit reboot. Kann es sein, dass da durch die aktuelle Änderung der nav irgendetwas faul ist?

Eigentlich nicht. Bei dieser Änderung werden nur die Zeitangaben in der nav angepasst. Diese waren bei dieser Aufnahme tatsächlich um mehr als 5 Stunden verkehrt!!
(Möglicherweise eine Timeshift-Aufnahme?)
Die Zeitangaben in der nav werden aber weder vom Topf, noch von RecStrip wirklich genutzt. Sie werden hauptsächlich für die Zeit-Anzeigen innerhalb von MC gebraucht.

Nach dem reboot wollte ich den reboot reproduzieren, da hat es dann aber geklappt (sieht man auch im log).

Danke, jetzt sehe ich das auch im Log!
Aber es ist hier überhaupt keine Ursache zu erkennen, warum es beim ersten Mal gecrasht ist, und beim zweiten Mal nicht. Es dürfte sich an den Ausgangsdaten (rec, nav) zwischendurch nichts geändert haben...
Solange dieser Crash sich nicht mehr reproduzieren lässt, sehe ich da aktuell keine Chance, die Ursache zu ermitteln.
Tatsache ist aber, dass in dieser Aufnahme dieser sehr sehr merkwürdige 8-Byte-Offset auftaucht, was eigentlich nicht sein dürfte. Dem würde ich gern auf den Grund gehen. Womöglich findet sich dabei auch die Ursache für den Absturz gleich mit ;-)

Wie zerkleinere ich die Datei? Sie ist außerdem in einem Zustand, in dem sie dann ja erfolgreich gestrippt wurde? Die Original *.nav.bak dürfte ich gelöscht haben

Wenn du die rec-Datei schon auf dem PC hast, dann ist es das einfachste, sie mit einem Hex-Editor (z.B. HxD) zu öffnen. Damit kann man (ähnlich wie in Word) den Anfang markieren, kopieren, und in eine neue Datei einfügen.
Wenn du die Datei noch nicht auf dem PC hast, und dich ein wenig mit der Linux-Konsole auskennst, kannst du dieses Kopieren des Anfangs bereits am Topf erledigen. Dazu einfach in Telnet das hier eingeben:

Code: Alles auswählen

head /mnt/hd/DataFiles/[i]<evtl. Unterordner einfügen>[/i]/Serenity.rec > /mnt/hd/DataFiles/AnfangVonSerenity.rec

Eine dritte Möglichkeit wäre, den Anfang mit MC abzuschneiden (dies würde aber die Originaldatei verändern - wäre also nur eine "Notlösung")...
Die nav ist schon okay so (es reicht, wenn es der Zustand vor dem Strippen ist).

[TV-Junkie]

Kann man eine Aufnahme nicht einfach hochladen irgendwo, und dann die Übertragung z.b. bei 1GB abbrechen ? Ich meine, ich hätte das mal so gemacht

[chris86]

Haha, jaa, ich hatte überlegt, genau das auch noch als Tipp dazuzuschreiben :d rinking:
Allerdings könnte es dabei auch immer passieren, dass der geladene Teil dann wieder entfernt wird...

[Alter Sack]

Wie zerkleinere ich die Datei?

Firebird hat doch für fast alles eine Lösung, RecFileCut

[db1]

head hätte ich schon verwenden wollen, da fehlt aber die Angabe wie viel geschnitten werden soll. mit -c1m ging es nicht (versteht keine c option, nur Zeilen und da war ich dann unsicher was Zeilen in einem binär-file sind).

Daher habe ich RecFileCut verwendet, das ging dann (*.inf ist dafür aber nötig).

Daten für Chris zur Verfügung gestellt.

edit: Ich habe sicherheitshalber auch die ersten bytes der Original und der Cut Datei verglichen, sie sind ident.

[LAL]

Immer öfter bekomme ich die Meldung "Der Schnitt ist fehlgeschlagen!" beim Scheiden. Hier sind 2 Beispiele im Log. Kann man damit die Ursache finden? Danke für Hilfe.

Gruss
Luc

[chris86]

Hi Luc,

das ist in der Tat ein merkwürdiges Problem...
Vielen Dank für das Logfile!

Code: Alles auswählen

2017-11-09 22:04:10 Size of the new playback file (after cut): [b]12389426304[/b]
2017-11-09 22:04:11 Playback re-started (j=186, isPlaybackRunning=1, TotalBlock=[b]1372886[/b], CurrentBlock=135)
...
2017-11-09 22:04:11 Processing segment 4
2017-11-09 22:04:12 ----------------------------------------
2017-11-09 22:04:12 Source        = 'Nouvelle Star + Nouvelle Star ça continue - 2017-11-08 21-00.rec'
2017-11-09 22:04:12 Cut name      = 'Nouvelle Star + Nouvelle Star ça continue - 2017-11-08 21-00 (Cut-3).rec'
2017-11-09 22:04:12 Inode Nr.     = 135560
2017-11-09 22:04:12 File size     = [b]12389426304 [/b]Bytes ([b]1372941 [/b]blocks)
...
2017-11-09 22:04:12 FileCut('Nouvelle Star + Nouvelle Star ça continue - 2017-11-08 21-00.rec', 'Nouvelle Star + Nouvelle Star ça continue - 2017-11-08 21-00 (Cut-3).rec', '/mnt/hd/DataFiles', 596354, 40755)
2017-11-09 22:04:13 ApplHdd_FileCutPaste('Nouvelle Star + Nouvelle Star ça continue - 2017-11-08 21-00.rec', 596354, 40755, 'Nouvelle Star + Nouvelle Star ça continue - 2017-11-08 21-00 (Cut-3).rec')
2017-11-09 22:04:13 ApplHdd_FileCutPaste() returned: 65024.
2017-11-09 22:04:13 FileCut() E0501. Cut file not created.
2017-11-09 22:04:13 MovieCutter() E0002: Firmware cutting routine failed.
2017-11-09 22:04:13 Checking file inode for wrong di_nblocks (Device=/dev/sda2):
2017-11-09 22:04:13 ??: Inode[135560]: Tree Error! Internal XAD[3], offset=1378175, should be 1313841 (has been fixed)
2017-11-09 22:04:13 1 files given, 1 found. 0 of them ok, 1 were fixed.
2017-11-09 22:04:13 Size of the new playback file (after cut): [b]12125914240[/b]
2017-11-09 22:04:15 Playback re-started (j=131, isPlaybackRunning=1, TotalBlock=[b]1372886[/b], CurrentBlock=79)

Hier lässt sich erkennen, dass beim Entfernen des 4. Segments die Firmware-Schnittfunktion einen Fehler zurückgeliefert hat. Wenn ich es richtig deute, dann wurde ein Teil des zu löschenden Segments aus der Aufnahme herausgeschnitten, jedoch nicht das komplette Segment. Jedenfalls wurde die Dateigröße verändert - nicht jedoch die berichtete Blockzahl...
Dann kam es zum Fehler (vermutlich weil der XAD-Tree des Inodes zu stark verschachtelt war). Hierbei wurde der Inode nicht mehr "fertig" behandelt, und das herausgeschnittene Stück nicht mehr in eine neue Datei eingefügt.
Wie es scheint, nutzt du die Einstellung DoiCheckTest=4 (nach jedem Schnitt prüfen), durch welche der entsprechende Inode scheinbar dennoch "repariert" werden konnte.

Sehe ich es richtig, dass die hinteren Werbeblöcke erfolgreich entfernt wurden, die vorderen nicht, und bei Segment 4 ein Teil der Werbung (jedoch nicht die ganze) entfernt wurde? Wurde der Anfang oder das Ende dieses Werbeblocks gelöscht?
Lässt sich die Aufnahme noch einwandfrei abspielen?

Die so beschnittene Aufnahme hat nun auf jeden Fall den Fehler, dass nav und inf nicht mehr passen (denn es wurde ein Teil-Schnitt durchgeführt). Dies würde sich aber leicht mittels RebuildNav oder RecStrip beheben lassen.

Im schlimmsten Fall weist der zugehörige Inode jedoch noch interne Fehler auf, weshalb die Datei beim nächsten Crash mit Festplattenprüfung gelöscht werden könnte.
Um dies zu testen wäre es klasse, wenn du einmal mittels MovieCutter eine (volle) Dateisystemüberprüfung durchführen könntest und mir die entsprechende Log-Datei (fsck.log) zukommen lassen könntest?
Sollten sich hier keine Fehler zeigen, würde ich einmal den Test wagen, einen Reboot zu provozieren (z.B. durch Stecker ziehen), und nachzusehen, ob die Datei "überlebt".
Damit wir sichergehen können, dass betroffene Aufnahmen technisch in Ordnung sind, und nicht plötzlich unerwartet gelöscht werden.

Für die Zukunft würde ich dazu raten, für eine geringere Fragmentierung der Festplatte zu sorgen (Platz schaffen, evtl. mal HDD formatieren, Timeshift ausschalten, etc.)

[Homer]

[quote="chris86"][...] einen Reboot zu provozieren (z.B. durch Stecker ziehen)[/quote]... oder mit TMS Remote: TMS -> Reboot

Viele Grüße
Homer

[chris86]

Macht der dann auch die HDD-Überprüfung beim Neustart...!?

[LAL]

Hallo Chris,

Vielen Dank für die Ausführliche Antwort.

Wie es scheint, nutzt du die Einstellung DoiCheckTest=4 (nach jedem Schnitt prüfen), durch welche der entsprechende Inode scheinbar dennoch "repariert" werden konnte.

Richtig.

Sehe ich es richtig, dass die hinteren Werbeblöcke erfolgreich entfernt wurden, die vorderen nicht, und bei Segment 4 ein Teil der Werbung (jedoch nicht die ganze) entfernt wurde?

Das ist so, wie du es im Screenshot sehen kannst.

Wurde der Anfang oder das Ende dieses Werbeblocks gelöscht?

Segment 5 enthält das Ende des Werbeblocks und ein Teil der Sendung nach der Werbung.

Lässt sich die Aufnahme noch einwandfrei abspielen?

Ja aber ab Segment 5 stimmen die Schnittmarken nicht mehr überein, mit was ich markiert hatte.

Um dies zu testen wäre es klasse, wenn du einmal mittels MovieCutter eine (volle) Dateisystemüberprüfung durchführen könntest und mir die entsprechende Log-Datei (fsck.log) zukommen lassen könntest?

Volle Dateisystemüberprüfung habe ich schon mehrmals durchgeführt. Die letzte hat die "Nouvelle Star" Aufnahme in der Dialog erwähnt. Aber bei anderen war es "File.db" oder "/DataFiles/__temprec__.ss". Ich lege den Log bei. Sieht nicht gut aus. Ich denke, ich werde alle Dateien auf ext. Platte sichern und die HDD formatieren, wie du es empfiehlst.

Nochmals vielen Dank für deine Unterstützung.

Gruss
Luc

[chris86]

Schauen wir uns das nochmal an...

Die "Salut les terriens" Aufnahme wird vom Filesystem-Check nicht angemeckert.
Solltest du diese also nicht zwischenzeitlich gelöscht haben (hast du?), dann scheint die icheck-Reparatur erfolgreich gewesen zu sein.

Die "Nouvelle Star + Nouvelle Star ça continue" Aufnahme wird als fehlerhaft angezeigt.
Vorsicht! Diese wird beim nächsten Crash mit Festplatten-Überprüfung von der Firmware gelöscht werden!

Wenn wir das Problem diagnostizieren (und diese, sowie ggf. künftige Aufnahmen mit demselben Fehler) retten wollen, dann müssen wir diese Datei also jetzt untersuchen, so lange sie noch da ist!!

Allerdings scheint da auch etwas nicht ganz zu stimmen...

Die "Nouvelle Star" Datei, die du laut Log geschnitten hast, hatte Inode Nr. 135560 und zuletzt eine Größe von 12.125.914.240 Bytes.
Die "Nouvelle Star" im Filesystem-Check hat Inode Nr. 135439 und eine (angebliche) Größe von 11.665.985.536 Bytes (jedoch 2.848.142 zugewiesene 4096 kB Blöcke).

Irgendwas musst du also mit dieser Datei nach dem Log noch gemacht haben! (Vermutlich weitere Schnitte)

Könntest du mir mal das vollständige Log (zumindest seit diesem Schnitt) per Mail senden?


PS: Formatieren scheint erstmal nicht nötig. Außer dieser einen Datei weist die Platte derzeit keine weiteren Fehler auf. Die Meldungen zu File.db und __temprec__.ss sind völlig normal, da auf diese Dateien aktive Schreibzugriffe durchgeführt werden)

[LAL]

[quote="chris86"]Schauen wir uns das nochmal an...

Die "Salut les terriens" Aufnahme wird vom Filesystem-Check nicht angemeckert.
Solltest du diese also nicht zwischenzeitlich gelöscht haben (hast du?), dann scheint die icheck-Reparatur erfolgreich gewesen zu sein.

Die "Nouvelle Star + Nouvelle Star ça continue" Aufnahme wird als fehlerhaft angezeigt.
Vorsicht! Diese wird beim nächsten Crash mit Festplatten-Überprüfung von der Firmware gelöscht werden!

Wenn wir das Problem diagnostizieren (und diese, sowie ggf. künftige Aufnahmen mit demselben Fehler) retten wollen, dann müssen wir diese Datei also jetzt untersuchen, so lange sie noch da ist!!

Allerdings scheint da auch etwas nicht ganz zu stimmen...

Die "Nouvelle Star" Datei, die du laut Log geschnitten hast, hatte Inode Nr. 135560 und zuletzt eine Größe von 12.125.914.240 Bytes.
Die "Nouvelle Star" im Filesystem-Check hat Inode Nr. 135439 und eine (angebliche) Größe von 11.665.985.536 Bytes (jedoch 2.848.142 zugewiesene 4096 kB Blöcke).

Irgendwas musst du also mit dieser Datei nach dem Log noch gemacht haben! (Vermutlich weitere Schnitte)

Könntest du mir mal das vollständige Log (zumindest seit diesem Schnitt) per Mail senden?


PS: Formatieren scheint erstmal nicht nötig. Außer dieser einen Datei weist die Platte derzeit keine weiteren Fehler auf. Die Meldungen zu File.db und __temprec__.ss sind völlig normal, da auf diese Dateien aktive Schreibzugriffe durchgeführt werden)[/quote]Hallo Chris,

Sorry, ich hatte vergessen zu erwähnen, dass ich die beiden betroffenen Aufnahmen auf meinem PC kopiert und vom Topf gelöscht hatte. Um deine Fragen zu beantworten, habe ich "Nouvelle Star" wieder auf Topf kopiert.

Diese Aufnahmen müssen nicht gerettet werden. Ich möchte aber die Ursache von der Fehler wenn möglich eliminieren.

Die volle fsck.log sende ich dir morgen.

Gute Nacht.
Luc

Envoyé de mon SM-G920F en utilisant Tapatalk

[Homer]

[quote="chris86"]Macht der dann auch die HDD-Überprüfung beim Neustart...!?[/quote]Ja, leider.

Viele Grüße
Homer