Ich habe das Verschieben per Aktion mal getestet. Format Value: _DIRECTORY
Diese Funktion weist einige Fehlfunktionen auf, wenn im Zielordner eine Datei mit gleichem Dateinamen existiert. Es kommt dann ja eine Abfrage, wie zu verfahren sei.
Bei "Überspringen" behält die markierte Quelldatei in der Ansicht ihre Tags. Sie wird jedoch in der Spalte %_path% im Zielordner lokalisiert. Beide angezeigten Dateien befinden sich also nach der Ansicht im Zielordner. Zu einem Neueinlesen wird man nicht aufgefordert. Wenn man das trotzdem tut, wird wieder der korrekte Zustand angezeigt.
Wenn man jedoch statt neu einzulesen in dieser Ansicht weiter arbeitet und einen Tag in der markierten Quelldatei ändere, wirkt sich die Änderung in der Zieldatei aus. Wenn man die Quelldatei aktualisiert zeigt die Ansicht 2 in den Tags gleiche Dateien im Zielordner an. Wenn man die Zieldatei in den Tags ändert, wirkt sich dies in der Ansicht auch auf die Quelldatei aus.
Die Optionen "Überspringen" bzw. "Inhalte vergleichen und Zieldatei behalten" münden also in der Ansicht in einen problematischen Zustand. Lediglich bei "Abbrechen" im Mp3Tag-Fenster "Schreibe Taginformationen" und anschließendes Schließen des Windows-Fensters mit den 3 Optionen (bzw. Auswahl von Überspringen in dem Fenster) bleibt die Ansicht korrekt.
Ich hoffe meine Ausführen über das etwas komplizierte Verhalten sind nachvollziehbar.
Mein erster Anlauf dieses Problem zu lösen war am 11. Februar 2022 und seitdem habe ich immer wieder mal Anläufe unternommen. Es war leider nicht ganz einfach.
Mit der aktuellen Version Mp3tag v3.25a sollte der inkonsistente Zustand der Dateiansicht bei Kollisionen nun behoben sein. Es sollten nun
einfach verschobene,
übersprungene,
überschriebene und
behaltene und mit einer Nummer versehene
Dateien korrekt angezeigt werden. Auch ein Abbrechen der Aktion, sollte den korrekten Status anzeigen.
Ich musste das Ganze komplett neu implementieren, sodass es diesmal den Beta-Status durchaus verdient und ich mich über ausgiebige Tests freuen würde.
Mir scheint dass bei der Bugbehebung etwas schief gelaufen ist.
Ich habe heute mal versucht den Fix zu testen, komme aber erst gar nicht zum Testen von Kollisionen, da MP3Tag schon Probleme hat, einfache Umbenennungen per Format Value für _DIRECTORY fehlerfrei durchzuführen.
Feld: _DIRECTORY
Format String: E:\MP3s\%albumartist%\%album%\
Die Aktion bringt für den 2. Track des Albumordners die Fehlermeldung "File cannot be accessed". Klickt man diese Fehlermeldung mit ok weg und überprüft den Vorgang, stellt man fest, dass die Verschiebeaktion aller Dateien des Albumordner ungeachtet der Fehlermeldung durchgeführt wurde. Die Ansicht in den Spalten von MP3Tag ortet sie aber immer im Quellordner. Wiederholt man die Aktion kommt die Fehlermeldung für Track 3 usw.
Im Forum tauchen ja auch schon im Detail anders geschilderte Probleme mit Format Value für _DIRECTORY seit der Version 3.26 auf.
Allerdings bin ich im Moment sehr verwirrt, weil ich einfach kein konsistentes Verhalten bei den Tests hinbekomme.
Zunächst mal sieht mein Workflow so aus, dass ich zunächst einen Ordner lade, in dem die Dateien eines Albums nicht alle im gleichen Unterordner liegen. Deshalb verschiebe ich per Format Value für _FILENAME die Dateien zunächst mal in den "Quellordner", wo dann das komplette Album liegt. Dieser Ordner ist dann nicht das Arbeitsverzeichnis von MP3Tag, allerdings ist er in meiner Spalte %_path% richtig verortet.
Nach einigen Bearbeitungen (Cover hinzufügen, Tags teilweise ändern bzw. löschen usw.) verschiebe ich dann alle Dateien aus diesem "Quellpfad" einschließlich im Ordner liegende Cover-Dateien usw. in den "Zielpfad" per Format Value _DIRECTORY. Dabei kommt es zu den Fehlermeldungen "File cannot be accessed", wobei der Track der gemeldeten Datei nicht immer gleich ist. Meistens ist es Track 2, manchmal auch andere. Die Dateien befinden sich zu diesem Zeitpunkt trotz Fehlermeldung bereits komplett im Zielordner. Nach einer Wiederholung dieser Verschiebe-Aktion wird eine andere Datei als nicht ansprechbar bezeichnet. Manchmal wird schon bei der 2. Fehlermeldung die Verortung der Dateien im Zielordner (Dateilistenansicht für %_path%) richtig gestellt, manchmal bedarf es einer weiteren Ausführung der Aktion. Nach richtiger Verortung bleiben Fehlermeldungen aus.
Versuche ich das ganze zu wiederholen, indem ich die Dateien außerhalb MP3Tag wieder in den Quellordner kopiere, diesen Quellordner in Mp3Tag direkt lade und die Verschiebeaktion per Format Value für _DIRECTORY durchführe klappt das zumindest bei meinen bisherigen Versuchen ohne Fehlermeldung.
Es scheint also eine gewisse Rolle zu spielen, dass diese Dateien ursprünglich über eine andere Ordnerstruktur geladen und dann verschoben wurden. Meine Hand möchte ich allerdings dafür nicht ins Feuer legen. Nach zig Versuchen habe ich sicherlich nicht alle möglichen Variationen durchgespielt und muss jetzt meinen Mausarm schonen.
Irgendwie sieht das ganze so aus, als ob Mp3Tag intern die Übersicht über den Speicherort der geladenen und durch Verschiebeaktionen behandelten Dateien zeitweise verliert.
Wenn ich in meinem Scenario die Dateiansicht aktualisiere verschwinden die in Schritt 1 meines Workflows (Format Value für _FILENAME) behandelten Dateien aus der Ansicht, da ja das Arbeitsverzeichnis aktualisiert wird, und ich müsste sie erneut hinzufügen.
Wie ich schrieb, tritt das Problem dann anscheinend nicht auf, wenn ich den Ordner in MP3Tag direkt lade.
Wenn sich jemand wundern sollte, ob mein bisheriger Workflow überhaupt funktionieren könnte:
MP3Tag hatte bisher damit bis auf die in diesem Thread geschilderten Kollisionsprobleme keinerlei Probleme. Ich mache das schon so seit ca. 12 Jahren.
Vielen Dank für die Details. Ich habe seit Anfang der Woche an den gemeldeten Problemen gearbeitet und bin jetzt soweit, eine neue Version zum Test bereitzustellen.
Könntest Du Deinen bisherigen Workflow nochmals mit der folgenden internen Testversion ausprobieren und mir Deine Ergebnisse schildern?
Bei der 326a tritt bei mir das Problem nicht mehr auf.
Auch das in Post 1 geschilderte Problem bei Dateikollision und "Überspringen" tritt nicht mehr auf.