MovieCutter

[chris86]

Oh, eins noch! Was genau meinst du damit:

Der Schnitt war dann schon verzögert

Kannst du das etwas näher erläutern?

Laut Log hat es vom Auslösen der Schnittoperation bis zu ihrer vollständigen Beendigung <= 2 Sekunden gedauert. An welcher Stelle genau trat denn da eine Verzögerung auf?
Oder meinst du damit, dass nicht exakt an der gewünschten Schnittstelle geschnitten wurde?

Code: Alles auswählen

2014-02-03 [b]21:29:42[/b] [Action 'Delete segments' started...]
...
2014-02-03 21:29:43 Size of the new playback file (after cut): 284454912
2014-02-03 [b]21:29:44[/b] Reported new totalBlock = 31417

[db1]

Das war kurz vor dem reboot und ich meinte, dass ich den reboot schon erahnen konnte. Wenn MC richtig schneidet geht es ja recht flott Schritt für Schritt weiter.
Im geschilderten Fall ist dann bei einem Schritt längere Zeit die aktuelle MC-Anzeige "eingefroren" und dann tschüss. Ich glaube mich zu erinnern, dass der zu dem Zeitpunkt zu schneidene Teil noch im Menü sichtbar war, also zumindest Menümäßig das TAP noch nicht fertig war. Der Schnitt war aber wohl fertig, da ja nach dem Neustart alles o.k. war.

[super-mentor]

Hilfe !!!
Seit 13.1.2014 schneide ich mit MovieCutter meine Aufnahmen, bevor ich sie in eigene Ordner auf der internen oder 2 externen HD's speichere. Das hat bisher fehlerfrei funktioniert.

Gestern habe ich eine Datei "beschnitten". Erfolgreich, keine Fehlermeldung, kein Absturz. Kopiert auf eine externe HD (NTFS, 1TB) wie bisher. Fehlerfrei, keine Meldung.

Beim nächsten Aufruf der Liste Aufgenommene Sendung fehlen mir von ca. 125 Serien über 49 Aufnahmen aus meinem Ordner "Serien". Die *.NAV und *.INFO-Dateien sind alle vorhanden, die 49 *.rec-Dateien sind spurlos verschwunden. Sie werden auch per ftp-Zugriff mit FileZilla nicht angezeigt, ebensowenig im internen Netz.

Was kann ich tun, um diese Serien möglichst zu retten? Als Anhang poste ich die Log-Datei von MC vom 7.2.2014. Davor war alles bestens.

Danke für jede Hilfe.

[FireBird]

Abgesehen davon dass das Log von heute ist, ist so wunderbar gekürzt, dass nicht einmal eine Versionsnummer zu finden ist.

[Woodman]

...Was kann ich tun, um diese Serien möglichst zu retten? Als Anhang poste ich die Log-Datei von MC vom 7.2.2014. Davor war alles bestens.

Danke für jede Hilfe.

Bei mir hat schon öfter der UFS Explorer geholfen.
Ist ein Windows-Tool, kann aber auch (fast) alle anderen Dateisystem (inkl. EXT[234] und JFS) lesen. Kostet ein paar Euronen, ist aber den Preis allemal wert.

[chris86]

Abgesehen davon dass das Log von heute ist, ist so wunderbar gekürzt, dass nicht einmal eine Versionsnummer zu finden ist.

Oder er verwendet eine so alte Version, dass sie noch gar keine Versionsnr. anzeigt

Hilfe !!!
Seit 13.1.2014 schneide ich mit MovieCutter meine Aufnahmen, bevor ich sie in eigene Ordner auf der internen oder 2 externen HD's speichere. Das hat bisher fehlerfrei funktioniert.

Zunächst ein paar Fragen:

• Welche Version des MovieCutters verwendest du?
• Sind nur Aufnahmen von der internen oder auch von einer externen HDD verschwunden?
• War das Verschwinden der Aufnahmen mit einer Festplatten-Prüfung beim Starten des Receivers verbunden?
• Ist das die erste Festplatten-Prüfung gewesen, die du seit dem 13.01.2014 hattest?
  (oder ist vorher schon einmal ein HDD-Check aufgetreten, den die jetzt gelöschten Aufnahmen überlebt haben) - [wichtige Frage!!!]
• Hast du beim Schneiden TimeShift aktiviert?

Bitte versuche alle diese Fragen so präzise wie möglich zu beantworten, damit wir die Ursache des Problems klären können!

Gestern habe ich eine Datei "beschnitten". Erfolgreich, keine Fehlermeldung, kein Absturz. Kopiert auf eine externe HD (NTFS, 1TB) wie bisher. Fehlerfrei, keine Meldung.
Beim nächsten Aufruf der Liste Aufgenommene Sendung fehlen mir von ca. 125 Serien über 49 Aufnahmen aus meinem Ordner "Serien".

Was genau bedeutet das? Lag zwischen dem "nächsten Aufruf" ein Neustart (ggf. mit Festplattenüberprüfung), oder passierte das einfach so? Falls zweiteres: Bist du sicher, dass die Dateien direkt zuvor noch da waren?

Davor war alles bestens.

Das weißt du leider nicht! Die Wahrscheinlichkeit ist hoch, dass es schon vor diesem letzten Schnitt ein Problem am Dateisystem gab, was jetzt erst zu Tage getreten ist. (Deshalb auch die vielen Fragen bezüglich Festplattenprüfung.)

Was kann ich tun, um diese Serien möglichst zu retten?

So traurig es ist, und so Leid es mir tut: Es ist (mir zumindest) bislang kein sicherer Weg bekannt, wie man derart verlorene Aufnahmen zurückbekommen kann. Es kann dir also leider niemand irgendeinen Erfolg versprechen.
ABER:
Da die Dateien bis vor Kurzem noch vorhanden waren, stehen die Chancen gut, dass sie noch nicht überschrieben, und somit noch zu retten sind.
Folgendes solltest du als erstes tun:

1. Unterlasse alles, was irgendwie schreibend auf die Festplatte zugreift! Das beinhaltet insbesondere Aufnahmen. Aber auch Timeshift (falls aktiviert) solltest du schleunigst abschalten, ebenso wie diverse EPG-TAPs, die ihre Daten auf der Festplatte ablegen. (noch besser: schalte den Receiver aus, und nicht mehr ein, bis das Problem geklärt ist)
2. Ausbauen der Festplatte aus dem Receiver und Anhängen an einen PC (das geht mittels USB-Gehäuse oder direkt an einen SATA-Port im PC.
3. Falls Windows dich fragt, ob du die Festplatte initialisieren, formatieren, defragmentieren oder weißdergeierwasnoch willst, unbedingt mit NEIN antworten! (sonst sind ALLE deine Aufnahmen für immer verloren)
4. Das Dateisystem, das Topfield verwendet, ist JFS. Du benötigst jetzt also ein Programm, das JFS-Festplatten lesen, und am besten auch noch Daten retten kann. Es wurde bereits der UFS-Explorer empfohlen. Probiers mal damit.
5. Mit etwas Glück verwaltet JFS mehrere Kopien der Dateizuordnungstabelle. Dann kann UFS-Explorer vermutlich eine alte Kopie verwenden, und deine Daten damit wiederherstellen.
6. Achtung: Das Wiederherstellen der verschwundenen Dateien sollte niemals direkt auf der Topfield-Platte geschehen! Kopiere die Dateien stattdessen auf eine andere HDD. Von dort aus, kannst du sie (wenn ALLE deine Files gerettet sind) wieder auf die Receiver-HDD zurückkopieren.

Ich wünsche dir ganz viel Erfolg!!!

Bei mir hat schon öfter der UFS Explorer geholfen.
Ist ein Windows-Tool, kann aber auch (fast) alle anderen Dateisystem (inkl. EXT[234] und JFS) lesen. Kostet ein paar Euronen, ist aber den Preis allemal wert.

Hast du das bereits bei diesem speziellen Problem ("Aufnahmenfresser" MC-geschnittener *.recs) erfolgreich angewendet?
Wenn ja, dann erzähle uns doch bitte mehr von deinen Erfahrungen!
(Insbesondere wäre es äußerst interessant, ob UFS-Explorer etwas dazu sagen kann, warum die Dateien kaputt bzw. verschwunden sind!)

[TV-Junkie]

@chris86, könnte es sinn machen, den Topf mit gedrückter 0 zu starten? oder noch anders, wenn das Sinn , das keine anderen Taps laufen, wäre es dann nicht gut, wenn MC laufende Taps, ausser vielleicht TimerDiags stoppen könnte, und nach beenden von MC wieder zu starten zu lassen oder den Topf neu zu booten

[chris86]

So, und jetzt die Ankündigung, wegen der ich eigentlich gerade ins Forum gekommen bin...

MovieCutter 2.0h ist jetzt stabil und ausgiebig getestet!!!

Die neue Version steht seit heute in TAPtoDate und auf der Homepage zur Verfügung.

Wichtigste Änderungen (2.0h):

• noch weitere Maßnahmen gegen den berüchtigten Aufnahmenfresser
  - Behandlung des letzten Segments neu gestaltet
  - Synchronisation der internen Caches
  (-> zumindest erste Tests von klassikmann und db1 lassen hoffen, dass dieses vertrackte Problem damit endlich aus der Welt ist!)
• Maßnahmen gegen die Verstümmelung des Endes (auch ohne Reboot)
• und seit der letzten beta:
  Verschiedene zusätzliche Sicherheitsüberprüfungen, die ungültige Aktionen oder Zeichnen außerhalb der OSD-Grenzen verhindern.
  (thanks to Firebird! Das behebt auch den zuletzt von klassikmann und db1 gemeldeten Crash...)

Also haut rein, und testet was das Zeug hält! Insbesondere auf weitere Schnitte und Festplattenprüfungen von klassikmann und allen anderen, die bisher schonmal mit dem Kollegen Aufnahmenfresser Bekanntschaft schließen durften, bin ich gespannt... Aber natürlich auch auf alle anderen Rückmeldungen!

Ein schönes Wochenende allen


PS: Wer auf der Homepage schaut, der findet dort noch zwei weitere Varianten der neuen Version. Diese sind für speziellen Bedarf gedacht und bewirken folgendes:

• ohne Sync: Die Cache-Synchronisation ist noch experimentell (unter anderem deshalb, weil es zig verschiedene Festplatten-Typen gibt, die sich möglicherweise unterschiedlich verhalten, und weil nicht gesichert ist, wie lang Linux braucht, um die Änderungen wirklich auf die Platter zu schreiben.)
  Falls es bei irgendjemandem Probleme geben sollte, dann möge der/diejenige bitte auch einmal testen, ob die Probleme mit der Version ohne Sync ebenso bestehen.
• ohne Stopp: Wie sich herausgestellt hat, bereitet das (reguläre) Stoppen der Aufnahme in Kombination mit dem V!deotext-TAP Probleme. Wer unbedingt beide TAPs gemeinsam verwenden möchte, wird vielleicht mit dieser Version glücklich. (Es treten dabei aber u.U. Probleme beim Ausblenden des OSD auf.)

[chris86]

@chris86, könnte es sinn machen, den Topf mit gedrückter 0 zu starten? oder noch anders, wenn das Sinn , das keine anderen Taps laufen, wäre es dann nicht gut, wenn MC laufende Taps, ausser vielleicht TimerDiags stoppen könnte, und nach beenden von MC wieder zu starten zu lassen oder den Topf neu zu booten

Das ist nicht wirklich sinnvoll. MC verträgt sich - soweit bekannt - mit allen anderen TAPs einwandfrei (mit Ausnahme von V!deotext, das aber eh nur auf dem TMS2100 sinnvoll läuft) .
Im Falle von Problemen rate ich zwar oft dazu, den Topf einmal mit der '0' zu starten, um auszuschließen, dass das Problem von anderen TAPs herrührt. Das dient aber eher diagnostischen Zwecken...

Achja, und selbst die Kombination mit V!deotext bewirkt im schlimmsten Falle "nur", dass der Schnitt verweigert wird. Die Aufnahme wird in diesem Fall nicht beschädigt oder fehlerhaft geschnitten o.ä.

[Twilight]

super, danke, find es toll wie du am ball bleibst

twilight

[Woodman]

...Hast du das bereits bei diesem speziellen Problem ("Aufnahmenfresser" MC-geschnittener *.recs) erfolgreich angewendet?
Wenn ja, dann erzähle uns doch bitte mehr von deinen Erfahrungen!
(Insbesondere wäre es äußerst interessant, ob UFS-Explorer etwas dazu sagen kann, warum die Dateien kaputt bzw. verschwunden sind!)

Leider kann ich nichts zur MovieCutter-Problematik beitragen ops:
Ich konnte den UFS-Explorer bisher nur erfolgreich bei diesem Problem anwenden.

[TV-Junkie]

Das ist nicht wirklich sinnvoll. MC verträgt sich - soweit bekannt - mit allen anderen TAPs einwandfrei (mit Ausnahme von V!deotext, das aber eh nur auf dem TMS2100 sinnvoll läuft) .
Im Falle von Problemen rate ich zwar oft dazu, den Topf einmal mit der '0' zu starten, um auszuschließen, dass das Problem von anderen TAPs herrührt. Das dient aber eher diagnostischen Zwecken...

Achja, und selbst die Kombination mit V!deotext bewirkt im schlimmsten Falle "nur", dass der Schnitt verweigert wird. Die Aufnahme wird in diesem Fall nicht beschädigt oder fehlerhaft geschnitten o.ä.

OK

[chris86]

Leider kann ich nichts zur MovieCutter-Problematik beitragen ops:
Ich konnte den UFS-Explorer bisher nur erfolgreich bei diesem Problem anwenden.

Na, das Symptom erscheint mir aber exakt genauso, wie bei unserem Aufnahmenfresser!
(Und es war damals zumindest eine Datei dabei, die geschnitten war, allerdings wohl noch mit einer älteren MC-Version).
Kannst du bestätigten oder ausschließen, dass bei dem beschrieben Fall nur recs gelöscht wurden, die vorher irgendwann mit MC geschnitten worden sind?
Ansonsten veranstaltet ja vielleicht (noch) ein anderes TAP Murks im Dateisystem

[TV-Junkie]

Ansonsten veranstaltet ja vielleicht (noch) ein anderes TAP Murks im Dateisystem

Deshalb ja mein Vorschlag
Selbst nur mit topfmitteln schneide ich ohne Taps. weil das nie richtig ging (Tasten wurden abgefangen etc)

[klassikmann]

MovieCutter 2.0h ist jetzt stabil und ausgiebig getestet!!!

Die neue Version steht seit heute in TAPtoDate und auf der Homepage zur Verfügung.

Wichtigste Änderungen (2.0h):

• noch weitere Maßnahmen gegen den berüchtigten Aufnahmenfresser
  - Behandlung des letzten Segments neu gestaltet
  - Synchronisation der internen Caches
  (-> zumindest erste Tests von klassikmann und db1 lassen hoffen, dass dieses vertrackte Problem damit endlich aus der Welt ist!)
• Maßnahmen gegen die Verstümmelung des Endes (auch ohne Reboot)
• und seit der letzten beta:
  Verschiedene zusätzliche Sicherheitsüberprüfungen, die ungültige Aktionen oder Zeichnen außerhalb der OSD-Grenzen verhindern.
  (thanks to Firebird! Das behebt auch den zuletzt von klassikmann und db1 gemeldeten Crash...)

In der Tat ist auch der reproduzierbare Crash behoben.

Vielen Dank.

Vielleicht kann man noch irgend etwas tun (Doku, Warnung, ???) um das Szenario zu vermeiden, das zum Crash führte, was ich in Post #1076 dokumentiert habe. Der Crash ist behoben, aber es sollte vermieden werden, dass ungewollt ein "falsches" Segment gelöscht wird, "falsch" nach "besten Wissen" des Anwenders.

Gruß
Herbert

[Woodman]

...
Kannst du bestätigten oder ausschließen, dass bei dem beschrieben Fall nur recs gelöscht wurden, die vorher irgendwann mit MC geschnitten worden sind?
Ansonsten veranstaltet ja vielleicht (noch) ein anderes TAP Murks im Dateisystem

Dieser Fall war ohne Mitwirkung von MC. Es waren alle Datei-Typen betroffen. In meinem Fall war der verfügbare Rest-Plattenplatz (20-30GB) wohl die Ursache (siehe hier und hier).

[chris86]

Dieser Fall war ohne Mitwirkung von MC. Es waren alle Datei-Typen betroffen.

Sicher, alle Typen!? Im Log sind nur die .recs aufgeführt. Waren die .infs und .navs denn ebenfalls gelöscht?

Code: Alles auswählen

2012-12-20 07:53:39 TimerDiags: RECMON: 'Visite - 2012-08-07 20-15.rec' has been deleted (dev=2050, inode=4480)
2012-12-20 07:53:39 TimerDiags: RECMON: 'Die Reifepruefung - 2012-08-08 00-15.rec' has been deleted (dev=2050, inode=4399)
2012-12-20 07:53:39 TimerDiags: RECMON: 'Konrad Adenauer - 2012-07-31 19-30[b](Cut-1)[/b].rec' has been deleted (dev=2050, inode=413697)

Und zumindest die Adenauer-Datei war geschnitten. Kannst du mit Sicherheit sagen, dass bei den dort gelöschten 122 Aufnahmen eine dabei war, die niemals mit dem MC angefasst wurde?

[FireBird]

RecMon prüft nur die .rec. Wenn RbN läuft, würden verwaiste .infs und .navs angemeckert werden.

[chris86]

Vielleicht kann man noch irgend etwas tun (Doku, Warnung, ???) um das Szenario zu vermeiden, [...] was ich in Post #1076 dokumentiert habe.
[...] es sollte vermieden werden, dass ungewollt ein "falsches" Segment gelöscht wird, "falsch" nach "besten Wissen" des Anwenders.

Den Hinweis nehme ich gerne auf. Um nicht wieder allgemeine Verunsicherung auszuösen, weise ich aber nochmals darauf hin, dass es sich bei dem genannten Szenario nicht um eine Fehlfunktion des MC handelt, sondern um ein Missverständnis der Bedienung.
Um weiteren Missverständnissen dieser Art vorzubeugen, folgender Hinweis:

Wenn man im MC die Funktionen "Aktuelles Segment speichern" oder "Aktuelles Segment löschen" auswählt, dann beziehen sich diese stets auf das Segment, welches zu dem aktuellen Zeitpunkt gerade wiedergegeben wird. Sprich: Das Segment, in dem sich der Wiedergabe-Cursor befindet, dessen Bild und Ton ausgegeben werden, und das in Cyan einfärbt ist.
Wenn man vorher einen Segment-Sprung durchführt, dann muss man mit dem Starten des Schnitts solange warten, bis die Sprungoperation abgeschlossen ist, d.h. bis die Wiedergabe sich wirklich im gewünschten Segment befindet. (dauert bis zu 1 sek.)

(Ich werde in der nächsten Version mal versuchen, den Menü-Button solange zu sperren, bis der zuletzt beauftragte Sprung durchgeführt wurde.)

[chris86]

RecMon prüft nur die .rec. Wenn RbN läuft, würden verwaiste .infs und .navs angemeckert werden.

RbN lief aber nicht, und hat somit keine verwaisten Dateien gelöscht. Deshalb frage ich danach