MovieCutter

[Twilight]

wenn die externe platte ntfs formatiert ist wir das problem wohl an einem sonderzeichen liegen...

twilight

[BluField62]

wie gesagt, ältere kopierte Dateien mit Sonderzeichen habe ich genug auf der vom Topf formatierten Platte

[Twilight]

ok, wenn sie vom topf formatiert ist, ist sie jfs...speicher ist genug frei?

twilight

[BluField62]

ja, genügend
@FireBird
brauchst du noch mehr Daten?

[FireBird]

Nein. Der nächste Test wäre der von chris86 vorgeschlagene, denn es klingt nach beschädigtem Dateisystem.

[BluField62]

hmm...abspielen geht, ne .inf ist da und navigieren kann ich auch....

[klassikmann]

Ich habe lange Zeit nichts mehr von mir hören lassen bzgl. des Problems mit dem "Aufnahmenfresser" nach dem Schneiden. Ein Schnitt hinterließ ein inkonsistentes Dateisystem, so dass bei der nächsten Festplattenüberprüfung - z.B. nach einem Crash - die Aufnahmen gelöscht wurden.

Mein Topf war jetzt beim Topfield-Service und ist heute zurückgekommen. Im Servicereport steht:

1. SATA Kabel getauscht
2. Der Fehler konnte in keiner Konstellation hervorgerufen werden, trotz mehrfach produzierter Netztrennung während des Abspielens einer Aufnahme. Aus den HDD Logs läßt sich entnehmen, dass eine mögliche Fehlerursache (Command Timeouts, Wert: 131075) durch eine schlechte Kabelverbindung (SATA Kabel) hervorgerufen wurde.

Ich konnte gerade die ersten Tests abschließen: Der Fehler trat dabei nicht auf. Aus persönlichen Gründen kann ich systematische Tests erst in 10 Tagen durchführen. Ich werde berichten.

Es könnte also sein, dass dieses mysteriöse Problem eine recht profane Ursache hatte.

btw.: Ich habe die heutigen Tests mit der Beta von MC 3.0 durchgeführt. Gefällt mir gut.

Gruß
klassikmann

[LAL]

Hallo Chris,

Mit ein wenig Verspätung bekommst du die Texte auf Französisch für die Version 3.0.

Gruss
Luc

[klassikmann]

Ich konnte gerade die ersten Tests abschließen: Der Fehler trat dabei nicht auf. Aus persönlichen Gründen kann ich systematische Tests erst in 10 Tagen durchführen. Ich werde berichten.

Details siehe #1287.

Meine Tests habe ich nun abgeschlossen. Fazit:
Der Nachweis ist wohl erbracht, dass das Problem des "Aufnahmenfressers" weiterhin besteht und die Ursache in der Schnittfunktion der Firmware liegt.

Im Einzelnen:
Zunächst habe ich eine nagelneue Festplatte eingebaut, um nach dem Austausch des internen SATA-Kabels durch den Topfield-Service, eine mögliche weitere Ursachenquelle auszuschließen. Danach schnitt ich eine ganze Reihe von Aufnahmen abwechselnd mit MC 3.0 Beta und mit der Schnittfunktion der Firmware; immer das gleich Szenario: Wegschneiden des Vor- und Nachlaufs. Dabei trat der Aufnahmenfresser (Inkonsistenz des Filesystems mit nachfolgendem Löschen der Aufnahme durch eine Festplattenüberprüfung) bei den mit MC geschnittenen Aufnahmen auf, wenn auch selten, bei der Verwendung der Firmware-Schnittfunktion jedoch nicht.

Also war mein erster Eindruck: Die Firmware ist "aus dem Schneider". chris86 gab mir darauf den Hinweis, dass MC beim Wegschneiden des Nachlaufs die Firmware in der Weise nutzt, dass nicht der Nachlauf weggeschnitten wird, sondern alles bis auf den Nachlauf gespeichert und nachher die Datei umbenannt wird. Er empfahl mir, die Schnittfunktion der Firmware doch mal in gleicher Weise zu benutzen.

Ich habe vier frische Aufnahmen zwischen 7GB und 11GB ausgewählt. TAPs wurden alle bis auf den TMSTelnetd deaktiviert (Telnet benötige ich für den Filesystem-Check jfs_fsck). Vor den Tests habe ich erst mal einen jfs_fsck ausgeführt: Alles in Ordnung. Dann habe ich die Aufnahmen mit der Firmware geschnitten (gespeichert) indem ich jeweils den Anfang der Aufnahme als Startpunkt und wenige Minuten vor Ende als Endpunkt gewählt habe. Am Ende zeigte ein "jfs_fsck -n" (via telnet) die Überraschung:

Es kam ein "cannot repair the data format error" für acht Dateien, nämlich alle <aufnahme>.rec und <aufnahme>(CUT)-1.rec. Eine Festplattenüberprüfung nach Power-Off/On löschte dann wie zu erwarten die acht Dateien.

Ich denke, jetzt ist wieder Topfield am Zug.

Gruß
klassikmann

[Bernhard75045]

Auch ich hab gerade mal zwei Filme mit der Topf-eigenen Schnittfunktion geschnitten. Dabei hab ich die erste Schnittmarke an den Anfang der Sendung gesetzt, und dann den ganzen Film markiert. Erst beim Beginn des nachlaufs hab ich dann die zweite Marke gesetzt und das gewünschte Teilstück (jew. etwa 10 GB) gespeichert.
Dann hab ich jew. den MC gestartet und eine Dateisystemprüfung durchgeführt.

Ergebnis: Das Dateisystem zeigte jeweils Fehler auf.

Das "Aufnahmefresser-Phantom" kommt also nicht vom MC sondern ist wohl tatsächlich ein Topfield-Problem.

Ach ja: Eine Prüfung des Systems VOR dem Schneiden zeigte, dass das System einwandfrei arbeitet.
Und: der MC war beim Schneiden nicht nur ausgeblendet sondern das TAP war gestoppt!

[klassikmann]

Hallo Bernhard,[quote="Bernhard75045"]Das "Aufnahmefresser-Phantom" kommt also nicht vom MC sondern ist wohl tatsächlich ein Topfield-Problem.[/quote]Dann haben wir also auf einem SRP und einem CRP das Problem nachgestellt.

"Topfield übernehmen Sie!"

Gruß
Herbert

[Bernhard75045]

Allgemein muss ich zu der Topf-eigenen Schnittfunktion mal loswerden:

Ich finde es sehr seltsam, dass, wenn man zum (vernünftigen) "Navigieren" beim Abspielen einer Aufnahme (also: Pause, vor-/zurückspulen usw) eine "Hilfsdatei" (also: die .nav) benötigt, diese bei diesem Vorgang einfach verschwindet oder zerstört wird.

Ich benötige also TAPs, sei es zum vernünftigen (korrekten) Schneiden oder sei es zum Wiederherstellen der fehlenden .nav-Datei.

[chris86]

Hallo zusammen!

Es ist mir gelungen, den „Aufnahmenfresser-Bug“ zu diagnostizieren und nachzuvollziehen!

Das Muster ist regelmäßig immer exakt dasselbe, und das Problem kann (auch gänzlich ohne TAPs, also nur mit der firmwareinternen Schnittfunktion) zielsicher reproduziert werden. Die Fehlfunktion wurde aktuell in 12 von 12 Versuchen auf insgesamt 4 verschiedenen Receivern der Topfield SRP/CRP-Reihe belegbar nachgewiesen. Sie tritt allerdings nicht auf allen Geräten in derselben Regelmäßigkeit auf.
Ich beziehe mich im Folgenden nur auf das Verhalten der firmwareinternen Schnittfunktion (ohne die Nutzung von TAPs).


Was genau passiert beim Schneiden?

Die (Firmware-)Schnittfunktion des Receivers arbeitet (grob) folgendermaßen:
Jede Datei wird durch das JFS-Dateisystem (das der Topf verwendet) in Blöcken zu jeweils 4096 Byte gespeichert. Jede Datei wird durch einen eindeutig zugeordneten Inode identifiziert, der u.a. Informationen über die Größe der Datei und die Anzahl und Speicherposition der zugehörigen Datenblöcke beinhaltet.
Schneidet man nun ein Segment aus einer Aufnahme heraus, so wird für dieses Segment eine neue Datei (=ein neuer Inode) angelegt, welchem die Datenblöcke der markierten Szene zugeordnet werden. Bei der verbleibenden Rest-Aufnahme werden die Verweise auf diese Datenblöcke aus dem Inode entfernt. Auf diese Weise müssen die eigentlichen Videodaten nicht umkopiert werden, sondern lediglich deren Verwaltungsinformationen werden verändert. Deshalb arbeitet die Schnittfunktion so schnell. Der Nachteil ist jedoch, dass hierzu „am Betriebssystem vorbei“ Low-Level-Operationen am Dateisystem vorgenommen werden müssen, die ein Dateisystem so eigentlich nicht vorsieht.

