MovieCutter

[chris86]

Hallo Herbert,

jetzt habe ich mal eine ganz doofe Frage: Wie hast du es geschafft, dass fsck tatsächlich eine Prüfung durchführt?
Das kommt da bei mir raus:

Code: Alles auswählen

# fsck -n /dev/sda2
fsck (busybox 1.14.2, 2009-07-11 00:32:06    )
# jfs_fsck -n /dev/sda2
sh: jfs_fsck: command not found
# ./jfs_fsck -n /dev/sda2
sh: ./jfs_fsck: No such file or directory
# ./fsck -n /dev/sda2
sh: ./fsck: No such file or directory

Ich habe auch schon auf die aktuellste Version von TMSTelnet aktualisiert. Dann ändert sich zwar die Versionsnr. auf 2014 - aber sonst tut sich nichts...
Und "jfs_fsck" gibts bei mir anscheinend überhaupt nicht...

[FireBird]

[klassikmann]

[quote="chris86"]Wie hast du es geschafft, dass fsck tatsächlich eine Prüfung durchführt?
...
Und "jfs_fsck" gibts bei mir anscheinend überhaupt nicht...[/quote]"Irgendwo" hier im Forum gibt es die jfs_utils; ich habe aber gerade den Link nicht parat. Ich schicke Dir die Utils gleich per E-Mail.

Auf der Festplatte habe ich mir dann ein Verzeichnis eingerichtet mit den jfs_utils (nicht vergessen das x-Bit für die Tools zu setzen) und der busybox. Die Dateien kopiere ich mir dass in einer Telnet-Session auf ein Verzeichnis der Root-Partion, von dort starte ich den jfs_fsck.

Gruß
Herbert

[FireBird]

[quote="klassikmann"]"Irgendwo" hier im Forum [/quote]
Vielleicht hilft Dir mein Smilie?

[klassikmann]

Vielleicht hilft Dir mein Smilie?

Mist, Du warst schneller.

Gruß
Herbert

[Wolfman]

Das ist schade! Wenn wir dem Problem jemals auf die Schliche kommen wollen, braucht es Leute, die das Problem nachstellen können (und das auch tun).
Bei mir (und den meisten anderen) ist es bislang nicht aufgetreten, weshalb ich ohne Tester nur im Dunkeln herumstochern kann...

Mal kucken, sobald ich mal wieder ein paar beieinander habe, die eh zum Löschen anstehen

Das wiederum ist interessant! Wäre super, wenn du die genauen Bezeichnungen nachliefern könntest - vielleicht ergibt sich ja da ein Muster...?

Sobald die Töpfe mal aufnahmetechnisch eine Auszeit haben, schmeiß ich HDDInfo an

[chris86]

So, ich habe jetzt eine Reihe von Test-Aufnahmen gemacht, und diese mit der aktuellen MC 2.0h Version geschnitten. Dazwischen immer wieder fsck.

(Danke für gewisse Smileys und gewisse E-Mails! Bei meiner Blindheit muss es aber beim nächsten Mal schon mindestens der hier sein: ^^)

Ergebnisse:

1. Es trat kein einziges Mal die "File system XYZ object is linked as ..." Meldung auf - die vermutlich den Aufnahmenfresser ankündigt. (passt auch dazu, dass er bei mir nicht auftritt) - Diese Meldung müssen wir also verfolgen!
2. fsck meldet eine ganze Reihe von Fehlern. Es wäre wahnsinnig toll, wenn sich jemand finden könnte, der ein bisschen Ahnung von JFS hat, und erklären kann, was die fett gedruckten Meldungen im Einzelnen bedeuten. Wenn ihr jemanden kennt, schickt ihn vorbei ;-)
3. Sehr interessant ist: Wenn man eine Aufnahme tätigt, und währenddessen (oder kurz danach) fsck laufen lässt, dann werden unzählige Fehler wie der rote gemeldet.
   Ich gehe davon aus, dass hier ein Stück der Aufnahme (vermutlich das Ende) noch nicht korrekt geschrieben wurde. Das würde auch die End-Zerstörung erklären, wenn man ohne Reboot schneidet.
   Nach einem sync sind diese roten Meldungen verschwunden! (Damit lässt sich nach ersten Tests auch die End-Zerstörung beheben - sowohl bei der internen Schnittfunktion als auch bei MC)
