RecStripper - TAP zum Schrumpfen der Aufnahmen

[Twilight]

das ist auch korrekt ich werd ihm nächste woche wieder ein kaffeetscherl spendieren

twilight

[FireBird]

Seit's bald fertig mit dem Schleimen?

[Töppi]

Kannst gerne mehr haben.....

[Twilight]

Seit's bald fertig mit dem Schleimen?

als hätt ich das nötig...hab ich doch nicht, oder ?!

twilight

[macfan]

Leider muss ich die gute Stimmung etwas verschlechtern. Ich hatte die letzten Tage keine Zeit, erst jetzt habe ich den ersten Test durchgeführt. "Mein" Fehler ist immer noch da. Wenn ich das Log richtig verstehe, liegt das an einem Fehler in der TS-Datei, aber der ist sehr wahrscheinlich durch die Anwendung deines anderen TAPs hereingekommen.

Gruß, Horst

[postler1972]

Seit's bald fertig mit dem Schleimen?

Das ist kein Schleimen, sondern eine sehr hohe Wertschätzung und Anerkennung für deine Arbeit

[Twilight]

minibug: befindet sich ein unterverzeichnis in recstrip dann wird dies als file mitgezählt.

aufgefallen ist mir dies da ich 2 files und ein leeren unterverzeichnis in recstrip habe und es beim start 3 files strippen anzeigt...

twilight

[Twilight]

mit zwei receivern heute 12 files gestrippt und alles bestens.
logs habe ich aufgrund der größe gezippt und per mail geschickt.


twiligth

[chris86]

Leider muss ich die gute Stimmung etwas verschlechtern. Ich hatte die letzten Tage keine Zeit, erst jetzt habe ich den ersten Test durchgeführt. "Mein" Fehler ist immer noch da. Wenn ich das Log richtig verstehe, liegt das an einem Fehler in der TS-Datei, aber der ist sehr wahrscheinlich durch die Anwendung deines anderen TAPs hereingekommen.

Ich sehe (noch immer) kein Problem hier...
Wie ich aus dem Logfile erschließe, hast du offenbar eine vermurkste* REC-Datei verwendet, was (erwartungsgemäß) mit einer entsprechenden Meldung quittiert wurde.

Zur näheren Beurteilung bräuchte ich eine detaillierte Beschreibung, was genau hier passiert ist.

Das, was hätte passieren sollen:
- Die Fortschrittsanzeige sollte fast vollständig durchlaufen, und dann das TAP mit der Fehlermeldung "0/1 Dateien erfolgreich (Error-Code 5)" beendet werden. Hierbei sollte es keinerlei Hänger / Freezes oder Abstürze geben.
- Die rec-Datei sollte danach bis zu der problematischen Stelle korrekt verarbeitet worden sein (da das Problem nur die letzten 2048 Bytes betrifft, sollte die Aufnahme bis zum Ende komplett fehlerfrei abspielbar sein).
- Die nav-Datei sollte vollständig erzeugt worden sein. (Dateigröße ist mit der Original-nav aufs Byte identisch, und die rec-Datei ist absolut flüssig vorwärts- und rückwärts spulbar).
- Die inf- und cut-Dateien wurden möglicherweise nicht erzeugt. Es kann aber einfach die Original-inf in den Ordner mit der gestrippten Aufnahme kopiert werden - dann müsste sich die Aufnahme komplett einwandfrei spielen und spulen lassen.

Kannst du bitte nachprüfen, ob die genannten Punkte allesamt exakt so wie beschrieben zutreffen?
Beziehungsweise den Verlauf dieses Fehlers auf deinem Topf detailliert beschreiben?

Falls es dir möglich ist, wäre zur weiteren Diagnose möglicherweise hilfreich:
- das letzte Stück (die letzten 10 MB) der genannten rec-Datei.
- das Logfile von MovieCutter (wenn die Aufnahme geschnitten wurde, und wenn das das "andere" TAP ist, das möglicherweise den TS-Fehler angeblich "eingebaut" haben sollte)

Apropos: Ist da eine Festplatte mit Advanced Format eingebaut?

[macfan]

Wie ich aus dem Logfile erschließe, hast du offenbar eine vermurkste* REC-Datei verwendet, was (erwartungsgemäß) mit einer entsprechenden Meldung quittiert wurde.

Die Frage ist, warum sind ausgerechnet meine Dateien "vermurkst"? Denn beim letzten Test mit zwei Dateien trat der Fehler bei beiden Dateien auf.

Kannst du bitte nachprüfen, ob die genannten Punkte allesamt exakt so wie beschrieben zutreffen?
Beziehungsweise den Verlauf dieses Fehlers auf deinem Topf detailliert beschreiben?

Wird gemacht.

- das letzte Stück (die letzten 10 MB) der genannten rec-Datei.

