MovieCutter

[FireBird]

[*]@Firebird: Denkst du, es wäre sinnvoll (und technisch möglich), das Flushen des Caches, was z.B. auch hdparm -f macht, durch MC auszulösen?

Ich kann mir das einfach nicht vorstellen, denn dann würden bei jedem Crash Aufnahmen verschwinden und so mancher TAP-Tester hätte permanent leere Festplatten. Klar kann man mit system() von einem TAP aus einen Shell-Befehl aufrufen und hdparm ist Bestandteil der busybox.

[FireBird]

@Herbert: wie "behebst" Du einen eingefrorenen Topf? Drückst Du auf die Standby-Taste und wartest, bis sich der Topf abschaltet, oder machst Du das über den Power-Schalter auf der Rückseite?

[chris86]

Am 11.2.14 hatte ich die Version MovieCutter V2.0h final installiert. Seitdem traten folgende Fehler auf:

Wiedergabe eines Filmes: Bild friert ein, keine Funktion mehr möglich. Ausschalten. Neustart. Festplatte wird geprüft. Die *.REC-Datei ist weg, *.NAV und *.INFO sind noch da.

- Passiert das jedes Mal, wenn du eine Aufnahme wiedergibst!?
- War die Aufnahme, bei der das passiert ist, zuvor geschnitten, oder noch "jungfräulich"?
- War sie gerade eben aufgenommen worden (ohne Neustart dazwischen)?
- War während der Wiedergabe der MC aktiv? (im Hintergrund / OSD eingeblendet?)

Nach weiterem Neustart eine Serie geschnitten. Meldung in etwa: "Die NAV-Datei ist kürzer als...
Möchten Sie trotzdem schneiden ?"

* Wie entsteht diese Ungleichheit ? Kann man etwas dagegen tun ?
* Wenn man trotzdem schneidet, was kann passieren ?

Diese Meldung ist harmlos. Das "Schlimmste" was dadurch passieren kann, ist dass die Anzeigen des MC (Zeiten / Fortschrittsbalken / etc.) unexakt werden. Das wirkt sich aber nicht aufs Schneiden aus.
Trotzdem sollte der Fall _eigentlich_ nicht auftreten. Könnte es sein, dass dein Empfang zu wünschen übrig lässt, und es während der Aufnahme "Störungen" (Lücken) gab?

[super-mentor]

Zuerst danke für Deine Geduld und Unterstützung !
Zu Deinen Fragen der Reihe nach:

* Seit Wochen das erste Mal
* Zuvor geschnitten (2 Tage vorher)
* 2 Tage zuvor aufgenommen
* MC war nicht aktiv

* Keine Störungen. Mein Empfang ist super.

[klassikmann]

[quote="FireBird"]@Herbert: wie "behebst" Du einen eingefrorenen Topf? Drückst Du auf die Standby-Taste und wartest, bis sich der Topf abschaltet, oder machst Du das über den Power-Schalter auf der Rückseite?[/quote]Standby-Taste

Gruß
Herbert

[db1]

Was mir dazu einfällt. Wenn es wirklich ein Problem mit dem Dateisystem nach dem Schneiden gibt, könnte das vielleicht durch verschieben der Datei in einen anderen Ordner behoben werden.
@Herbert: Wenn du das Dateifressen nun beinahe reproduzieren kannst, könntest du einmal versuchen, die geschnittenen Dateien vor dem Freeze in einen anderen Ordner (und ev. auch wieder zurück ins root) zu verschieben.

[Twilight]

ich würde die sache mal von einer anderen sache angehen:

vor und nach dem schneiden eine analyse mit jfs_fsck zu machen und die ergebnisse zu posten mit dem feedback ob etwas verschwunden ist.

twilight

[Bickabunk]

Hi,

ich lese ja hier nur gelegentlich mit und weiß nicht, ob Folgendes schon mal probiert wurde:
1) Eine beliebige Sendung aufnehmen (braucht nicht lang zu sein, vielleicht 5min)
2) Sendung mit MovieCutter schneiden.
3) MovieCutter eventuell aus AutoStart rausnehmen, vielleicht sogar alle TAPs
4) Topf normal runter fahren und wieder anschalten
5) Topf bewußt zu einer HDD Prüfung führen (sprich: Stecker ziehen und wieder einstöpseln)

Wenn nun eine oder mehrere Aufnahmen verschwunden sind, hilft das bei der Fehlersuche? Ich meine, dann kann es ja nur sein, dass es tatsächlich nicht direkt am MC liegt.
Stimmt es, dass das Dateisystem JFS ist?

MfG Stefan Fröhlich
42 ;-)

[klassikmann]

ich würde die sache mal von einer anderen sache angehen:

vor und nach dem schneiden eine analyse mit jfs_fsck zu machen und die ergebnisse zu posten mit dem feedback ob etwas verschwunden ist.

Werde ich gleich machen, obwohl man ein fsck eines gemounteten Filesystems nicht tun sollte. Selbst bei einem readonly Check sind die Ergebnisse nicht unbedingt aussagekräftig (WARNING: Checking a mounted filesystem does not produce dependable results.). Wenn sich jedoch bei beiden Läufen Unterschiede zeigen, kann uns das weiterhelfen.

Gruß
Herbert

[Twilight]

ich habe schon einige platten so wieder zum leben erweckt, die warnung ist mir bekannt...schlechte ergebnisse hatte ich dadurch allerdings noch nie

twilight

[klassikmann]

So ich habe gerade einen umfangreichen Testlauf durchgeführt, den ich hier jetzt dokumentiere. Die Ergebnisse sprechen zumindest für mich keine eindeutige Sprache. Die betroffene Aufnahme findet sich aber in verschiedenen jfs_fsck.

Also hier der Ablauf:

1. Aufnahme „Das Erste HD“: „Tierärztin Dr. Mertens (25)“ mit fünf Minuten Vor- und Nachlauf

2. Timeshift abgeschaltet (um Festplattenaktivität zu verringern)

3. Alle TAPs beendet (um Festplattenaktivität zu verringern), bis auf TMSTelnetd (wegen jfs_fsck via putty)

4. jfs_fsck -n (Log1.txt)

5. Normaler Reboot (via Standby) ohne TAPs, Start TMSTelnetd

6. jfs_fsck -n (Log2.txt)

7. kein "jfs_fsck -f" durchgeführt, sonder nochmal normaler Reboot ohne TAPs, Start TMSTelnetd

8. jfs_fsck -n (Log3.txt)

9. jfs_fsck -f (Log4.txt)

10. Normaler Reboot ohne TAPs, Start TMSTelnetd

11. jfs_fsck -n (Log5.txt)

12. Start MC 2.0h, Schnitt der Testaufnahme (Vor- und Nachlauf), Stop MC 2.0h

13. jfs_fsck -n (Log6.txt)

14. Normaler Reboot ohne TAPs, Start TMSTelnetd

15. jfs_fsck -n (Log7.txt)

16. jfs_fsck -f (Log8.txt)

17. Start restlicher Autostart-TAPs sowie tma1
- Kein Freeze durch Sleep-Taste, damit auch keine Festplattenprüfung nach Reboot möglich
- stattdessen normaler Reboot mit TAPs

18. jfs_fsck -n (Log9.txt)

19. Start tma1 starten
- Sleep-Taste -> Freeze
- Reboot via Standby
- Festplattenüberprüfung
- Geschnittene Aufnahme ist verschwunden

20. jfs_fsck -n (Log10.txt)

21. Timeshift wieder eingeschaltet

Das ist jetzt mein aktueller Stand.

Für mich ist es schwierig, die Meldungen des jfs_fsck eindeutig zu interpretieren, da ja auf einem gemounteten Filesystem gearbeitet wird.

Grüße
Herbert

[Twilight]

ein überprüfen der festplatte kannst du durch ein ausschalten via power schalter hinten am gerät auslösen.
so lange nach dem reboot keine aufnahme verschwindet sind die werte die du nun gesammelt hast noch nicht viel wert. erst wenn eine aufnahme verschwindet und wir die scans vor und nach dem reboot haben kann man mit den werten die du nun gesammelt hast eventuell etwas finden.

twilight

[chris86]

Danke an alle fürs Nachdenken und für die guten Tipps!

Was mir dazu einfällt. Wenn es wirklich ein Problem mit dem Dateisystem nach dem Schneiden gibt, könnte das vielleicht durch verschieben der Datei in einen anderen Ordner behoben werden.

Das könnte man mal probieren. Wenn das Dateisystem durchs Schneiden aber schonmal beschädigt wird, dann könnte eine weitere Schreib-Aktion mit dieser Datei u.U. allerdings auch noch größere Schäden anrichten...

ich würde die sache mal von einer anderen sache angehen:

vor und nach dem schneiden eine analyse mit jfs_fsck zu machen und die ergebnisse zu posten mit dem feedback ob etwas verschwunden ist.

Hervorragender Plan!

...weiß nicht, ob Folgendes schon mal probiert wurde:
1) Eine beliebige Sendung aufnehmen (braucht nicht lang zu sein, vielleicht 5min)
2) Sendung mit MovieCutter schneiden.
3) MovieCutter eventuell aus AutoStart rausnehmen, vielleicht sogar alle TAPs
4) Topf normal runter fahren und wieder anschalten
5) Topf bewußt zu einer HDD Prüfung führen (sprich: Stecker ziehen und wieder einstöpseln)

Wenn nun eine oder mehrere Aufnahmen verschwunden sind, hilft das bei der Fehlersuche? Ich meine, dann kann es ja nur sein, dass es tatsächlich nicht direkt am MC liegt.

Das haben wir (so oder ähnlich) ja schon mehrfach gemacht. Manchmal ist was weg - machmal nicht

[chris86]

Ich habe gerade ein paar Tests mit MC 1.4 und MC 2.0 durchgeführt. Zunächst habe ich vier Sendungen aufgenommen von denen ich zwei mit MC 2.0 geschnitten habe. Nach einer kontrollierten Festplattenüberprüfung (Freeze mittels tma1 + Sleep-Taste, siehe #1116) waren die beiden ungeschnittenen Aufnahmen noch da, aber eine (nicht beide) der mit MC 2.0 behandelten weg.

Danach habe ich zwei weitere Sendungen aufgenommen, die ich beide mit MC 1.4 geschnitten habe. Siehe da, keine verschwundenen Aufnahmen nach der Festplattenüberprüfung. Sicherheitshalber habe ich den Freeze mittels tma1 + Sleep-Taste nochmal wiederholt. Gleiches Ergebnis.

Was sagt uns das?

Danke dir fürs Testen!
Was sagt uns das nun? - Leider nicht viel. Denn da das Problem (bislang zumindest) nicht reproduzierbar auftrat, können wir nur mit Sicherheit sagen, dass es da ist, wenn es passiert. Wenn es nicht passiert - keine Ahnung

Des weiteren sagt es uns aber auch, dass du offenbar nicht die übliche (PVR-optimierte) Seagate-Festplatte benutzt, sondern eine andere von WD. Womöglich verarbeitet die ja irgendwelche Schreibzugriffe anders, als unsere Platten...?

So ich habe gerade einen umfangreichen Testlauf durchgeführt, den ich hier jetzt dokumentiere. Die Ergebnisse sprechen zumindest für mich keine eindeutige Sprache. Die betroffene Aufnahme findet sich aber in verschiedenen jfs_fsck.
(...)

Für mich ist es schwierig, die Meldungen des jfs_fsck eindeutig zu interpretieren, da ja auf einem gemounteten Filesystem gearbeitet wird.

Hervorragend!!!
Das scheint mir ein absoluter Volltreffer zu sein! Man sieht ja hier direkt schon, dass die Datei einen Fehler aufweist. Und dann verschwindet sie bei der nächsten Festplattenprüfung!

Leider fehlen auch mir die tieferen Linux- und JFS-Kenntnisse, um die Ausgaben genauer zu interpretieren...

Was mir nur auffällt:

• Warum werden da ständig (auch ohne Schnitt) Errors in der "File/Directory Allocation Map" angezeigt?
• Warum ist das Filesystem (selbst nach dem Reparieren) ständig als "Dirty" markiert? - ist das normal bei gemounteten Filesystems?
• und vor allem: Was bedeutet das hier genau?

  File system object FF4121 is linked as: /DataFiles/Tierärztin Dr. Mertens (25).rec
  cannot repair the data format error(s) in this file.
  cannot repair FF4121.

Aber auch ohne das genauer zu wissen, denke ich wir haben so eine Möglichkeit gefunden, das Problem zu diagnostizieren, ohne dass Crashes auftreten oder Aufnahmen im Orkus verschwinden müssen. Jipiieee!! :
Ziel ist es also, den MC so zu verändern, dass nach einer Schnittaktion die o.g. Meldung nicht mehr im fschk-Log auftaucht.

klassikmann:
Ich habe hier nochmal zwei modifizierte Versionen hochgeladen. Könntest du mit diesen beiden nochmal einen Testschnitt (mit fschk vor und nach dem Schnitt) durchführen, und nachsehen, ob es da genauso läuft? Wenn es bei einer Testaufnahme keine Probleme gibt, vielleicht auch noch mit ein oder zwei anderen?
Natürlich brauchst du dieses Mal nicht wieder das ganze Prozedere mit Neustart und zig Logs betreiben - ich denke wir können nach diesem ausgiebigen Test davon ausgehen, dass Aufnahmen, die den o.g. Fehler im fschk zeigen, über kurz oder lang irgendwann verschwinden werden ;-)