4. Das angehängte Log ist direkt nach einem Schnittvorgang mit MC entstanden. Wiederum interessant: Die bunten Meldungen veschwinden, wenn man ein sync ausführt.
   Womöglich darf einfach keine weitere Schnittoperation ausgeführt werden, solange diese Fehler bestehen?

Code: Alles auswählen

jfs_fsck version 1.1.15, 04-Mar-2011
processing started: 1/1/2000 0:19:56
Filesystem is currently mounted.
WARNING: Checking a mounted filesystem does not produce dependable results.
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:  243665712
**Phase 1 - Check Blocks, Files/Directories, and  Directory Entries
**Phase 2 - Count links
**Phase 3 - Duplicate Block Rescan and Directory Connectedness
**Phase 4 - Report Problems
**Phase 5 - Check Connectivity
**Phase 6 - Perform Approved Corrections
**Phase 7 - Verify File/Directory Allocation Maps
[b]The Inode Allocation Map has an incorrect number of free inodes value (F).
The Inode Allocation Map control information has an incorrect number of free inodes value for AG F1.
Errors detected in the Fileset File/Directory Allocation Map control information. (F)[/b]
**Phase 8 - Verify Disk Allocation Maps
[b][color=red]1 consecutive blocks observed available but pmap (9216, 11, 2) indicates they are allocated.
Incorrect number free detected in dmap 9216.
1 consecutive blocks observed available but pmap (12290, 27, 17) indicates they are allocated.[/color] 
[color=blue]Incorrect number free detected in dmap 12290.
Incorrect internal (6) value detected in DM page 12290.
Incorrect internal (27) value detected in DM page 12290.
Incorrect leaf (112) value detected in DM page 12290.[/color]
Incorrect number of free blocks detected in Block Map Control Page.
Incorrect number of free blocks in AG 1 detected in Block Map Control Page.
Incorrect number of free blocks in AG 20 detected in Block Map Control Page.
Incorrect number of free blocks in AG 36 detected in Block Map Control Page.
Incorrect number of free blocks in AG 48 detected in Block Map Control Page.
[color=blue]Descrepancies detected between observed block allocations and pmaps.
Inconsistencies detected in leaf values (DM).
Inconsistencies detected in internal values (DM).
Incorrect data detected in pages (DM).[/color]
Discrepancies detected in the Block Map Control Page AG free count list.
Incorrect data detected in the Block Map Control Page. 
[color=blue]Incorrect data detected in disk allocation structures.[/color]
Incorrect data detected in disk allocation control structures.[/b]
Filesystem Summary:
Blocks in use for inodes:  252
Inode count:  2016
File count:  614
Directory count:  43
Block count:  243665712
Free block count:  224882342
974662848 kilobytes total disk space.
      217 kilobytes in 43 directories.
 74950459 kilobytes in 614 user files.
        0 kilobytes in extended attributes
        0 kilobytes in access control lists
   183238 kilobytes reserved for system use.
899529368 kilobytes are available for use.
File system checked READ ONLY.
Filesystem is dirty.
processing terminated:  1/1/2000 0:20:52  with return code: 0  exit code: 4.

Und das da hätten wir auch noch (nach einem anderen Schnitt)

Code: Alles auswählen

Discrepancies detected in the Free IAG List. (F,2)
Inode Allocation Group F14 is inconsistent.
Discrepancies detected in the Free IAG List. (F,3)
Discrepancies detected in the Free Inode Extent List for Allocation Group F50. (2)
Discrepancies detected in the Free Inode List for Allocation Group F50. (3)
Inode Allocation Group F50 is inconsistent.
The Free Inode Allocation Group List is inconsistent (F).
The Inode Allocation Map has an incorrect number of backed inodes value (F).
The Inode Allocation Map has an incorrect number of free inodes value (F).
The Inode Allocation Map control information has an incorrect number of free inodes value for AG F1.
The Inode Allocation Map control information has an incorrect number of backed inodes value for AG F22.
The Inode Allocation Map control information has an incorrect number of free inodes value for AG F22.
Errors detected in the Fileset File/Directory Allocation Map control information. (F)
Errors detected in the Fileset File/Directory Allocation Map. (F)