Wie komme ich daran? Ich meine, als ich das letzte Mal mit MovieCutter ein Stück einer Aufnahme kopieren wollte, hat MovieCutter das trotzdem zusätzlich weggeschnitten und ich möchte die Aufnahme ja als Testbeispiel erhalten. Wie lang sind die 10 MB etwa als Zeit?

das Logfile von MovieCutter (wenn die Aufnahme geschnitten wurde, und wenn das das "andere" TAP ist, das möglicherweise den TS-Fehler angeblich "eingebaut" haben sollte)

Ich behaupte nicht, dass MovieCutter Schuld ist, aber ein gemeinsamer Faktor für meine Testdateien ist, dass sie mit MovieCutter geschnitten sind.

Apropos: Ist da eine Festplatte mit Advanced Format eingebaut?

Wie kann ich das feststellen?

Gruß, Horst

[macfan]

Die Fortschrittsanzeige sollte fast vollständig durchlaufen, und dann das TAP mit der Fehlermeldung "0/1 Dateien erfolgreich (Error-Code 5)" beendet werden. Hierbei sollte es keinerlei Hänger / Freezes oder Abstürze geben.

Ja

Die rec-Datei sollte danach bis zu der problematischen Stelle korrekt verarbeitet worden sein (da das Problem nur die letzten 2048 Bytes betrifft, sollte die Aufnahme bis zum Ende komplett fehlerfrei abspielbar sein)

Ja

Die nav-Datei sollte vollständig erzeugt worden sein. (Dateigröße ist mit der Original-nav aufs Byte identisch, und die rec-Datei ist absolut flüssig vorwärts- und rückwärts spulbar).

Nein, die erzeugte nav ist kürzer. Ohne inf kann man mW eh nicht spulen.

Die inf- und cut-Dateien wurden möglicherweise nicht erzeugt. Es kann aber einfach die Original-inf in den Ordner mit der gestrippten Aufnahme kopiert werden - dann müsste sich die Aufnahme komplett einwandfrei spielen und spulen lassen.

Die inf wird nicht erzeugt. Zum Spulen mit der originalen inf kann ich nichts sagen, weil ich die inf mit dem FTP-Programm hin und her kopiert habe. Jetzt ist sie leer und auch das Original kann nicht gespult werden. Ich meine, dass es vorher möglich war. Es kann natürlich auch die inf schon vorher defekt gewesen sein, da bin ich jetzt nicht 100%ig sicher. Daher werde ich mir morgen die zweite Testdatei vornehmen.

Gruß, Horst

[macfan]

So, nun habe ich das nächste Beispiel doch noch heute geschafft.

Die Fortschrittsanzeige sollte fast vollständig durchlaufen, und dann das TAP mit der Fehlermeldung "0/1 Dateien erfolgreich (Error-Code 5)" beendet werden. Hierbei sollte es keinerlei Hänger / Freezes oder Abstürze geben.

Ja

Die rec-Datei sollte danach bis zu der problematischen Stelle korrekt verarbeitet worden sein (da das Problem nur die letzten 2048 Bytes betrifft, sollte die Aufnahme bis zum Ende komplett fehlerfrei abspielbar sein)

Ja

Die nav-Datei sollte vollständig erzeugt worden sein. (Dateigröße ist mit der Original-nav aufs Byte identisch, und die rec-Datei ist absolut flüssig vorwärts- und rückwärts spulbar).

Nein, die erzeugte nav ist kürzer.

Die inf- und cut-Dateien wurden möglicherweise nicht erzeugt. Es kann aber einfach die Original-inf in den Ordner mit der gestrippten Aufnahme kopiert werden - dann müsste sich die Aufnahme komplett einwandfrei spielen und spulen lassen.

Die inf wird nicht erzeugt. Nach dem Hinzufügen der originalen inf kann man in der Tat problemlos spulen.

Logs hängen an.

Gruß, Horst

[Twilight]

so, jetzt wo das ding läuft fange ich mal an ein bischen laut nachzudenken

ich wünsche mir:

