# \[F\] Falsches Verzeichnis wenn Fehler bei Umbenennen über Aktion **URL:** \ **Category:** Fehlermeldungen\ **Created:** [January 10, 2018, 5:47am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679 "2018-01-10T05:47:25Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [January 10, 2018, 5:47am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/1 "2018-01-10T05:47:25Z")
So, jetzt ist aber doch was passiert, was anscheinend mit Aufräumen nicht zu beseitigen geht: Grundlage ist die neu angelegte Datenbank. Es kommen dynamisch Dateien dazu, die dann nach Schema umbenannt werden. Dieses Schema führt dazu, dass ein neu angelegtes Verzeichnis plus Dateiname illegal lang sind, woraufhin MP3tag meldet, dass es die Datei nicht finden kann. Aktualisieren der Ansicht mit F5 zeigt die Datei in dem vermeintlich neuen Verzeichnis, jeder Versuch, auf sie zuzugreifen, führt zu einer leeren Tag-Anzeige und Editierversucht zur Fehlermeldung (klar, Dateiname eigentlich zu lang). Fakt ist allerdings, dass sich die Datei unumbenannt noch im Ausgangsordner befindet. Eine Bereinigung der Datenbank gibt auch an, dass einige wenige Datensätze bereinigt wurden (frohlocken!), als aber die Datei bearbeitet werden soll, wird sie mit dem Zielverzeichnis als Pfad gezeigt, wo sie natürlich nicht ist, sie ist ja noch im Ausgangsverzeichnis - eine Bearbeitung schläg fehl. Im Screendump ist Pfad und Dateiname der wirklich vorhandenen Datei im Explorer zu sehen und in MP3tag der in MP3tag gespeicherte Pfad. Dieser Pfad lässt sich nicht aktualisieren. Auch nicht mit Aufräumen. ![](https://community.mp3tag.de/uploads/default/original/2X/d/d1154fc089c72d4360aa5d3254478883cb69f352.png) Was (natürlich?) hilft: Datei im Ausgangsverzeichnis geringfügig umbenennen (ne 1 oder n \_ dazu) und neu einlesen. Da ist sie wieder. Anschließendes Aufräumen scheint den irreleitenden Eintrag zu löschen, jedenfalls wird bei einer erneuten Umbenennung der Ausgangsdatei auf den ursprünglichen Namen nicht der falsche Pfad gezeigt. (F5 geht irgendwie nicht wirklich gut in diesem Zusammenhang ...) ![](https://community.mp3tag.de/uploads/default/original/2X/d/d1154fc089c72d4360aa5d3254478883cb69f352.png) ---
**Author:** ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)\ **Post date:** [January 11, 2018, 7:03am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/2 "2018-01-11T07:03:28Z")
@Ohrenkino Besteht das Problem auch, wenn Du MP3Tag beendest und nach einem Neustart den betreffenden Ordner neu einliest? Ist es also ganz klar einem fehlerhaften Datenbankeintrag zuzuordnen? Dass bei mir MP3Tag durch fehlgeschlagene Aktionsverschiebungen in einen Zustand gerät, wo falsche Ordner angezeigt werden und auf Dateien nicht zuzugreifen ist habe ich m.E. auch schon früher ohne Datenbank gehabt. Allerdings verschärft natürlich die Datenbanklösung potentiell das Problem. ---
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [January 11, 2018, 7:09am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/3 "2018-01-11T07:09:43Z")
Neustart ändert nichts. Auch beim D&D aus dem Explorer heraus, wo ja das wirkliche Verzeichnis offensichtlich sein sollte, wird weiterhin das alte (nun vermutlich in der Datenbank gespeicherte) gezeigt. Da die Datei dort aber nicht existiert, bleiben die Tags leer (die also werden akut gelesen). ---
**Author:** ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)\ **Post date:** [January 11, 2018, 7:45am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/4 "2018-01-11T07:45:43Z")
Ich sehe es so, dass das Problem schon immer bestand, dass bei bestimmten fehlgeschlagenen Aktionen MP3Tag falsche Daten hatte/anzeigte. Nur kommt jetzt durch die Speicherung der falschen Daten in der Datenbank und die fehlende Aktualisierung der Datenbankwerte, wenn sich an den Dateien nichts ändert, bei dem Problem noch eine weitere Dimension hinzu. Als noch alles nur im RAM war, genügte es einfach zu aktualisieren oder Mp3Tag neu zu starten. Jetzt muss man wohl zusätzlich noch einen Datenbank-Bereingungsvorgang starten. Es hat schon seinen Grund, warum ich im Normalfall die Datenbank in den Optionen auf wenige Ordner beschränke, die ich als fertig-getagged ansehe und für meine Vorbereitungs-Arbeitsordner die Datenbankoption nicht aktiv habe. Notwendig wäre eigentlich, dass das Enstehen solcher Zustände generell abgefangen wird, also nicht nur der falsche Datenbankeintrag, aber das scheint mir anscheinend wirklich schwierig zu sein. ---
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [January 11, 2018, 7:53am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/5 "2018-01-11T07:53:07Z")
> [@poster](#): > > ... > Notwendig wäre eigentlich, dass das Enstehen solcher Zustände generell abgefangen wird, also nicht nur der falsche Datenbankeintrag, aber das scheint mir anscheinend wirklich schwierig zu sein. Ob solche Zustände von vornherein abgefangen werden können, sei mal dahingestellt. Ich würde mir wünschen, dass wenn der Nutzer schon sagt (mit F5 oder per D&D): "Nun lies doch noch mal!", dass dann auch wirklich nochmal aus der Datei gelesen wird. Oder es eben ein "Umschalten-F5" oder sowas gibt, mit dem man sagen kann "Bitte noch mal DB und Datei synchronisieren". Denn der Ausweg, bei jedem dieser Fehler die ganze Datenbank noch mal neu anzulegen, konterkariert den beabsichtigten Zeitspareffekt für große Sammlungen doch ziemlich. Besonders ärgerlich finde ich in diesem Zusammenhang, dass ja denn, wenn es um die Bearbeitung der Tags geht, die Tags einfach leer sind, da natürlich an der in der DB gespeicherten Stelle gar keine Datei ist. Spätestens jetzt müsste dieser Eintrag gelöscht/aktualisiert werden und nicht immer wieder angeboten werden. ---
**Author:** ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)\ **Post date:** [January 11, 2018, 8:15am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/6 "2018-01-11T08:15:11Z")
> [@ohrenkino](#): > > Denn der Ausweg, bei jedem dieser Fehler die ganze Datenbank noch mal neu anzulegen, konterkariert den beabsichtigten Zeitspareffekt für große Sammlungen doch ziemlich. Es kommt aber doch ziemlich auf das Gleiche heraus, denn um zu beurteilen, ob ein Eintrag falsch oder richtig ist, müssen letztlich die Tags neu gelesen und mit der Datenbank vergleichen werden, wenn auch nicht die Datenbank komplett neu geschrieben werden. Das Lesen der Tags aus den Dateien erfordert ja den größten Anteil an Zeit. Und ohne Datenbank dauerte das Lesen ja wirklich sehr lang und musste bei mir in der Praxis bei Arbeiten mit dem großen Datenbestand wegen Abstürzen von MP3Tag aus Speichermangel oder anderen Gründen komplett wiederholt werden. ---
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [January 11, 2018, 12:25pm UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/7 "2018-01-11T12:25:39Z")
Ich meine mehr so eine Funktion, bei der explizit nur dieser eine Datensatz noch mal aufgefrischt wird, wenn doch der Anwender genau das anfordert. Allerdings müsste eine Fehleranzeige hinzukommen, wenn wie hier der Datensatz keine Entsprechung mehr als Datei hat. ---
**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\ **Post date:** [January 12, 2018, 6:32am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/8 "2018-01-12T06:32:20Z")
Ich würde gerne die Ursache für den Fehler lösen, d.h. den ungültigen Zustand der dann angezeigt wird von vornherein richtig behandeln. @ohrenkino Könntest Du mir ein minimales Beispiel beschreiben, in dem das von Dir beschriebene Verhalten auftritt? Danke und Gruß – Florian ---
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [January 12, 2018, 6:42am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/9 "2018-01-12T06:42:29Z")
Ich habe es immer hingekriegt, wenn ein aus Tags generierter Verzeichnis/Dateiname (Konverter\>Tag-Dateiname) zu lang war und MP3tag (anschließend) meldet, dass auf die Datei nicht zugegriffen werden kann. Dann steht in der Datenbank schon der neue Pfad, während die Originaldatei sich noch im Ausgangsverzeichnis befindet. Wenn Du also z.B. irgendeine Testdatei z.b. mit diesen Daten versiehst: TITLE: Soundtrack From Bernard Rose's Video Of The Welcome To The Pleasuredome Single ALBUM: All In The Mind, All In The Body (Frankie Goes To Hollywood In The Pleasuredome) ARTIST: Frankie Goes To Hollywood ALBUMARTIST: Frankie Goes To Hollywood YEAR: 1985 Und du mit Konverter\>Tag-Dateiname arbeitest: e:\musik\interpreten\%albumartist%\%year% - %album%\%albumartist% \_ %album% \_ 005 \_ %title% müsste die Erzeugung fehlschlagen, aber die ursprüngliche Testdatei unberührt im Ausgangsverzeichnis liegen. ---
**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\ **Post date:** [January 12, 2018, 6:54am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/10 "2018-01-12T06:54:08Z")
> [@ohrenkino](#): > > müsste die Erzeugung fehlschlagen, aber die ursprüngliche Testdatei unberührt im Ausgangsverzeichnis liegen. Ja, allerdings bleibt bei meinen Tests dabei auch der ursprüngliche Pfad und Dateiname der Testdatei in Mp3tag unberührt. ![](https://community.mp3tag.de/uploads/default/original/2X/7/7e7ee47384ddab492e55772c829a9732827a5bb4.png) Viele Grüße — Florian ![](https://community.mp3tag.de/uploads/default/original/2X/7/7e7ee47384ddab492e55772c829a9732827a5bb4.png) ---
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [January 12, 2018, 7:10am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/11 "2018-01-12T07:10:12Z")
> [@Florian](#): > > Ja, allerdings bleibt bei meinen Tests dabei auch der ursprüngliche Pfad und Dateiname der Testdatei > > Viele Grüße > — Florian Bis hierher ist das Verhalten deckungsgleich mit dem was ich bei mir sehe. Wenn du den Screendump in post #6 [[AF] Datenbank aufräumen - tut was?](https://community.mp3tag.de/t/19642/1) ansiehst, ist aber der Eintrag in der Datenbank schon aktualisiert. Und von jetzt an sucht MP3tag in dem (eigentlichen) Zielverzeichnis, während die Datei immer noch im Ausgangsverzeichnis ist. Das schlägt fehlt, die Tags werden im MP3tag blank. ---
**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\ **Post date:** [January 12, 2018, 7:14am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/12 "2018-01-12T07:14:04Z")
- Soweit ich das beurteilen kann ist das bei Dir auch unter Windows 7 SP1, oder? - Hast Du evtl. nicht den Konverter, sondern einen anderen Weg zum Umbenennen verwendet? - Kommt bei Dir auch das Fenster mit der Fehlermeldung? Viele Grüße — Florian ---
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [January 12, 2018, 7:17am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/13 "2018-01-12T07:17:06Z")
Nein, der Screenshot ist unter W8.1 entstanden. Ja, zugegeben, das war eine Aktion Tag-Feld formatieren für \_FILENAME Ja, es kommt auch die Meldung. Und wo wir schon am Rahmenparameter ergründen sind: Es ist aufgetreten mit einer portablen Installation, bei der MP3tag und die Daten und die Datenbank auf einer über USB3 angeschlossenen externen Festplatte liegen. ---
**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\ **Post date:** [January 13, 2018, 7:18am UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/14 "2018-01-13T07:18:10Z")
> [@ohrenkino](#): > > Ja, zugegeben, das war eine Aktion Tag-Feld formatieren für \_FILENAME Für solche Fehler ist es immer sehr hilfreich für mich, wenn Du eine minimale Anzahl von Schritten beschreiben kannst, mit denen der Fehler reproduzierbar auftritt. Ich habe unter Verwendung der Aktion Tag-Feld formatieren für \_FILENAME mit absolutem Pfad als Formatstring, eine Konstellation entdeckt, in der der Verzeichnis-Pfad fälschlicherweise auf den Zielpfad gesetzt wird, auch wenn das Umbenennen fehlschlägt. Den Umstand, dass eine Aktualisierung der Anzeige weiter den fehlerhaften Eintrag zeigt konnte ich hier nicht reproduzieren. Ich habe hier eine inoffizielle Zwischenversion gebaut, in der dieser Fehler behoben ist und freue mich natürlich wie immer über Feedback: [https://download.mp3tag.de/support/D384AAE5...gv285ksetup.exe](https://download.mp3tag.de/support/D384AAE5-4EA3-4E46-80B0-05E1DF26AC0A-285111/mp3tagv285ksetup.exe) Viele Grüße — Florian ---
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [January 14, 2018, 2:38pm UTC](https://community.mp3tag.de/t/f-falsches-verzeichnis-wenn-fehler-bei-umbenennen-uber-aktion/19679/15 "2018-01-14T14:38:45Z")
Feedback: Die gute Nachricht vorweg: mit der inoffiziellen k-Version wird die DB nicht falsch gefüllt. Ich habe einen W7 Rechner verwendet, auf dem eine Standard-Installation mit lokaler DB läuft und auch eine portable Installation der alten k-Version, die ebenfalls eine lokale DB verwendet. Die Aktions-Verzeichnisse sind bei beiden identisch gefüllt. Ich habe zuerst die alte k-Version auf einen wiederum sehr langen Titel losgelassen, was auch prompt zu der Mitteilung führt, dass der Pfad nicht gefunden werden kann. Dies führt zum im Screendump gezeigten (schon bekannten) Fehler: ![](https://community.mp3tag.de/uploads/default/original/2X/1/1821fde22c76370909a617314f40b56fa8839e33.jpg) Die Datei ist noch im alten Verzeichnis, MP3tag V2.85k(alt) zeigt aber schon den (zu langen) Zielpfad. Im Zielpfad werden auch schon die auch mit der Aktion erzeugten exportierten Bilddateien angelegt, es wird also anscheinend auf die Parameter der Datenbank zurückgegriffen und nicht auf die Datei selbst. Beim Versuch, ausschließlich die eine Datei aus dem Quellverzeichnis zu laden (D&D), wird von MP3tag V2.85k(alt) der Pfad des Zielverzeichnisses gezeigt. Dieselbe Aktion ausgeführt mit MP3tag V2.85k(neu) erzeugt auch den OS-Fehler, dass der Pfad nicht gefunden werden kann, jedoch bleibt jetzt die Datei im Quellpfad. Das habe ich mit noch 2 weiteren Dateien überprüft, so dass ich sagen würde, dass dieser Fehler beseitigt ist. ![](https://community.mp3tag.de/uploads/default/original/2X/1/1821fde22c76370909a617314f40b56fa8839e33.jpg)