RecStripper - TAP zum Schrumpfen der Aufnahmen

[chris86]

Kannst es gleich nochmal ändern!
Ist nämlich schon längst in der 0.5 korrigiert

(Wer das Update VOR dem 20.02. heruntergeladen hat, muss dies vllt. nochmal wiederholen, damit das korrekte Flag gesetzt wird...)

[FireBird]

Den Leuten heimlich Änderungen unterschieben. Jetzt muss ich aber ganz dringend

[Twilight]

wenn ich mich mal auf alex verlasse

twilight

[Wolfman]

[chris86]

Wenn wir schon beim Thema Änderungen sind...
Ich würde mir ja eigentlich eine RecStripper-Bedienung über ein Filer-TAP (z.B. SmartFiler) wünschen.

Dazu würden mir mehrere Varianten einfallen:
(a) SmartFiler bietet per Tastendruck die Möglichkeit, zu einer gewählten Aufnahme das rs_ToBeStripped-Flag (zurück)zusetzen.
(b) SF verwaltet eine Art Queue, in die zu strippende Aufnahmen eingefügt werden können, und die dann irgendwie (TAPCOM?) an RecStripper weitergegeben wird
(c) SF verwaltet eine Queue und kümmert sich selbst um den RecStrip-Aufruf. Den entsprechenden Code (mit StateMachine ) könnte ich als Modul bereitstellen, so dass er mit minimalem Aufwand integriert werden könnte.

Am einfachsten und flexibelsten wäre wohl Variante (a). Dann könnten auch andere Filer dieselbe Funktionalität anbieten. Denkt ihr, das wäre möglich?

[FireBird]

(d) SF macht etwas, das es schon für BackgroundCopy macht: es erstellt für jede zu strippende Datei ein JobFile (eine INI mit den File-Daten), die dann von RecStripper abgearbeitet wird, bis das Job-Directory leer ist. Ob SF RecStripper sofort startet, oder später, kann man noch überlegen. Dabei kann SF natürlich (a) mit übernehmen.

[ameise999]

(d) SF macht etwas, das es schon für BackgroundCopy macht: es erstellt für jede zu strippende Datei ein JobFile (eine INI mit den File-Daten), die dann von RecStripper abgearbeitet wird, bis das Job-Directory leer ist. Ob SF RecStripper sofort startet, oder später, kann man noch überlegen. Dabei kann SF natürlich (a) mit übernehmen.

gruss

[macfan]

(d) SF macht etwas, das es schon für BackgroundCopy macht: es erstellt für jede zu strippende Datei ein JobFile (eine INI mit den File-Daten), die dann von RecStripper abgearbeitet wird, bis das Job-Directory leer ist. Ob SF RecStripper sofort startet, oder später, kann man noch überlegen. Dabei kann SF natürlich (a) mit übernehmen.

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 RecStripper ja ähnlich laufen.

Gruß, Horst

[macfan]

(Wer das Update VOR dem 20.02. heruntergeladen hat, muss dies vllt. nochmal wiederholen, damit das korrekte Flag gesetzt wird...)

Ich hatte leider die Version vom 17.02., so dass ich es nicht sehen kann. Daher die Nachfrage: Handelt es sich um das von dir unten genannte rs_ToBeStripped-Flag, dass man mE (Jobfiles) nicht benötig oder um ein rs_IsStripped-Flag? Letzteres ist nämlich mE extrem wichtig, damit man den Überblick behält, was noch gestrippt werden muss und was nicht.

(a) SmartFiler bietet per Tastendruck die Möglichkeit, zu einer gewählten Aufnahme das rs_ToBeStripped-Flag (zurück)zusetzen.
(b) SF verwaltet eine Art Queue, in die zu strippende Aufnahmen eingefügt werden können, und die dann irgendwie (TAPCOM?) an RecStripper weitergegeben wird
(c) SF verwaltet eine Queue und kümmert sich selbst um den RecStrip-Aufruf. Den entsprechenden Code (mit StateMachine ) könnte ich als Modul bereitstellen, so dass er mit minimalem Aufwand integriert werden könnte.

Am einfachsten und flexibelsten wäre wohl Variante (a). Dann könnten auch andere Filer dieselbe Funktionalität anbieten. Denkt ihr, das wäre möglich?