--> Könnte es sein, dass die FW da ganz schön rumpfuscht beim Schneiden?

[chris86]

Zu den MC-Testversionen von chris86 komme ich erst morgen Früh.

Könntest du bitte zusätzlich den -v(erbose) Parameter verwenden? Dann kommen ein paar mehr relevante Informationen raus...

Sobald die Töpfe mal aufnahmetechnisch eine Auszeit haben, schmeiß ich HDDInfo an

Danke!
Und Aufruf an alle anderen vom Aufnahmenfresser Betroffenen:
Bitte meldet euch, und schreibt hier, welche Festplatte (Marke, Modell) ihr in eurem Topf verwendet! Und ob diese Original von Topfield verbaut wurde!

[Roemer]

Schau dir doch mal dieses Dokument an, insbesondere den Abschnitt 3.0 ATA-7 Streaming Command Set. Vielleicht ist es hilfreich, insbesondere der Hinweis: It is important to allow drives some error recovery time. At least three revolution times (3 x 8.34 ms) plus the data transfer time is recommended. könnte zu dem rot markierten Text in #1147 passen.

Vielleicht musst du der Platte ab und zu etwas Zeit geben, die Daten wegzuschreiben.

[klassikmann]

So ich habe jetzt die Tests mit der Spezialversion des MC 2.0h (ohne Behandlung des letzten Segments) abgeschlossenen. Ich habe keine Tests mit MC 1.4 plus neuer FBLib durchgeführt. Die Logs des jfs_fsck sind m.E. unspektakulär. Interessanter ist das Verhalten der Spezialversion.

Aber Schritt für Schritt:

1. Drei neue Aufnahmen gemacht. Im Gegensatz zu den gestrigen Tests mit allen TAPs der Autostart (siehe meine Signatur). TimeShift ist aktiv.

2. ./jfs_fsck -n -v (Log1.txt)

3. Zwei der drei Aufnahmen mit der Spezialversion geschnitten

4. ./jfs_fsck -n -v (Log2.txt)

5. Normaler Reboot via Standby

6. ./jfs_fsck -n -v (Log3.txt)

7. Versuch eines Reboot mit Festplattenüberprüfung (via tma1, Sleep-Taste, Freeze)
nicht erfolgreich. Schneiden mit der Spezialversion von MC scheint den Freeze zu vermeiden.

8. Harter Reboot (PowerOff), Festplattenüberprüfung: Alle geschnittenen Aufnahmen vorhanden

9. ./jfs_fsck -n -v (Log4.txt)

Gruß
Herbert

[db1]

Ich hab auch eine selbst nachgerüstete 2GB WD

Könnte es nicht auch mit den Umlauten und der Umstellung auf UTF-8 zu tun haben?
Die geschredderte Datei hatte ja einen solchen im filenamen.

edit: Firmware ist bei mir die ORF Testversion, vielleicht auch noch wichtig?

[super-mentor]

Und Aufruf an alle anderen vom Aufnahmenfresser Betroffenen:
Bitte meldet euch, und schreibt hier, welche Festplatte (Marke, Modell) ihr in eurem Topf verwendet! Und ob diese Original von Topfield verbaut wurde!

Bei mir ist von Topfield eingebaut:
WDC WD10EURS-630AB!

[chris86]

Ich hab auch eine selbst nachgerüstete 2GB WD

Bei mir ist von Topfield eingebaut:
WDC WD10EURS-630AB!

Damit haben wir schonmal eines schriftlich:
Der furchtbare Aufnahmenfresser ist belang also nur bei WD-Festplatten aufgetreten.

Schau dir doch mal dieses Dokument an, insbesondere den Abschnitt 3.0 ATA-7 Streaming Command Set. Vielleicht ist es hilfreich, insbesondere der Hinweis: It is important to allow drives some error recovery time. At least three revolution times (3 x 8.34 ms) plus the data transfer time is recommended. könnte zu dem rot markierten Text in #1147 passen.

Vielleicht musst du der Platte ab und zu etwas Zeit geben, die Daten wegzuschreiben.

