Locked Files durch Aufruf des Albumartdownloaders

Mit der Version 2.77 (wohl auch schon einige Versionen früher) tritt folgendes Problem auf:
Ein Aufruf des AlbumArtDownloader über das Tools-Menue führt zu gelockten Files, was die weitere Verarbeitung durch MP3Tag behindert.
Mit Version 2.65 trat dieses Problem noch nicht auf

siehe auch:
/t/17915/1

Ich greife das Problem nochmals auf, weil es weiterhin besteht und einen erheblichen Nervfaktor darstellt.
Inzwischen hat sich folgende Verhaltensweise seit Monaten als beständig etabliert.

  1. Ich rufe aus MP3Tag über Tools und Parameterübergabe aus den Tags den AlbumArtDowndowder XUI auf und speichere gefundene Cover mit den Presets von AlbumArtDownloader im Ordner des Albums mit den Tracks ab.

  2. Ich schließe den AlbumArtDownloader. Im Taskmanager verschwindet das Programm bei den aktiven Apps und wandert in die Hintergrundprozesse. Dort bleibt es manchmal nur ca. 30 Sekunden, meistens aber bis zu 2 Minuten erhalten, bis es dort wieder verschwindet.

  3. Solange der AlbumArtDownloader als Hintergrundprozess im Taskmanager gelistet ist, kann MP3Tag meine Aktionen zu 99,9 % nicht auf den 11. Track (und nur diesen nicht) anwenden. Das heißt in der Praxis, dass ich alle Alben mit 11 Titeln oder mehr nicht sofort komplett weiter bearbeiten kann sondern entweder ca. 2 Minuten warten oder vorher den Hintergrundprozess über den Taskmanager beenden muss.

  4. Ich benutze den AlbumartDownloader seit Jahren und bis letztes Jahr dieses Problem auftrat, hatte ich nie derartige Schwieigkeiten.
    Keine Ahnung, ob das Problem an Windows 10, einer neuen Version von AlbumArtDownloader oder einer veränderten Version von Mp3Tag liegt.
    Ein Test bei einer alten Installation von Windows 7 und einer älteren MP3Tag-Version verlief ohne solche Probleme.

Das ist ja eigenartig, genau diesen Fehler wollte ich gerade schildern!
Bei mir ist es ebenfalls der 11te Track der sich nicht bearbeiten lässt.

Den AAD benutze ich ebenfalls seit Jahren, allerdings separat gestartet und nicht durch Parameterübergabe, aber das bleibt sich wohl gleich..

Der AAD beendet sich oft nicht, das ist extrem nervig, ich behelfe mir indem ich den Task abschiesse oder schlicht weg irgendein anderes Album per rechtsklick an den AAD übergebe und dann beende, das entlockt die Files im Mp3Tag.
Das Problem hatte ich früher auch nicht, erst seit Win10..
Ich bezweifle das MP3Tag daran schuld ist, tippe eher auf den AAD, der ja nur sehr gemässigt weiterentwickelt wird, aber genau weiss ich das natürlich auch nicht..

Gerade beim bearbeiten größerer Discographien ist das alles ein ziemlicher Murks..

In dem Fall übergibt Du dem AAD den Speicherordner manuell und es immer der, in dem auch die Musikfiles liegen?
Ich habe da immer einen Zusammenhang mit der Parameterübergabe durch MP3Tag gesehen, bei der ja auch der Speicherordner übergeben wird.
Deine Schilderung würde ja in dem Fall bedeuten, dass der AAD grundsätzlich solange er nicht auch als Hintergrundprozess beendet ist in Zusammenarbeit mit W10 den 11. Track eines Ordners lockt, in dem er sein Cover abspeichert.
Irgendwie ist das völlig abstrus.

Ich kann ja noch nachvollziehen - wenn auch schwer nachvollziehen, dass vielleicht eine Software einen Ordner komplett lockt, wenn sie etwas darin speichert. Warum aber alle Files des Ordners bis auf den 11. Musiktrack bearbeitbar bleiben, entzieht sich meiner Erklärungslogik.

I have had a similar issue but have been able to do a work around where I only search one file from the corresponding folder for artwork than save whatever artwork I would like. I save it to a folder within that corresponding mp3 files folder labelled as artwork - %preset% (the default extension from AAD) this allows me to save multiple artwork such as the "artwork - cover" as well as the "artwork-sleeve" and any "artwork-booklet" and so on..than I go back and select all files in that folder and apply the artwork from that folder.