• ein RS flag wie wir es für RebuildNav in der inf haben um anderen taps die möglichkeit zu geben zu sehen ob das file gestrippt ist oder nicht. (das flag darf erst gesetzt werden wenn alles fertig ist)
• die freie konfiguration der beiden arbeitsverzeichnisse
• ein "done" verzeichnis wo die alten files hin verschoben werden wenn das automatische löschen nicht aktiv ist
• das RecStripper den verzeichnisbaum den es im source verzeichnis vorfindet auch in destination verzeichnis nachbildet und die files genau dort ablegt wo sie in source waren
• das RecStripper im hintergrund arbeitet und files die nicht fertig gestellt wurden wieder fortsetzen kann
• eine option die beim strippen den vor und nachlauf weg lässt wenn entsprechende bookmarks gesetzt sind (die idee kommt nicht von mir :twisted
• eventuell ein zeitfenster in dem RecStripper arbeiten darf

ich bin mir sicher das chris schon über vieles davon nachgedacht hat und das eine oder andere auch schon am radar hat...wollte einfach mal so meine gedanken zu dem tollen tap los werden

ach ja...für die exe: auch hier wäre eine ini die den arbeitsbereich vorgibt toll damit man mehrere datein automatisch verarbeiten kann sehr hilfreich

twilight

[chris86]

@macfan: Danke für die Info!

Nein, die erzeugte nav ist kürzer.

Hmm, das ist eher schlecht. Um wieviel denn? Genau 64 Byte oder mehr?

Wie komme ich daran? Ich meine, als ich das letzte Mal mit ein Stück einer Aufnahme kopieren wollte, hat das trotzdem zusätzlich weggeschnitten...

Die einfachste Möglichkeit wäre, das hier auf der Telnet-Konsole (direkt auf dem Topf) einzugeben. Das kopiert die letzten 10 MB in eine neue Datei namens Last10MB.rec:

Code: Alles auswählen

cd /mnt/hd/DataFiles
tail --bytes=10m -q "[Name der Aufnahme].rec" > Last10MB.rec

Ich behaupte nicht, dass MC Schuld ist, aber ein gemeinsamer Faktor für meine Testdateien ist, dass sie mit MC geschnitten sind.

Das wäre ja auch durchaus eine Möglichkeit. Daher ja auch die Frage: Hast du das Schnittlog der betroffen(en) Datei(en) noch?

Wie kann ich das feststellen?

Hast du die Festplatte mal gewechselt? Die Originalen Seagate-Platten haben kein AF, bei einer selbst eingebauten würde die Modellnr. Aufschluss geben.


Meine Vermutung ist hier:
Ich habe im Zusammenhang mit MovieCutter bei Geräten mit AF-Festplatte hin und wieder Aufnahmen gesehen, die am Ende plötzlich um 1024, 2048 oder 4096 Bytes zu lang waren. Dieser Teil enthielt oft Nullen oder Unsinn.
Sollte dieses Phänomen hier zutreffen (was genau geklärt werden muss), könnte ich RecStrip "überreden", in diesem Spezialfall das Strippen trotzdem erfolgreich zu beenden, und die inf zu erzeugen.
Ändert aber nichts daran, dass noch geklärt werden muss, warum die nav hier nicht passt...

[chris86]

ich wünsche mir:

Schöne Ideen! Wenn ich unendlich viel Zeit hätte, würde ich mit Sicherheit die meisten davon umsetzen...
Da dies aber leider nicht der Fall ist, müssen wir mal schauen, ob und wann etwas davon kommt...

ein RS flag wie wir es für RebuildNav in der inf haben um anderen taps die möglichkeit zu geben zu sehen ob das file gestrippt ist oder nicht. (das flag darf erst gesetzt werden wenn alles fertig ist)

Das wäre im Prinzip kein Problem. Gib mal Details, wie das bei RbN realisiert ist, bzw. wo genau in der inf was genau gespeichert wird... (und warum?)

das RecStripper im hintergrund arbeitet und files die nicht fertig gestellt wurden wieder fortsetzen kann

Ersteres ist geplant. Ein Fortsetzen einer angefangenen Datei dürfte kaum (nur schwer) möglich sein - in dem Fall würde diese einfach wieder von vorne angefangen...

ein "done" verzeichnis wo die alten files hin verschoben werden wenn das automatische löschen nicht aktiv ist

Auch das ist sinnvoll und geplant.

die freie konfiguration der beiden arbeitsverzeichnisse

Ginge mit der aktuellen Implementierung aber nur für Unterverzeichnisse von /DataFiles, da die Topfield-File-API nur darauf Zugriff gewährt...

das RecStripper den verzeichnisbaum den es im source verzeichnis vorfindet auch in destination verzeichnis nachbildet und die files genau dort ablegt wo sie in source waren

eventuell ein zeitfenster in dem RecStripper arbeiten darf

Das wären komplizierte Punkte, mit denen ich mich aktuell nicht näher beschäftigen kann/will. Evtl. ist entsprechender Code aber bereits in anderen TAPs vorhanden, den man "übernehmen" dürfte?

eine option die beim strippen den vor und nachlauf weg lässt wenn entsprechende bookmarks gesetzt sind (die idee kommt nicht von mir :twisted

Das mach ich nicht. Dafür gibts MovieCutter.

ach ja...für die exe: auch hier wäre eine ini die den arbeitsbereich vorgibt toll damit man mehrere datein automatisch verarbeiten kann sehr hilfreich

Nö. Das kann mit nem einfachen Batch-File viel besser gelöst werden...

[Twilight]

Das wäre im Prinzip kein Problem. Gib mal Details, wie das bei RbN realisiert ist, bzw. wo genau in der inf was genau gespeichert wird... (und warum?)

das haben wir, soweit ich weiß, an der inf hinten dran gehängt...oder hat firebird wo einen bereich gefunden der nicht genutzt wurde
eine mögliche anwendung wäre zb. in einer zusammenarbeit mit BackgroundCopy:

BackgroundCopy kann dann erkennen ob es ein gestripptes file ist oder nicht und auch ob es schon fertig ist. man kann dann im setup einstellen ob man nur files mit diesem flag kopiert. aktuell zb. werden nur unverschlüsselte files kopiert.

Ginge mit der aktuellen Implementierung aber nur für Unterverzeichnisse von /DataFiles, da die Topfield-File-API nur darauf Zugriff gewährt...

das ist kein problem, hintergrund wäre wieder eine zusammenarbeit mit BackgroundCopy: wenn das dest. verzeichnis das move verzeichnis von BackgroundCopy ist

Das wären komplizierte Punkte, mit denen ich mich aktuell nicht näher beschäftigen kann/will. Evtl. ist entsprechender Code aber bereits in anderen TAPs vorhanden, den man "übernehmen" dürfte?

dazu müsste firebird was sagen...im kopierteil von BackgroundCopy ist das drin. hintergrund aus meiner sich ist natürlich wieder die zusammenarbeit mit BackgroundCopy.

Das mach ich nicht. Dafür gibts MovieCutter.

ja eh

Nö. Das kann mit nem einfachen Batch-File viel besser gelöst werden...

kannst du ein solches zur verfügung stellen? mit entsprechenden filenamen wäre mir das auch klar, aber wie würde eines aussehen das allgemein gültig für bestimmte verzeichnisse ist und alles was darin enthalten ist bearbeitet?

twilight

[macfan]

Hmm, das ist eher schlecht. Um wieviel denn? Genau 64 Byte oder mehr?

In der Tat genau 64 Byte.

Die einfachste Möglichkeit wäre, das hier auf der Telnet-Konsole (direkt auf dem Topf) einzugeben. Das kopiert die letzten 10 MB in eine neue Datei namens Last10MB.rec:

Code: Alles auswählen

cd /mnt/hd/DataFiles
tail --bytes=10m -q "[Name der Aufnahme].rec" > Last10MB.rec

tail: unrecognized option `--bytes=10m'
...
Options:
-c N[kbm] Output the last N bytes

Dann muss ich wohl statt -bytes -c nehmen. Aber was ist mit [kbm] gemeint?

Das wäre ja auch durchaus eine Möglichkeit. Daher ja auch die Frage: Hast du das Schnittlog der betroffen(en) Datei(en) noch?

Schicke ich dir mit den 10 MB.

Hast du die Festplatte mal gewechselt? Die Originalen Seagate-Platten haben kein AF, bei einer selbst eingebauten würde die Modellnr. Aufschluss geben.

Ich habe eine WD 2TB eingebaut, das genaue Modell weiß ich nicht mehr.

Zu deiner Anmerkung in deiner Diskussion mit Twi bez. Batch:

In TMSArchive und SmartFiler kann man mit der roten Taste mehrere Dateien auswählen und dann Jobfiles für BackgroundCopy erstellen. Das könnte mit RS ja ähnlich laufen.

Gruß, Horst

[chris86]

Code: Alles auswählen

tail -c 10m 'Input'.rec Output.rec

[FireBird]

eine option die beim strippen den vor und nachlauf weg lässt wenn entsprechende bookmarks gesetzt sind (die idee kommt nicht von mir :twisted

Das mach ich nicht. Dafür gibts MovieCutter.

Falsche Antwort.

[tai74]

Erstmal Gratulation und vielen Dank für dieses tolle TAP. Bin auch schon zum Stripper geworden [emoji6]

Die Sache mit den .inf Dateien macht es allerdings etwas kompliziert. Diese bleiben nach dem Schrumpfen im Quell-Ordner RecStrip.
Ich verschiebe dann die geschrumpften RECs und NAVs zurück an ihren ursprünglichen Platz. Die INFs aus dem Quell-Ordner muss ich mir leider immer per ftp dazu holen. Danach lösche ich die original RECs und NAVs.

Könnte es mit relativ wenig Aufwand realisiert werden, die INFs als Abschluss des Schrumpf Vorgangs automatisch von RecStrip nach RecStripOut zu verschieben. Dann könnte man seine kleinen neuen Film Dateien (nun wieder komplett) am Topf zurück schieben, ohne PC. Dann kann das Ding auch mein Vater benutzen [emoji6]
Das wär fein.

Liebe Grüße,
tai74!