In diese Richtung gehen meine Gedanken ja auch die ganze Zeit. Aber bei der neuen Version hat die Platte schon vor und nach jeder Schnittoperation jeweils 300 ms zusätzliche Zeit. UND bei dem o.g. Test kam ja auch noch die Zeitspanne dazu, die ich brauchte, um den MC zu beenden und den fsck-Befehl einzutippen (das waren mindestens ein paar Sekunden!)

Könnte es nicht auch mit den Umlauten und der Umstellung auf UTF-8 zu tun haben?
Die geschredderte Datei hatte ja einen solchen im filenamen.

edit: Firmware ist bei mir die ORF Testversion, vielleicht auch noch wichtig?

ALLES ist möglich. Es sind allerdings auch schon Aufnahmen ohne Umlaute geschreddert worden... Und die österreichische Firmware haben bestimmt nicht alle Betroffenen installiert...

[Twilight]

Damit haben wir schonmal eines schriftlich:
Der furchtbare Aufnahmenfresser ist belang also nur bei WD-Festplatten aufgetreten.

nun, dann mußt du aber auch fragen welche platte die leute drin haben wo es noch nicht passiert ist. ich hab auch eine WD drin...

die meissten user haben ein WD drin, weil diese hier sehr häufig empfohlen wird. deswegen verwundert mich diese umfrage vorerst nicht.

twilight

[super-mentor]

Umlaute:

Bei meinen verschwundenen *.rec-Dateien waren keine Umlaute im Spiel. Soweit diese nicht vom TAP IQTuner umgewandelt wurden, was nicht immer gelingt, habe ich sie manuell entfernt, damit die Aufnahmen (nach dem Schnitt auf der internen HD) auf eine externe HD (NTSF-formatiert) kopierbar sind.

[chris86]

So ich habe jetzt die Tests mit der Spezialversion des MC 2.0h (ohne Behandlung des letzten Segments) abgeschlossenen. Ich habe keine Tests mit MC 1.4 plus neuer FBLib durchgeführt. Die Logs des jfs_fsck sind m.E. unspektakulär.

Das nennst du 'unspektakulär'!? Da wird aber ein ganzer Haufen von Fehlern gemeldet, u.a. Blöcke, die zwar beschrieben aber nicht allokiert wurden usw.!
War Timeshift während dem Test aktiv? Das würde das vielleicht noch erklären.
Ansonsten wundert mich da gar nichts, wenn Dateien verschwinden...

Achja, und das fand ich auch interessant:
Anscheinend verschwinden nicht nur Aufnahmen, sondern auch Dateien, die definitiv nicht geschnitten wurden, wie z.B. die Event.db von SmartEPG...

Code: Alles auswählen

One or more directory entry found for unallocated inode F483328.
Directory entries for unallocated files have been detected.
**Phase 4 - Report Problems
File system object FF483328 is linked as: /ProgramFiles/Settings/SmartEPG_TMS/Event.db
The path(s) refer to an unallocated file.

Interessanter ist das Verhalten der Spezialversion.
Aber Schritt für Schritt:

1. Drei neue Aufnahmen gemacht. Im Gegensatz zu den gestrigen Tests mit allen TAPs der Autostart (siehe meine Signatur). TimeShift ist aktiv.

Ach okay, das beantwortet meine Frage von oben.

2. ./jfs_fsck -n -v (Log1.txt)

3. Zwei der drei Aufnahmen mit der Spezialversion geschnitten

4. ./jfs_fsck -n -v (Log2.txt)

5. Normaler Reboot via Standby

6. ./jfs_fsck -n -v (Log3.txt)

7. Versuch eines Reboot mit Festplattenüberprüfung (via tma1, Sleep-Taste, Freeze)
nicht erfolgreich. Schneiden mit der Spezialversion von MC scheint den Freeze zu vermeiden.

Das letzte ist ein Fehlschluss! Bei deinem letzten Test mit der vorigen Version hast du auch schon berichtet, dass kein Freeze aufgetreten ist. Denke, das hat eher mit der Startreihenfolge der TAPs zu tun - oder ist ebenfalls ein sporadisches Problem...

8. Harter Reboot (PowerOff), Festplattenüberprüfung: Alle geschnittenen Aufnahmen vorhanden

Gut! Das bestätigt die Vermutung, dass nur Dateien verschwinden, die schon zuvor bei fsck als beschädigt gemeldet werden.