If memory serves the instructions are here.../t/11489/1

Ich benutze keinen separaten Unterordner für die Cover-Dateien sondern speichere sie permanent im Albumordner. Das möchte ich so beibehalten und ein Workaround der unter den Voraussetzungen erfordert, dass ich anschließend noch Files verschiebe, bringt mit nicht mehr Zeitgewinn als das Task-Abschießen mit dem Tasmanager.
Ansonsten ist mein Workflow weitgehend indentisch.

Da ich nach dem Herunterladen der Files durch den AAD ohnehin zuerst per Tools einen command-batch auf die Bilddateien loslasse, bevor ich weitere MP3Tag-Aktionen auf die Musikfiles anwende, habe ich jetzt in dieser Batch-Datei einen taskkill-Befehl eingebaut.

taskkill /IM AlbumArt.exe /F

Dennoch bleibt das natürlich eine unschöne Notlösung.

Kannst Du das Problem auch ohne Mp3tag reproduzieren?

Ich habe etwas rumprobiert.

Der User Ananda führt weiter oben an, dass das Problem auch auftritt, wenn er AAD manuell startet.
Ich habe das mehrere Male probiert, d.h. den AAD gestartet, die Suchkriterien von Hand eingetragen und manuell den Albumordner als Speicherplatz angegeben.
So trat das Problem des gelockten 11. Tracks bei mir nicht auf. Bisher konnte ich das also nicht nachvollziehen.

Bei mir tritt es also bisher nur auf, wenn ich AAD über das Tools-Menü aufrufe, wobei ich in dem Fall %albumartist% und %album% als Suchparameter übergebe.

'/artist "'$if2(%ALBUMARTIST%,%ARTIST%)'"  '/album "%ALBUM%"' /path "'%_folderpath%$if2(%ALBUMARTIST%,%ARTIST%)' - '$replace(%ALBUM%,?,,/,-,*,,:, - )'%preset%.jpg"'

Es ist jedoch kein MP3Tag-Problem, dass die anschließenden Aktionen fehlschlagen. Das 11. Musikfile ist generell gelockt und lässt sich auch nicht im Explorer umbenennen. Der Explorer gibt als Fehlermeldung aus, dass die Datei durch AAD in Benutzung ist. Auch ein Beenden von MP3Tag ändert daran nichts.
Es macht auch keinen Unterschied, ob ich beim Tools-Aufruf von AAD alle Files eines Albums markiert habe oder nur eins ("für alle ausgewählten Dateien" ist nicht angehakt). In jedem Fall ist ist dann nur Track 11 betroffen, in ganz seltenen Fällen auch schon mal nur Track 10.

Daher ging meine bisherige Vermutung in die Richtung, dass sich eventuell etwas am Verhalten mit W10 mit MP3Tag bei so einem Tools-Aufruf intern geändert hat. Vielleicht verhält sich W10 anders oder es ist eine Änderung bei der Überarbeitung von MP3Tag aufgetreten, die Du 2016 vorgenommen hast.

Es passiert oft, dass zu Beginn einer Arbeits-Session mit MP3Tag und AAD das Locken des 11. Tracks nur nach dem 2. Mal und dann alle weitere Male auftritt und das 1. Mal noch problemslos ohne Locken klappt.

Der Schuldige, der Track 11 in Beschlag nimmt und ihn erst frei gibt, wenn er auch als Hintergrundprozess beendet ist, ist wohl klar der AAD.
Da ich aber das Problem bisher nur beim geschilderten Aufruf aus MP3Tag reproduzieren kann, sieht es bisher für mich nach einem Problem des Zusammenwirkens aus.

Ist das Verhalten eigentlich normal, dass ich beim Starten und beim Beenden von AAD im Taskmanager beobachtet habe?
Beim Start: Ganz kurz erscheint das Programm als Hintergrundprozess und wenn das Fenster sich öffnet, springt es nach oben zu den Apps.
Beim Beenden: Es verschwindet bei den Apps, springt nach unten zu den Hintergrundprozessen und bleibt dort bis zu 2 Minuten um dann zu verschwinden.

Es entzieht sich wohl jeder Erklärungslogik, existiert aber :slight_smile:
Ich habe eine 4TB Musikplatte und von dort übergebe ich an den AAD.
Wenn ich vor dem Covern erst vortaggen muss weil die Files ziemlich verwüstet sind (Webfund), damit der AAD richtig sucht, klappt alles.