Ein Beispiel:
Gegeben sei eine Datei (Inode A), welche aus den Datenblöcken [1, 2, 3, 4, 5, 6, 7, 8, 9] besteht.
Aus dieser Datei sollen die mittleren drei Blöcke herausgeschnitten werden.
Dabei wird ein neuer Inode B (Cutfile) angelegt, und die Blockzuordnung sieht dann so aus:
A --> [1, 2, 3, 7, 8, 9] B --> [4, 5, 6]




Und was läuft dabei nun schief? (technische Beschreibung)

Glücklicherweise klappt die beschriebene Neuzuordnung der Datenblöcke zu dem alten und neuen Inode anscheinend stets einwandfrei! Deshalb ist es auch (selbst im Fehlerfall) möglich die geschnittenen Dateien abzuspielen - und sie enthalten auch stets den erwarteten Inhalt.

Jetzt aber kommt das Problem:
Wenn das neu erzeugte Cutfile die Größe von 4 GB übersteigt, dann kann es vorkommen (es muss nicht), dass die Anzahl der belegten Blöcke (di_nblocks) im neu erzeugten Inode falsch eingetragen wird. Die eingetragene Blockzahl ist dabei dann stets um 1.048.576 Blöcke (= 2^20 Blöcke oder 2^32 Bytes) zu klein.
Für das verbleibende Rest-File wird die Blockzahl (auf dieser Basis) entsprechend berechnet – sie ist dadurch um 1.048.576 zu groß.

Und was passiert dann?
Das Dateisystem „rechnet“ nicht damit, dass es passieren kann, dass die Blockzahl derart falsch eingetragen wird. Wenn es also bei einem Selbst-Check (der z.B. nach einem Absturz ausgelöst wird) einen solchen Fehler feststellt, dann „denkt“ es, die Angaben im Inode seien korrekt, und die fehlenden Blöcke seien verloren gegangen. Daraus folgert es, die Datei wäre schwer beschädigt und könnte nicht repariert werden. Also wird die beschädigte Datei gelöscht.
So kommt der „Aufnahmenfresser“ zu Stande.
(In Wirklichkeit ist die einzige Beschädigung der Datei jedoch ein fehlerhafter Eintrag für di_nblocks. Dies lässt sich leicht nachweisen: Nach manueller Korrektur dieses Eintrags ist die Datei wieder blütenrein und wird auch nicht mehr beanstandet.)

Ursache?
Aufgrund des immer gleichen Fehlerbildes (und der „magischen“ Zahl von 2^20 Blocks bzw. 2^32 Bytes) wäre die Vermutung naheliegend, dass bei der Berechnung der Blockzahl eine Art von Integer-Überlauf in der Firmware auftreten könnte.
Ein Hardware-Fehler ist vor dem Hintergrund des immer gleichen Ablaufs und des immer gleichen Fehlbetrages äußerst unwahrscheinlich. Auch das „böse“ SATA-Kabel war offenbar nicht der Übeltäter (es sei denn das neue von Herbert ist gleich wieder kaputt^^).


Noch ein kleines Beispiel aus der realen Welt

Zu dem hier von Bernhard beschriebenen Schnitt-Experiment liegen mir detaillierte Diagnose-Daten vor, anhand derer ich das Fehlverhalten hier nun beispielhaft erläutern will:

Receiver Model: SRP-2401CI+ (22130)
Firmware: TF-BCPCE 1.10.00 (Sep 23 2013)
Hard disk: ST31000322CS, FW SC13, Serial: 9VX0RA62

Geschnitten wurden zwei Filme nach der u.a. Reproduktions-Anleitung.

Original-Datei „Bella und der F.rec“:
(InodeNr=114691, di_size=13249438720, di_nblocks=3234729)