Der Autor von TMSArchive macht garantiert mit, wenn du ihn informierst, auch bei einem rs_IsStripped-Flag, denke ich. Bei deiner Frage plädiere ich nach wie vor für meinen Vorschlag, Jobfiles wie bei BackgroundCopy zu verwenden.

Gruß, Horst

[macfan]

[quote="chris86"]Wäre es möglich, dass du mir von dieser Aufnahme noch die letzten ca. 120 MB hochladen könntest?[/quote]
Ist passiert.

Gruß, Horst

[chris86]

Ich hatte leider die Version vom 17.02., so dass ich es nicht sehen kann. Daher die Nachfrage: Handelt es sich um das von dir unten genannte rs_ToBeStripped-Flag, dass man mE (Jobfiles) nicht benötig oder um ein rs_IsStripped-Flag? Letzteres ist nämlich mE extrem wichtig, damit man den Überblick behält, was noch gestrippt werden muss und was nicht.

Es gibt 2 Flags, einmal für "ist gestrippt" und einmal für "soll gestrippt werden".
Bei der "alten" Version vom 17.02. wurde das "ist gestrippt" Flag an eine Stelle gesetzt, die bereits von IQTuner verwendet wird, und musste daher nochmal "umziehen".

Der Autor von TMSArchive macht garantiert mit, wenn du ihn informierst, auch bei einem rs_IsStripped-Flag, denke ich. Bei deiner Frage plädiere ich nach wie vor für meinen Vorschlag, Jobfiles wie bei BackgroundCopy zu verwenden.

Wenn dem so ist, dann spräche das gegen die Jobfiles.
Was wäre zum Beispiel, wenn jemand in SE eine Datei fürs Strippen vormerkt, sich dann doch dagegen entscheidet, und die Vormerkung in TMSA wieder entfernt.
Bei der "Flag"-Lösung würde die Vormerkung dann einfach wieder aus der inf entfernt werden, und schon würde auch SE automatisch "sehen", dass diese Datei nicht mehr gestrippt werden soll.

[Twilight]

SE sicht gar nix, wenn dann SF

twilight

[macfan]

Wenn dem so ist, dann spräche das gegen die Jobfiles.

Finde ich nicht.

Was wäre zum Beispiel, wenn jemand in SE eine Datei fürs Strippen vormerkt, sich dann doch dagegen entscheidet, und die Vormerkung in TMSA wieder entfernt.

Warum sollte jemand mit beiden Filern arbeiten? Und die Jobfiles von BackgroundCopy kann man auch höchstens per FTP aus den Settings löschen und noch hat sich niemand, weder von den TMSArchive- noch von den SmartFiler-Anwendern beschwert.

Ich glaube, dass du dir hier einen Kopf machst, wo es absolut nicht nötig ist.

Gruß, Horst

[Twilight]

in SmartFiler kannst du das auch...über die filesuche zb.

twilight

[chris86]

Wenn ich mir nicht einen Kopf gemacht hätte, wo das sonst keiner für nötig gehalten hätte, dann gäbe es RecStripper nicht

Ich stelle es mir so ungefähr vor:
Der User wählt eine Datei im Filer aus (bei der kein grünes "Ist schon gestrippt" Symbol steht), und drückt die entsprechende Taste welche das ToBeStripped-Flag umschaltet. Daraufhin erscheint eine kleine rote Uhr, die anzeigt, dass diese Datei gestrippt werden soll. Drückt der User dieselbe Taste nochmal, verschwindet die Uhr wieder, und die Datei wird eben nicht gestrippt. Im idealsten Fall gäbe es eines Tages noch ein gelbes Sanduhr-Icon für "Die Datei wird gerade gestrippt", was man dann nicht mehr entfernen kann (oder was dann zum Abbruch der Aktion führt), und evtl. noch eines für "Die Datei wurde versucht zu strippen, hat aber irgendwie nicht geklappt, also lösch sie bitte nicht einfach so"
Und dieses Verhalten eben identisch bei TMSA und SF und ggf. allen anderen Filer-TAPs.

Und sobald RecStripper gestartet wird (oder wenn es schon im Hintergrund läuft), dann findet es die markierten Aufnahmen, und macht sich im Hintergrund ans Strippen.

Aus meiner aktuellen Vorstellung heraus, halte ich das für ziemlich benutzerfreundlich. Wüsste jetzt nicht, was dagegen sprechen sollte... aber ich lass mich gerne belehren...

[Twilight]

Ich stelle es mir so ungefähr vor:
Der User wählt eine Datei im Filer aus (bei der kein grünes "Ist schon gestrippt" Symbol steht), und drückt die entsprechende Taste welche das ToBeStripped-Flag umschaltet.

das ist in der logik falsch, denn nur ein bereits gestripptes files hat dieses flag und soll auch als solches zu erkennen sein. ein file das noch nicht gestrippt wurde hat eben kein flag und damit kein icon dieses icon sollen nur die files haben die aus dem stipper raus kommen und fertig sind.

ich persönlich empfinde den weg via job file und/oder verzeichnis den einfacheren und via verzeichnis auch übersichtlicheren. letztendlich braucht man die source files ja nach dem strippen nicht mehr und sollten gelöscht werden wenn alles geklappt hat, oder eben in ein done verzeichnis mit einem - hinten dran damit AutoMove nicht die anderen files automatisch dorthin verschiebt.

man erstpart sich jedesmal die ganz platte zu durchsuchen das im normalfall viel resourcen verbraucht.

twilight

[Twilight]

noch eine geschichte die gegen den "flag" auftrag spricht:

es gibt keine möglichkeit für den user festzustellen welche files frei gegeben wurden und diese eventuell zurück zu setzen außen alle der reihe nach anzuwählen.
da job files+verzeichnislösung ja schon bgc verwendet werden könnte ich mir vorstellen eine sicht zu schaffen wo alle anstehenden job files dargestellt werden und man sie auch wieder löschen kann...

twilight

[chris86]

... bei der kein grünes "Ist schon gestrippt" Symbol steht...

Hat da etwa jemand ein kleines 'k' überlesen?

es gibt keine möglichkeit für den user festzustellen welche files frei gegeben wurden und diese eventuell zurück zu setzen außen alle der reihe nach anzuwählen.

Doch, wenn das Icon immer neben dem Dateinamen angezeigt wird, kann man das auf einen Blick sehen.

man erstpart sich jedesmal die ganz platte zu durchsuchen das im normalfall viel resourcen verbraucht.

Das ist ein Argument!
Von welchem Zeitraum reden wir hier? Ich hätte jetzt geschätzt, das dauert max. 30 sek. Im Vergleich mit dem Zeit- (und Ressourcen-)Aufwand, der fürs Strippen selbst erforderlich ist, wäre das verschwindend. Aber ich habs nicht ausprobiert...

[Twilight]

Hat da etwa jemand ein kleines 'k' überlesen?

treffer verenkt ops:

Doch, wenn das Icon immer neben dem Dateinamen angezeigt wird, kann man das auf einen Blick sehen.

nun, das kommt erstens auf die gestaltung der sicht an (15er in SmartFiler werden diese symbole nur angezeigt wenn man diese markiert) und zweitens sind dann noch unterverzeichnisse.

Das ist ein Argument!

wenigstens eines

Von welchem Zeitraum reden wir hier? Ich hätte jetzt geschätzt, das dauert max. 30 sek. Im Vergleich mit dem Zeit- (und Ressourcen-)Aufwand, der fürs Strippen selbst erforderlich ist, wäre das verschwindend. Aber ich habs nicht ausprobiert...

kann ich dir nicht sagen, jedenfalls blockieren diese aktionen den SRP ...je nachdem wie intensiv und wie weit man es betreibt.
wie sehr das strippen den SRP ausbremst weiß ich ja bis jetzt nicht da ein bedienen wärend dessen ja noch nicht möglich ist.

twilight

[HD_Topfgucker]

Hat da etwa jemand ein kleines 'k' überlesen?

treffer verenkt ops:


nun, das kommt erstens auf die gestaltung der sicht an (15er in SmartFiler werden diese symbole nur angezeigt wenn man diese markiert) und zweitens sind dann noch unterverzeichnisse.


wenigstens eines

kann ich dir nicht sagen, jedenfalls blockieren diese aktionen den SRP ...je nachdem wie intensiv und wie weit man es betreibt.
wie sehr das strippen den SRP ausbremst weiß ich ja bis jetzt nicht da ein bedienen wärend dessen ja noch nicht möglich ist.

twilight

Über Webcontrol lassen sich die Sender umschalten und auch Files abspielen

Grüße HD_Topfgucker