Umgekehrt eben nicht, Files locked, aber auch nicht ständig.
Sicher ist das abstrus...

Das kann ich ebenfalls bestätigen, ich benutze den "System Explorer 7.1" (exzellente Freeware) um den AAD zu beobachten, der geht nicht gerne freiwillig. (Aber manchmal eben doch)
Das Problem bleibt sich gleich ob man den AAD via MP3Tag startet oder direkt.
Ergo muss der Verursacher der AAD sein, weniger der Tagger.
Aber ich bin kein Programmierer, mir steht keine Beurteilung zu.. :slight_smile:

Das ist sehr schade weil ich den AAD fast täglich benutze und ich die automatische Größensortierung der Cover schätze und es keine vernünftige Alternative gibt..

Eigentlich wäre es sinnvoll eine Problemschilderung hier zu stellen...

https://hydrogenaud.io/index.php/topic,57392.0.html

Oder ist WIN10 Creators Update schuld?

Wenn ich den AAD manuell starte, ist zwar das Verhalten beim Beenden gleich (bleibt eine Zeitlang als Hindergrundprozess erhalten), allerdings kann ich in dem Fall keine Auswirkungen hinsichtlich des Lockens des 11. Tracks feststellen. Wie soll der AAD auch beim manuellen Start wissen, in welchem Ordner er eine Datei locken "soll"?
Bei der Parameterübergabe durch die Tools von MP3Tag bekommt er den Ordner ja mitgeteilt.

Dort liegt ja auch eine Schilderung des Problems vor - eine Reaktion darauf jedoch nicht.
https://hydrogenaud.io/index.php/topic,5739....html#msg934327

Könnte das am Schreib/Lese Cache oder der Inizierung von Win 10 liegen?
Ich habe das Problem auch bei anderen Programmen wie IrfanView und Foobar 2000 festgestellt.
In den Laufwerkseigenschaften unter allgemein steht "Zulassen,dass für Dateien auf diesem Laufwerk Inhalte zusätzlich zu Dateieigenschaften indiziert werden", wenn ich im Total Commander eine einzelne Datei lösche, werden im Filecount immer zwei Dateien angegeben, obwohl eigentlich nur eine Datei gelöscht wird (evtl.eine physisch und eine im Index?). Möglicherweise werden die Dateien solange gesperrt,bis die Änderungen in den Index übernommen worden sind?
Foobar 2000 zeigt den aktuell wiedergegebenen Track bei mir im Infocenter an. Leider hinkt die Anzeige manchmal dem tatsächlich wiedergegebenen Track hinterher. Wenn ich dann versuche das Verzeichnis zu verschieben, geht das nur teilweise, weil die noch nicht angezeigten Dateien vom Infocenter blockiert werden.
Ich werde mal auprobieren was passiert wenn ich die zusätzliche Indizierung für ein Laufwerk abschalte.

An der Indizierung liegt es mit Sicherheit nicht. Ich habe das Problem bei indizierten als auch bei nicht indizierten Ordnern.
Die von Dir angeführte Indizierung lässt sich übrigens viel detaillierter in den Indizierungsoptionen einstellen.
Das Problem ist m.E. direkt dem AAD zuzuordnen, denn es verschwindet ja augenblicklich, wenn der als Hintergrundprozess beendet wird.

War nur so eine Idee, da ich AAD nicht nutze und die selben oder ähnliche Probleme mit einigen Programmen habe.

Update:
Nachdem ich vor 2 Tagen bei meinem Windows 10 das erschienene "Fall Creators Update" installiert habe, ist das Problem mit den gesperrten Dateien im Zusammenhang mit dem AlbumArtDownloader nicht mehr aufgetreten.

Edit:
Meine o.a. Aussage muss ich relativieren.
Das Problem der gesperrten Dateien (fast immer der 11. Track) ist bei mir ganz vereinzelt wieder aufgetreten. Fakt ist jedoch, dass dieses Problem vor dem letzen Windows Update fast zu 100 % bei Alben mit 11 Tracks oder mehr auftrat, inzwischen vielleicht nur noch bei ca. 5 %. Bei diesen 5 % ist das Problem auch nicht mehr so gravierend, d.h. dass die Datei schon nach wenigen Sekunden wieder freigegeben wird. Früher dauerte dies meistens um die 1 Minute, manchmal bis 2 Minuten.