Wann genau führt Automove die Umbenennung durch?

[MiK]

Hallo,

ich habe gerade herausgefunden, dass meine Probleme mit RecCopy daran lagen, dass ich bei Automove eine Verzögerung von 30 Sekunden eingestellt hatte. RecCopy hat dann seine mittlerweile umbenannten Dateien nicht mehr gefunden.

Ich habe nun Automove vor RecCopy und die Verzögerung auf 0 gestellt. Werden bei dieser Einstellungen alle Umbenennungen in der TAP_Main() durchgeführt, so dass beim Start des nächsten TAPs alles abgeschlossen ist?

[Wolfman]

Afaik gibt es doch bei Automove eine Einstellung, dass erst verschoben wird, wenn RecCopy gescannt hat.

[MiK]

Ja, das gilt aber nur für das Verschieben aber nicht für das Umbenennen (Anhängen des Datums).

[Wolfman]

Stimmt... bei meinem 5500er kamen sich beide nicht in die Quere, ich weiß aber gerade nicht, welche Verzögerung ich eingestellt hatte.

[Happy]

[quote="MiK"]
Ich habe nun Automove vor RecCopy und die Verzögerung auf 0 gestellt. Werden bei dieser Einstellungen alle Umbenennungen in der TAP_Main() durchgeführt, so dass beim Start des nächsten TAPs alles abgeschlossen ist?[/quote]
Nein, im TAP_Main wird praktisch nichts gemacht.
Das Umbenennen und Verschieben erfolgt erst anschließend über mehrere Idle-Events verteilt.
Das Umbenennen erfolgt jedoch als erstes.

Gruß,
Happy

[MiK]

Danke für die schnelle Auskunft.

Ich kann also nicht 100% sicher sein, dass die Dateien beim Aufruf des nächsten TAPs (RecCopy) schon umbenannt sind.

Allerdings habe ich auch eingestellt:
6. Arbeistmodus: nach jeder Aufnahme starten (TSR)

Damit sollte die Datei doch schon vor dem Ausschalten des Topfes nach der Timeraufnahme umbenannt werden, oder? Das war bisher nur wegen der Verzögerung nicht passiert?

[Happy]

[quote="MiK"]
Damit sollte die Datei doch schon vor dem Ausschalten des Topfes nach der Timeraufnahme umbenannt werden, oder? Das war bisher nur wegen der Verzögerung nicht passiert?[/quote]
Das müsstest Du ausprobieren, 100%ig sicher wäre ich mir da nicht.

Gruß,
Happy

[MiK]

[quote="Happy"]Das müsstest Du ausprobieren, 100%ig sicher wäre ich mir da nicht.
[/quote]

Anscheinend funktioniert das nicht. Ich hatte heute Nacht zwei überlappende Timer-Aufnahmen. Beim Start von RecCopy um 4:00 waren beide Aufnahmen noch nicht umbenannt. Da dies dann während der Arbeit von RecCopy passiert, kommt es dann (je nach Zeitpunkt) zu mehr oder weniger großen Fehler im Ablauf von RecCopy.

Könnte man das Umbenennen nicht schon einmal in TAP_Main() durchführen? Das dauert doch nicht so lange, oder? Und so könnte man ohne Zusätze wie XStart oder BootMenu sicherstellen, dass RecCopy keine Probleme bekommt.

[Happy]

Leider ist das ohne größeren Aufwand nicht umstellbar.

Ich frage mich, wie sich Automove und Reccopy bei anderen Anwendern verhalten. Klappt das dort ?

Gruß,
Happy

[MiK]

Es ist eben eine Timingfrage. Wenn man eine Verzögerung eingestellt hat, tritt es nur auf, wenn mehr als eine Sendung entschlüsselt werden müssen und die noch nicht umbenannte nicht als erstes dran kommt. RecCopy erstellt am Anfang eine Liste und scannt die Aufnahmen. Wenn sie dann später entschlüsselt werden sollen und die Datei heißt dann anders kommt es zu einem Fehler.

Jetzt ohne eingestellte Verzögerung war es noch schlimmer, weil dann die Umbenennung genau in der Initialisierung und vor dem Scannen kam...

[Töppi]

Firebird hat ein Reccopy Update bereitgestellt.

[FireBird]

Was in MiKs Fall aber nichts bringt. Mal schauen, wie lange er sich gegen XStart zur Wehr setzt.

[Töppi]

hatte nur etwas von "Timing" gelesen .....

[Happy]

Habe mir den Automove start nochmal angesehen.
AM legt sogar erst 5 Sekunden nach dem Start aller TAPs los mit Umbenennen und Verschieben, damit der Topf möglichst früh bedienbar wird.

Nach einer Aufnahme, wenn der Topf bis dahin nicht per Tastendruck bedient wurde, wird kein eVerschieben und umbenenen mehr gestartet, weil das zu lange gehen könnte.

(Diese Einschränkung fällt bei der nächsten TMS-Version, denn dieser ist schnell genug, wie ich am Wochenende getestet habe)

Gruß,
Happy

[Wolfman]

Stimmt... bei meinem 5500er kamen sich beide nicht in die Quere, ich weiß aber gerade nicht, welche Verzögerung ich eingestellt hatte.

Die Verzögerung hatte bei mir überhaupt keinen Einfluss, weil ich, wie mir hiernach

Was in MiKs Fall aber nichts bringt. Mal schauen, wie lange er sich gegen XStart zur Wehr setzt.

wieder einfiel, ja BootMenu benutzt habe und RecCopy ohne AutoMove starten ließ (steht sogar in meiner Sig) ops: