Ach ja ...! Genau das war einer der Workarounds: nämlich NICHT MP3tag im Kontextmenü des Explorers aufrufen, sondern die Dateien/Verzeichnisse aus MP3tag heraus öffnen bzw. die Adresszeile des Explorers kopieren und in MP3tag einfügen.
Es scheint so zu sein, dass der Explorer entsetzlich neugierig ist, wenn ein anderes Programm Dateien öffnet und alle paar Sekunden nachguckt, ob es Daten aktualisieren kann. Das führt dann zu Zugriffsverletzungen/Blockaden.
Ggf. äußert sich das Problem auch darin, dass nur Teile einer (großen) Datei geschrieben werden und sie deshalb verworfen wird, weil kaputt.
Also: bitte den Workflow so ändern, dass nach dem Rippen das Verzeichnis über MP3tags Dateiauswahl geöffnet wird und nicht über den Explorer.
Kommt es dann immer noch vor?
Hmm ... dem wahren Grund deiner Problemsituation sind wir damit nicht auf die Spur gekommen.
Normalerweise ist bei Mp3tag ein "Kaltstart" des Rechners niemals notwendig.
Hmm ... also vielleicht war es doch ein "Raumtemperatur" Problem?
Über die Benutzung des Tag-Typs APE solltest du noch einmal intensiv nachdenken.
Wie bekannt kommt es damit immer wieder zu (Anwender-) Problemen beim Taggen von mp3 Dateien.
Das Tagger Leben wird einfacher, wenn man nur den Tag-Typ ID3v2.3 benutzt, denn der verspricht heutzutage die best mögliche Kompatibilität zwischen den Anwendungen, die Tag-Felder auslesen oder beschreiben können.
Was? Und das soll dagegen helfen, dass Dateien, die zuvor sogar im Dateisystem nicht mehr zu finden waren, jetzt völlig korrekt behandelt werden?
Du siehst mich mit verblüfft offenem Mund. Oder die Fehlerbeschreibung war eine Abwandlung zu Grimms Märchen.
Also ist es eher ein Problem der lokalen Arbeitsweise und Einstellungen und nicht ein Fehler in MP3tag?
Kannst du mal kritisch in dich gehen und gucken, worin sich der eine Ort vom anderen unterscheidet? Z.B. wäre die EInstellung, ob die externe Platte indiziert werden soll oder nicht und wie das mit der internen zusammenpasst, ein gutes Thema.
Dann stürzt sich nämlich der Indexer auf die geänderte Datei und blockiert sie.
habe dein Rat befolgt und den Indexdienst abgeschaltet.
Will nicht wieder vorgreifen, aber bischer FUNKTIONIERT es. (DANKE!)
Ich habe ja vermutet daß es irgend etwas mit dem Speicherort zu tun hat. Dem war / ist es ja so
scheinbar nicht.
Ich habe da auch etwas verwechselt : Statt den Indexdienst habe leider jedesmal ich Döddel die Indizierung der Platten in den FD - Eigenschaften mehrfach geändert - natürlich ohne Erfolg, und nicht wie jetzt auf Grund deines Tips in der Systemsteuerung / bzw. Diensten.
Falls es langfristig doch noch Probleme geben sollte werde ich mich melden, ansonsten ist für mich persönlich MEIN Problem damit gelösst.
ich hatte als ich vor ca. 2 Jahren mit MP3Tag zu arbeiten begann einen sehr ähnlichen Fehler, weiß aber nicht, ob es dasselbe Problem ist (Windows XP):
Ich war der Meinung, dass jede geänderte Zeile (Datei) mit Klick auf das Disketten-Symbol gespeichert werden müsste. In seltenen Fällen und nicht exakt reproduzierbar verschwanden einige Tags, d.h. vereinzelte Tag-Felder einer Datei waren leer, obwohl ich mir sicher war, dass da vorher etwas drin stand.
Nach einiger Zeit kam ich dahinter, dass ich nicht explizit speichern muss. Wenn ich eine geänderte Zeile verlasse, d.h. eine andere Zeile anklicke, sind die Werte automatisch gespeichert. Ich arbeite nur gelegentlich mit MP3Tag und nicht in großem Umfang, bisher mit Version 2.45a. Und der Fehler trat seitdem nicht wieder auf.
Ich vermute, dass es an dem Programmteil liegt, der mit Klick auf das Diskette-Symbol ausgeführt wird.