Fehlverhalten beim Verschieben von Dateien per Konverter oder einer Aktion

Ich habe in der Vergangenheit schon mehrmals über Probleme beim Dateiverschiebungen über den Konverter oder eine Aktion berichtet, die aufgrund eines Abbruchs wegen gesperrten Dateien auftreten. Solche betroffenen gesperrten Dateien beruhen natürlich in der Regel auf einem Benutzerfehlverhalten (wie z.B. das gleichzeitige Abspielen in einem Player). Teilweise kann allerdings die Ursache einer gesperrten Datei etwas komplexer und für den Nutzer nicht immer offensichtlich sein.

Hier ein Variantenbeispiel:

Ein Bestand von Mp3s ist in Mp3Tag geladen. Ein Album wird markiert und soll nach Bearbeitung in eine neue Ordnerstruktur verschoben werden. Track 3 wird im Player abgespielt und und ist somit für die Verschiebung gesperrt.
Die Verschiebung wird über den Konverter Tag->Dateiname oder eine Aktion Tagfeld formatieren für _FILENAME mit dem Format String
D:\MP3s\Zielordner\%albumartist%\%album%\$num(%track%,2) - %artist% - %title%
gestartet, verarbeitet die Tracks 1 und 2 und stoppt bei Track 3 mit einer Mp3Tag-Fehlermeldung, auf die man mit "Abbrechen, Wiederholen, Ignorieren" reagieren kann. Man erkennt als Problemverursachung das zeitgleiche Abspielen von Track 3 und beendet den Player.

Jetzt versucht man per "Wiederholen" fortzufahren, Mp3Tag wiederholt jedoch die Fehlermeldung, dass auf Track 3 nicht zugegriffen werden kann, verschiebt aber dennoch Track 3 (und zwar nur Track 3) und belässt die Tracks 4ff im Quellordner. In der Anzeige verortet Mp3Tag Track 3 nach wie vor im Quellordner. Weitere Aktionen schlagen demgemäß bei Track 3 fehl (und bei den weiteren hinter Track liegenden markierten Dateien).

Um den Zielordner ordnungsgemäß in Mp3Tag einzubinden, könnte man jetzt auf die Idee kommen, diesen Ordner der bestehenden Auswahl hinzuzufügen, sei es über das Menü oder per Drag&Drop. Das ändert jedoch nichts an der Anzeige für Track 3, d.h. das Hinzufügen dieses Zielordners bringt keinen aktuellen Zustand. Erst ein weiteres Aktualisieren bringt wieder eine korrekte Anzeige.

Wenn man also nicht über "Hinzufügen des Zielordners" und "Aktulisieren" sich wieder den tatsächlichen Zustand in die Anzeige bringt, hat man einen problematischen Zustand bei der Weiterverarbeitung. Bei einem alleinigen Aktualisieren (ohne Hinzufügen des Zielordners) hätte man Track 1-3 nicht mehr in der Anzeige und könnte ggfls. das Album nicht komplett weiter bearbeiten.

Noch etwas problematischer wird der Zustand, wenn man wie ich diese Verschiebung im Rahmen einer Aktionsgruppe durchführt, die vor der letztlichen Verschiebung eine Reihe von Tagveränderungen durch Aktionen durchführt.

Mp3Tag legt übrigens den Zielordner vor dem Verschieben der Datei an und dieser leere Pfad ist demgemäß auch dort angelegt, wenn das Verschieben überhaupt nicht zum Zuge kommt, wenn z.B. der Abbruch schon bei Track 1 erfolgt.

1 Like

Vielen Dank für die ausführliche Beschreibung des Fehlers, der mit Mp3tag v3.19 nun behoben sein sollte.