1. MC 2.0h (ohne Letztes Segment)
2. MC 1.4 mit neuer FBLib (von Alex)

Ich werde mich gleich mal dransetzen, und dieselben Tests durchführen, und nachsehen, was mein Topf so dazu zu sagen hat...

[chris86]

19. Start tma1 starten
- Sleep-Taste -> Freeze
- Reboot via Standby
- Festplattenüberprüfung
- Geschnittene Aufnahme ist verschwunden

ein überprüfen der festplatte kannst du durch ein ausschalten via power schalter hinten am gerät auslösen.
so lange nach dem reboot keine aufnahme verschwindet sind die werte die du nun gesammelt hast noch nicht viel wert. erst wenn eine aufnahme verschwindet und wir die scans vor und nach dem reboot haben kann man mit den werten die du nun gesammelt hast eventuell etwas finden.

Aber sicher sind die was wert! Sogar Gold wert!
Er schreibt doch, dass die Aufnahme nach dem nächsten Reboot mit Festplattenprüfung tatsächlich verschwunden ist... (auch wenn er den Reboot anders ausgelöst hat - aber das ist ja völlig egal)

[Twilight]

das hab ich übersehn...dann "passt" es ja

twilight

[Roemer]

[quote="chris86"]Des weiteren sagt es uns aber auch, dass du offenbar nicht die übliche (PVR-optimierte) Seagate-Festplatte benutzt, sondern eine andere von WD. Womöglich verarbeitet die ja irgendwelche Schreibzugriffe anders, als unsere Platten...?
[/quote]

Nur mal so ein Einwurf von mir: habt ihr mal untersucht, ob die Dateiverluste nur bei bestimmten Plattentypen (AV-optimiert bzw. nicht AV-optimiert) auftreten? btw., die WD-EURS und -EURX sind ebenfalls AV-optimiert.

[Wolfman]

Ich hatte ja seither keine verlorenen Aufnahmen mehr (hab allerdings auch nichts mehr getestet) - aber wenn, dann waren die beim 2410 M mit einer WD, beim 2410 mit einer Seagate passierte nix (genaue Bezeichnung der Platten müsste ich nachliefern).

Ich sags aber gleich: die WD baute ich ein, nachdem die vorherige Seagate kaputt war und da kommt keine Sie geht oder Seagate nicht mehr rein

[chris86]

[quote="Wolfman"]Ich hatte ja seither keine verlorenen Aufnahmen mehr (hab allerdings auch nichts mehr getestet)[/quote]
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...

[quote="Wolfman"]aber wenn, dann waren die beim 2410 M mit einer WD, beim 2410 mit einer Seagate passierte nix (genaue Bezeichnung der Platten müsste ich nachliefern).[/quote]
Das wiederum ist interessant! Wäre super, wenn du die genauen Bezeichnungen nachliefern könntest - vielleicht ergibt sich ja da ein Muster...?

[klassikmann]

Hallo chris86 + twilight,

die Stellen hier aus Log6 direkt nach dem Schnitt :

Code: Alles auswählen

File system object FF4121 is linked as: /DataFiles/Tierärztin Dr. Mertens (25).rec
cannot repair the data format error(s) in this file.
cannot repair FF4121.

sowie aus und Log7 (fsck -n) und Log8 (fsck -p) nach dem Reboot:

Code: Alles auswählen

File system object FF4121 is linked as: /DataFiles/Tierärztin Dr. Mertens (25).rec
cannot repair the data format error(s) in this file.
cannot repair FF4121.  [b]Will release.[/b]

waren auch für mich die entscheidenden.

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

Gruß
Herbert