Locked Files

#1

Seit einigen Wochen habe ich das Problem, dass MP3Tag bei meinen Aktionensgruppen aussteigt mit der Meldung, dass eines der markierten MP3s nicht zum Schreiben geöffnet werden könnte.

Nach einer gewissen Wartezeit klappt es dann.

Ich habe also mal nach der Ursache geforscht und bin in mich gegangen, was sich alles bei meiner Konfiguration geändert hat, seitdem das Phänomen aufgetreten ist:
Neues Windows - Version 10
Neuer MP3Tag - Version 2.77
Neuer AlbumArtDownloader XUI 1.0.2.0

Dann habe ich einige Tests angestellt und glaube zumindest einiges raus bekommen zu haben.

Mein Workflow - etwas vereinfachte Darstellung:

  1. Markieren aller der Files eines Albums (direkt alle weil die Markierung in der Folge bei der Aktion gebraucht wird.)

  2. Aufruf des AlbumArtDownloaders mit der rechten Maustaste über Tools (Häkchen bei "alle gewählten Files" nicht gesetzt)

  3. Schließen des AlbumArtDownloaders

  4. Aufruf einer Aktionsgruppe, die u.a. das gespeicherte Cover-File in den Tag abspeichert.

Hierbei kommt es jetzt (in der Vergangenheit nie) zu dem Fehler-Problem, dass 1 File nicht zu beschreiben ist. Anscheinend ist es gelocked. Nach einiger Wartezeit klappt es wieder.
Seltsamerweise ist es immer das 10. File, was diese Fehlermeldung hervorruft, d.h. die Files 1-9 werden noch durch die Aktion verarbeitet, ab dem 10. File wird die Aktion mit der Fehlermeldung unterbrochen.

Das Ganze ist etwas nervig und ich frage mich, welche von meinen Software-Änderungen (Windows, AlbumArtDownloader, MP3Tag) letztlich dafür verantwortlich ist und warum um Himmels Willen immer das 10. File betroffen ist.

Versuche das Ganze auf der früheren Softwarebasis durchzutesten habe ich noch nicht angestellt.

Locked Files durch Aufruf des Albumartdownloaders
#2

Das ist normalerweise der Windows Explorer oder WMP, der bei sich ändernden Dateien, zu denen gleichzeitig ein Ordner geöffnet ist, die Metadaten erkunden, um ggf. Index und thumbnail zu aktualisieren.
Und das sperrt dann die Datei.

Es sollte helfen, den WE (und/oder WMP) zu schließen.

#3

Ich habe inzwischen etwas weiter herumprobiert.

WMP hatte ich bisher noch nie aufgerufen. Klar ist der Windows Explorer geöffnet, aber ob der geöffnet oder geschlossen ist hat keinen Einfluss. Den Index hatte ich auch zuerst in Verdacht, er ist es aber wohl nicht.

Das Problem tritt immer auf, wenn ich den AlbumArtDownloader per Tools öffne, auch dann, wenn ich ihn sofort wieder schließe ohne eine Cover-Datei abzuspeichern, also ohne dass sich überhaupt etwas in dem betreffenden Albumordner verändert.

Wenn ich das AlbumArtDownloader-Fenster offen lasse, bleibt das Problem dauerhaft. Wenn ich es wieder geschlossen habe, tritt es zunächst auf, verschwindet aber nach kurzer Zeit.
Selbst wenn ich z.B. nur Track 1 markiere und den AlbumArtDownloader per Tools starte, anschließend beispielsweise alle Albumfiles mit dem Wizard durchnummerieren will, steigt MP3Tag mit der Fehlermeldung bei Track 10 aus.

Hinsichtlich Track 10 muss ich etwas korrigieren: Fast immer ist es Track 10, ich hatte bei jetzt zig Tests jedoch auch einmal Track 11 und einmal Track 12. Noch nie war also ein Track unter 10 betroffen.

Mit stellt sich nun die Frage, ob

  • es neuerdings einen veränderten Tools-Aufruf in MP3Tag gibt, der das hervorruft
  • ob AlbumArtDownloader neuderdings aus unerfindlichen Gründen Files im Ordner locked (mit einer Vorliebe für Track 10)
  • ob Windows 10 irgendwie anders vorgeht, was zu dem Phänomen führt.

Ich muss nochmals anführen, dass bei nichtgeschlossenem AlbumArtLoader-Fenster früher nie ein File gelocked war. Jetzt ist das 10. File dauerhaft gelockt, solange das Fenster offenbleibt und bleibt für eine Zeitspanne gelocked, nachdem es geschlossen wurde.
Mein Aufrufparameter:
'/artist "'$if2(%ALBUMARTIST%,%ARTIST%)'" '/album "%ALBUM%"' /path "'%_folderpath%$if2(%ALBUMARTIST%,%ARTIST%)' - '$validate(%ALBUM%, -)'%preset%.jpg"'

#4

Dann guck doch mal im Task Manager, ob sich der AAD auch jedes Mal wieder beendet und nicht als Hintergrundprozess noch ein Weilchen erhalten bleibt.

#5

Der ist sofort weg.
Aber selbst wenn er nicht weg wäre, würde sich die Frage stellen, warum dieses Problem früher nie aufgetreten ist.

#6

Im Task manager gibt es in der Ansich "Mehr Details" unter der Abteilung
Apps
die Abteilung
Hintergrundprozesse.
Ein Programm verschwindet aus den Apps, wenn das GUI geschlossen wird und kann dann noch beliebige Zeit in den Hintergrundprozessen verweilen (Macht z.B. WMP gerne - wenn der auf ein Verzeichnis einer externen HDD zugegriffen hat, kann man die HDD erst abdocken, wenn der Hintergrundprozess auch beendet ist ...).
Deshalb die Nachfrage.

#7

o.k.
Ich habe es mir so und auch zusätzlich in Sysinternals Process-Explorer angesehen, wo AAD als von MP3Tag aufgerufener Prozess abgebildet wird.
Teilweise wird der Prozess in der Tat erst etwas später geschlossen, nachdem er beendet wurde. Das erklärt, warum das Phänomen kurzfristig auch auftritt, wenn AAD beendet wurde.

Das alles erklärt aber nicht das generelle Verhalten, denn bis vor kurzem wurden auch keine Files geblockt, wenn der AAD-Prozess überhaupt nicht beendet wurde und das Fenster noch aktiv war.
Warum werden überhaupt Files durch diesen Aufruf geblockt und zudem nicht alle Files des Ordners geblockt?

Ich habe weiter geforscht und meinen W7-Home-Rechner bemüht:

  1. Dort war noch Mp3Tag 2.65 installiert. Gleiche AlbumArtDownloader-Version
    Das Problem tritt nicht auf.

  2. Mp3Tag 2.77 installiert. Das Problem tritt auf.

Damit haben wir wohl den Verursacher für das Problem. Ich werde mal einen Eintrag im Unterforum "Fehlermeldungen" machen.