Und es gibt einen (weiteren) Hinweis darauf, dass es möglicherweise mit dem letzten Segment zu tun haben könnte...

Was aber vollkommen verwirrend ist:
Diese "Spezial"-Version unterscheidet sich von der 2.0h praktisch nur in einer einzigen relevanten Zeile. Das ist ein HDD_Rename... Und es muss doch möglich sein, eine Datei mit Hilfe der von Topfied veröffentlichten TAP-API umzubenennen, ohne dass dabei gleich das gesamte Dateisystem zerbröselt wird! - Alles sehr verwirrend

(Deshalb glaube ich da eher an einen "Zufallstreffer". Soll heißen, das Problem liegt woanders, aber die zusätzliche Umbenennung trägt dazu bei, dass es öfters auftritt, und so schneller bemerkt wird...)

9. ./jfs_fsck -n -v (Log4.txt)

Ist dieser Log direkt nach dem Neustart (bei dem die HDD geprüft wurde!) gemacht worden? Wenigstens da müsste das FS doch intakt sein... Und v.a. nicht neue Dateien defekt sein...

[chris86]

nun, dann mußt du aber auch fragen welche platte die leute drin haben wo es noch nicht passiert ist. ich hab auch eine WD drin...

die meissten user haben ein WD drin, weil diese hier sehr häufig empfohlen wird. deswegen verwundert mich diese umfrage vorerst nicht.

twilight

Ich gehe eigentlich davon aus, dass die meisten User eine Seagate drinnen haben, weil Topfield (soweit ich weiß - supermentor spricht allerdings dagegen) ausschließlich diese verbaut und ausschließlich diese zertifiziert hat.

Aber du hast recht, die Gegenprobe sollten wir machen:
Also, wer hat schon häufiger mit MC 2.0 Aufnahmen geschnitten, und seitdem mindestens eine Festplattenüberprüfung gehabt, bei der keine der Aufnahmen verschwunden ist? Und welche Festplatte (Marke, ggf. Modell) ist bei euch eingebaut?

[Igodauge]

Umlaute:

Bei meinen verschwundenen *.rec-Dateien waren keine Umlaute im Spiel. Soweit diese nicht vom TAP IQTuner umgewandelt wurden, was nicht immer gelingt, habe ich sie manuell entfernt, damit die Aufnahmen (nach dem Schnitt auf der internen HD) auf eine externe HD (NTSF-formatiert) kopierbar sind.

Eine Frage nur nebenbei, ohne etwas andeuten zu wollen. Welche Version von SE hast du im Einsatz? Ist das schon eine 6er?

(Ich will nix andeuten, suche aber auch die Ursache für ein Phänomen das die SE Datenbank zerbröselt, sporadisch den Topf blockiert und abschaltet und manche Aufnahmen verschwinden lässt. Aber noch mit altem MC, Seagate und erst seit wenigen Wochen;-) )

[chris86]

Dann mal viel Erfolg bei der Suche! Ich hoffe, du hast mehr Glück dabei, als ich bisher

[Twilight]

Soweit diese nicht vom TAP IQTuner umgewandelt wurden, was nicht immer gelingt, habe ich sie manuell entfernt, damit die Aufnahmen (nach dem Schnitt auf der internen HD) auf eine externe HD (NTSF-formatiert) kopierbar sind.

mit BGC wäre das nicht notwendig...wenn BGC weiß das es sich um eine NTFS platte handelt kümmert es sich um alles notwendige

Ich gehe eigentlich davon aus, dass die meisten User eine Seagate drinnen haben, weil Topfield (soweit ich weiß - supermentor spricht allerdings dagegen) ausschließlich diese verbaut und ausschließlich diese zertifiziert hat.

das stimmt so nicht, ich glaube es wurden auch viele hitachi verbaut

Aber du hast recht, die Gegenprobe sollten wir machen:
Also, wer hat schon häufiger mit MC 2.0 Aufnahmen geschnitten, und seitdem mindestens eine Festplattenüberprüfung gehabt, bei der keine der Aufnahmen verschwunden ist? Und welche Festplatte (Marke, ggf. Modell) ist bei euch eingebaut?

aus meinen berichten siehst du das ich viel geschnitten habe, ohne das datein verschwunden sind, habe eine WD platte.

twilight