Nach dem Schnitt:
Cut-File: „Bella und der F(CUT)-1.rec“
(InodeNr=335873, di_size=11510919168, di_nblocks=1761708, should be 2810284)

Rest-Aufnahme: „Bella und der F.rec“
(InodeNr=114691, di_size=1738519552, di_nblocks=1473021, should be 424445)

Cut-File*:
InodeNr=335875, di_size=<fehlt>, di_nblocks=<fehlt>, should be <fehlt>

Rest-File:
InodeNr=270336, di_size=848009920, di_nblocks=1255610, should be 207034

(*Daten des Cut-Files sind leider noch nicht erfasst worden. Werde versuchen, das nachzuliefern.)

Was an den Werten auffällt:

• Die Dateigrößen stimmen überein (Cut-File + Rest-Aufnahme = Original).
• Block-Zahl des Cut-Files ist um 1048576 zu niedrig, die des Rest-Files um denselben Betrag zu hoch.
• Die reale Blockzahl ist bei einigen dargestellten Dateien größer als man erwarten würde (di_size/4096). Das kann u.a. dadurch passieren, dass eine Datei auf mehrere AG’s verteilt wird. In solchen Fällen tritt der Fehler evtl. häufiger auf.

Mir liegen darüber hinaus diverse Logfiles von mehr als 20 Schnittoperationen vor, bei welchen sich jedes Mal das exakt identische Fehlerbild darstellte.


So kann das Problem (am besten) reproduziert werden

Die folgende Anleitung hat auf den „stärker“ betroffenen Geräten in 100% aller Testfälle des beschriebene Fehlverhalten produziert. Auf anderen Geräten klappt dies weniger „zuverlässig“. Auf meinem CRP-2401 musste ich es ca. 10 Mal durchführen – dann schlug aber auch hier der Fehler zu.

• Starten des Topfs mit der gedrückten [0] oder Beenden aller TAPs (v.a. MC).
• Man nehme eine frische (d.h. bisher ungeschnittene) Aufnahme mit > 8 GB.
• Aufnahme starten, und ganz am Anfang mit der [>|<]-Taste den Schnittbeginn setzen.
• Bis kurz vor das Ende spulen (ca. 5 min. übriglassen), und dort mit der Blauen Taste das Schnittende setzen.
• Die Option ‚Speichern’ auswählen.
• Jetzt sind sowohl das Cutfile als auch die Rest-Aufnahme (häufig, aber nicht zwangsläufig) beschädigt. Falls nicht, die obigen Schritte mit einer frischen Aufnahme wiederholen.
• Um die Beschädigung nachzuweisen, kann man nun den MovieCutter (aktuelle Version) starten und eine Dateisystemprüfung durchführen. Alternativ (wenn man dem MC nicht vertraut) kann die Diagnose auch mit folgender Anleitung durchgeführt werden:

Für alle, die das Problem näher untersuchen wollen:

Sollten sich auf der Festplatte Dateien befinden, die durch o.g. Fehlfunktion „vermurkst“ wurden, so lässt sich der Fehler mit Hilfe von TMSTelnetd und den JFS-Tools (von Firebird kompiliert hier zu finden) näher diagnostizieren:

1. Mit dem Befehl jfs_fsck -n -v /dev/sda2 sieht die Ausgabe für eine fehlerhafte Datei folgendermaßen aus:

   Code: Alles auswählen

   ../ProgramFiles/jfs_fsck_orig version 1.1.15, 04-Mar-2011
   processing started: 1/1/2000 0:12:51
   
   FSCK  Device /dev/sda2 is currently mounted READ ONLY.
   The current device is:  /dev/sda2
   Open(...READONLY...) returned rc = 0
   Primary superblock is valid.
   The type of file system for the device is JFS.
   Block size in bytes:  4096
   Filesystem size in blocks:  121571712
   **Phase 1 - Check Blocks, Files/Directories, and  Directory Entries
   File system object [b]FF5208[/b] has corrupt data [b](9)[/b].
   **Phase 2 - Count links
   **Phase 3 - Duplicate Block Rescan and Directory Connectedness
   **Phase 4 - Report Problems
   File system object [b]FF5208[/b] is linked as: /DataFiles/DamagedRecording.rec
   [b]cannot repair the data format error(s) in this file.
   cannot repair FF5208.[/b]
   ...

2. Anschließend wechselt man in das Verzeichnis mit der fehlerhaften Datei, und gibt dort ein
   ls -i
3. So erhält man die Inode-Nummer zu der fehlerhaften Datei.
4. Jetzt verwendet man das Tool jfs_debugfs, und gibt dort ein
   i <InodeNr>
5. Nun werden diverse Informationen, u.a. die Dateigröße (di_size) und die eingetragene Blockanzahl (di_nblocks) angezeigt.
6. Mit diesem Tool ist es zudem möglich, den falschen Eintrag in di_nblocks zu reparieren (und die Datei somit vor dem „Fresser“ zu retten) oder auch den Schaden künstlich zu erzeugen.

Und weiter?

Nachdem ich nun fast ein halbes Jahr lang unermüdliche Arbeit und Engagement in die Diagnose und Aufarbeitung dieser Geräte-Fehlfunktion investiert habe, dürfte die Vorarbeit soweit geleistet sein, dass das eigentliche Fixen des Bugs für die Firmware-Entwickler nun eine Kleinigkeit sein sollte.
Zumindest dürfte der Aufwand deutlich geringer ausfallen, als wenn alle betroffenen Kunden nun ihre Geräte zur Reparatur einsenden würden.

Ich würde mir nun abschließend wünschen, dass das Problem jetzt, da es nachgewiesen und ergründet ist, (wenigstens) von Topfield Europe (Gerti?) ernstgenommen wird, und meine Erkenntnisse an die Entwickler in Korea weitergeleitet werden.
Wann (und ob) es jemals eine korrigierte Firmware geben wird, müssen wir dann natürlich abwarten.


Und zum Schluss möchte ich mich an dieser Stelle ganz herzlich bedanken bei Bernhard und Herbert für das geduldige und unermüdliche Durchführen immer neuer Tests, bei Tino Reichardt (einem der JFS-Mitentwickler), der mir mit viel Zeit und persönlichem Einsatz bei der Diagnose und Reparatur geholfen hat, und Alex für unendlich viele praktische und zielführende Tipps

[chris86]

Nachtrag:

Wenn (falls) sich die Koreaner nun schon mal an die Schnittfunktion ransetzen sollten, möchte ich die Gelegenheit nutzen und gleich noch auf einen zweiten Bug der Firmware-Schnittroutine hinweisen. Dieser ist wesentlich weniger dramatisch (und außerdem bereits in MC 2.0 durch einen Workaround „unschädlich“ gemacht).
Aber er wäre auch sehr leicht zu beheben:

Hier die Beschreibung:
Das Schneiden kann, bedingt durch obige Erläuterung der Schnittfunktion, ausschließlich an Blockgrenzen des Dateisystems (Blockgröße 4096) erfolgen. Zudem muss jede Aufnahme mit einem TS-Paketstart beginnen.

Beauftragt man nun einen Schnitt an einer bestimmten Abspiel-Position x, so sucht die Firmware ausgehend von der Byte-Adresse dieser Position (x * 9024) die nächste Stelle, wo Blockgrenze der HDD und Start eines TS-Pakets zusammenfallen.
Im Prinzip müssen dafür lediglich die in der Nähe befindlichen Blockgrenzen (Adressen, die durch 4096 teilbar sind) darauf untersucht werden, ob sich hier ein Paketanfang befindet.

Bei dieser Überprüfung sieht der Topf allerdings nur nach, ob sich an der Blockgrenze ein Sync-Byte (0x47 oder 'G' - markiert den TS-Paketstart) befindet.
Er prüft aber nicht, ob es sich hierbei wirklich um einen Paketstart handelt. Wenn also an der entsprechenden Stelle zufällig innerhalb eines Pakets der Wert 0x47 vorkommt, wird einfach an dieser Stelle geschnitten. Eine so bearbeitete Aufnahme ist zerstört und lässt sich nicht mehr wiedergeben.

Lösen könnte man dies zum Beispiel sehr einfach, indem man für den (möglicherweise) gefundenen Paketstart nochmals testet, ob die nächsten 10 jeweils im Abstand von 192 (bzw. in Australien 188) folgenden Bytes ebenfalls Sync-Bytes (0x47) sind.
Wenn ja --> Paketanfang gefunden, wenn nein --> weitersuchen!

Bei Bedarf kann ich für dieses zweite Problem ein kurzes Testvideo zur Verfügung stellen, welches beim Schneiden auf jedem Topf garantiert zu dem beschriebenen Fehlverhalten führt.

[Twilight]

chris, mir steht der mund offen und ich bin begeistert von deiner doktor arbeit

meinen tiefsten und eine tiefe von mir

twilight

[Bernhard75045]

Auch ich möchte mich bei Christian bedanken für seine unermüdliche Arbeit.

Ein kleiner Nebeneffekt ist - zumindest bei mir - beim vielen Testen und Schneiden aufgetreten:

Auf meinem 5500er hatte ich zum Schneiden zuletzt mit den - eigentlich weniger bekannten (Warum nur??) - TAPs CutADS und CutFiles gearbeitet, die mir deutlich "angenehmer" waren als das sicherlich ebenfalls sehr gute Schnitt-TAP von flechumer; das hatte ich - trotz vorhandener Lizenz - zuletzt gar nicht mehr verwendet (mittlerweile kann ich mich nicht mal mehr erinnern, wie es hieß ). OK, ich hätte mich damit wohl nur etwas mehr beschäftigen müssen. Aber es gibt schließlich Schöneres mit dem Topf zu machen als Filme zu schneiden...
Als ich dann den SRP bekam war ich anfangs etwas traurig, dass mir diese zwischenzeitlich so lieb gewordenen TAPs hier nicht mehr zur Verfügung standen. Als Alternative kamen also wohl nur die "interne" (leider auch recht unkomfortable) Schnittfunktion oder der MovieCutter in Frage.

Als ich zum ersten Mal mit dem MC schnitt dauerte es eine geraume Weile, bis ich mich damit wirklich zurecht fand. (Wie schrieb Firebird damals: "es empfiehlt sich, die ersten Schnittversuche mit weniger wichtigen Dateien zu machen...". )

Mittlerweile bin ich mit dem "Muh-Vieh-Kater" derart "fit", die Handhabung ist mir derart geläufig, dass ich den früheren TAPs überhaupt nicht mehr nachtrauere. Ja, ich weiß die Vorzüge des MC sehr zu schätzen und will keinesfalls mehr darauf verzichten. Schneiden mit dem MC macht mittlerweile richtig Spaß!

Und: es ist einfach klasse, dass es in unserer Forums-Gemeinschaft so viele Leute gibt, die sich den vielen größeren und kleineren Problemen und deren Behebungdurch TAPs, Fehlersuchen und Hilfsprogrammen annehmen und dabei oft sehr, sehr viel Freizeit und "Herzblut" investieren.

Ich denke, das kann man nicht oft genug sagen!

[klassikmann]

Ich kann mich Twilight und Bernhard nur anschließen: Das ist eine Meisterleistung von chris86.

Den Hut zieh
Herbert

[macfan]

und an Chris für seine Heidenarbeit! Hoffentlich wird nun der Fehler bald in Korea behoben.

Gruß, Horst

[Roemer]

Das ist eine hochprofessionelle Analyse. Hut ab!

Was ich für mich erst mal mitnehme: der gewöhnliche Vor- und Nachlauf-Abknipser ist wohl weitestgehend aus dem Schneider, denn dabei werden kaum je 4 GB Dateigröße erreicht?!

[chris86]

Was ich für mich erst mal mitnehme: der gewöhnliche Vor- und Nachlauf-Abknipser ist wohl weitestgehend aus dem Schneider

Leider nicht korrekt! Warst du nicht auch schonmal betroffen...?

1.) Der MovieCutter ("meine" Version) "provoziert" das Problem gewissermaßen. siehe hier
Der Grund dafür ist, dass ansonsten ein kleines Teilstück des Aufnahme-Endes hinter dem weggeschnittenen Nachlauf verbleibt. Dieses sorgt im besten Fall für eine kurze Bildstörung, im schlechtesten Fall kann es den Topf zum Absturz bringen. Und es bereitet Probleme beim Abspielen am PC.

2.) Mir liegen nicht genügend Testdaten vor, um mit Sicherheit ausschließen zu können, dass der Fehler auch auftreten kann, wenn das Rest-File die 4 GB Grenze überschreitet. Oder andere Faktoren hinzukommen.