Mit der v2.85c sollte jetzt vieles besser funktionieren. Das Umbenennen von Verzeichnissen hat denke ich zu den meisten Problemen geführt.
Zu Deinen Vorschlägen: da muss ich mal darüber nachdenken. Für die Adressierung der Speicherprobleme sehe ich momentan zwei Wege: entweder eine harte Grenze für die Größe einer Sammlung einzuführen (sehr einfach) oder zu versuchen mehr und mehr Informationen aus dem Speicher zu bekommen (sehr schwer).
Meine Vorgehensweise, die sich über Jahre herausgebildet hat, kennt aus Gründen der Übersichtlichkeit mehrere Stufen der Bearbeitung. Bei diesen Stufen verschiebe ich nach getaner Tat die Dateien mehrmals in anderen Bearbeitungsordner, bis er reif für die endgültige Sammlung ist.
Nur kurz etwas vereinfacht und verkürzt zum Verständnis:
Stufe:
Dateien haben keine Tags (oder nur rudimentäre) und auch nicht immer "sprechenden Namen", können also beispielsweise für ein Album einfach auch von 1.mp3 bis 15.mp3 durchnummeriert sein.
In dieser Stufe werden die zu einem Album gehörigen Dateien markiert und über eine Websource bestückt, anschließend über eine Aktionsgruppe in den Ordner der 2. Stufe verschoben und gleichzeitig der Dateiname zur besseren Übersichtlichkeit anhand der Tags ($num(%track%,2) - %artist% - %title%) festgelegt.
Stufe:
Durchsicht, was die Websource an Ungereimtheiten verbrochen hat und Änderung verschiedener Sachen bei den Tags nach meinen Vorstellungen, z.B. "feat. ..." vom Titel in den artist-tag, Tracknummerieung bei mehreren CDs nach physischen Medien statt durchgehend, Ermitten des tatsächlichen Erscheinungsjahres, Ändern des Genres usw.
Dann Suchen nach Album-Covern durch AAD (Front, Back, CD. Booklets usw.) und Speicher eines 800x800-großen Frontcovers in die Tags, das mit einer Aktionsgruppe geschieht, die auch u.a. eine Neubennenung des Dateinamens beinhaltet, die aufgrund der vorgenommenen Änderungen erfolgt.
Anschließend Verschiebung in eine neuen Bearbeitungsordner.
Stufe:
Automatisiertes Suchen nach Lyrics über Mediamonkey und dessen Script Lyricator.
Durchsicht der gefundenen Lyricsergebnisse und weitere Online-Recherchen nach Lyrics, die per C&P gespeichert werden.
Anschließend Verschieben des kompletten Album-Ordners durch eine Aktionsgruppe, die auch weitere kleinere Bereinigungen vornimmt in den endgültigen Bestimmungsordner.
Die entsprechenden Files hat MP3Tag bereits in der 1. Stufe in die Datenbank eingelesen. Danach werden diese Dateien dann in den weiteren Stufen mehrmals durch Erweiterung und Änderung der Tags und teilweise des Dateinamens verändert und zudem noch verschoben, was MP3Tag bei seiner Datenbanklösung alles nachhalten muss.
Die Verschiebung erfolgt teilweise durch eine Tagfeld-Formatieren Aktion des Tagfeldes _DIRECTORY, was erforderlich ist, da auch Nichtmusikdateien im Ordner mit verschoben werden sollen.
Anscheinend werden meine festgestellten Abstürze und Probleme wohl durch eine Inkonsistenz zwischen Datenbank und Dateien hervorgerufen, wahrscheinlich weil ein Tagfeld-Formatieren von _DIRECTORY - wie Florian schrieb - nicht berücksichtigt wird.
Mp3Tag ist sehr flexibel und erlaubt die unterschiedlichsten persönlichen Herangehensweisen bei der Bearbeitung. Neben Usern die gerne ihren ganzen Datenbestand einlesen und daran herumdoktern, gibt es halt auch User wie mich, die sich für ein häppchenweises Vorgehen entschlossen haben, nicht zuletzt auch mit beeinflusst durch die bisherigen Performance- und Speicherprobleme.
Ich sehe bei einer Datenbanklösung, die natürlich viele Vorteile bietet, die grundsätzliche Problematik alles konsistent zu halten und auch Abstürze von Programm und Betriebssystem auszuhalten.
In dem Bereich, den ich kenne (Mediamonkey, Subsonic) kommt es immer wieder mal zu Konsistenzproblemen.
Bei der überwiegenden täglichen Arbeit, in der ich allenfalls um die 1000 Dateien (meistens viel weniger) in MP3Tag lade, sehe ich keinen Vorteil in der Datenbanklösung. Vereinzelte Aufgaben wiederum erfordern das Laden des gesamten Datenbestandes und sind ohne Datenbanklösung einfach nicht wirklich praktikabel.
Bedenken habe ich gegen eine grundsätzliche Datenbanklösung, bei der MP3Tag alles was es denn in der alltäglichen Aufarbeitungsphase aus den verschiedensten Ordnern lädt, ständig bei Verschiebungen, Änderungen oder auch geduldeten Duplikaten oder Symlinks nachhalten und "umbuchen" muss, bis eine Datei ihren vorläufig endgültigen Bearbeitungszustand und Ort erreicht hat.
Für mich persönlich wäre daher eine Options-Lösung am besten, bei der ich wählen könnte, ob ich mich im alltäglichen häppchenweisen Bearbeitungsmodus befinde und auf das Speichern in der Datenbank verzichte, oder ob ich mich einer Aufgabe widme, bei der die Nutzung der Datenbank sinnvoll wäre. Ich sehe aber auch, dass eine solche Variationsmöglichkeit womöglich neue Nutzer zunächst mal verwirrt und vielleicht überfordert.
Wenn das Verlassen des Betastadiums nur aufgrund der nicht endgültig ausgetesteten neuen Datenbankfunktionen nicht möglich ist, könnten natürlich auch sonstige Bugfixes aufgehalten werden bis wieder eine Stable-Version herausgegeben wird.
Vielleicht sollte Florian das daher irgendwie trennen in Versionslevel, denn es hadelt sich ja doch um einen größeren Einschnitt:
Zum einen die neue Datenbankversion beginnend mit Version 3 und für einige Zeit parallel weiterhin die Version 2 mit nur dringend erforderlichen Bugfixes für Bugs, die irgendwann mal festgestellt werden.
Alternativ böte sich eine Option in MP3Tag, die da heißen könnte:
"Aktivieren der experimentellen Datenbankfunktion" mit entsprechenden Wanrungshinweisen an.
Zuletzt aber das überfällige Lob an Florian, dass der sich dieser doch umfassenden neuen Herausforderung widmet. 
Bei mir besteht eine erhebliche Diskrepanz zwischen den vorhanden Dateien und den tatsächlich dann verarbeiteten Musikdateien. In der Fortschrittsanzeige zeigt MP3Tag alle Dateien, d.h. auch die Cover-Dateien usw. an.
Das ist ja nicht das einzige Speicher-Crash-Problem. Ich muss mich beim Einlesen auf eine geringere Zahl Files beschränken, weil erst die anschließend anstehende Aufgabe der Erstellung eines umfangreichen Reports zum Crash führt. Das heißt, ein wesentlicher Speichermehrbedarf tritt wohl auch bei der Erstellung eines Reports auf.
Bei meiner heutigen Tagarbeit ist dieses Problem nicht mehr aufgetreten. Der Fix ist wohl erfolgreich.
Anderes Problem:
Ich hatte ja das Problem, dass in der Vergangenheit durch den Aufruf des AlbumArtDownloaders das 11. Trackfile für eine Zeitlang gelockt wurde.
Locked Files durch Aufruf des Albumartdownloaders
Dieses Problem hatte sich mit dem letzten Windows 10 Update (Fall Creators Update) nahezu völlig verflüchtigt. Es trat statt vorher regelmäßig nur noch ganz selten auf und die Lockzeit betrug dann auch nur noch wenige Sekunden, d.h. der 2. Schreibversuch klappte immer.
Jetzt mit 2.85c muss ich leider feststellen, dass das Problem teilweise zurückgekehrt ist. Das Locken tritt wieder sehr oft auf und wenn es auftritt hält es auch über 1 Minute an.
Ich habe noch versucht den Zeitunterschied beim runterscrollen zu vergleichen. Ich drück auf der obersten Zeile auf die Cursor-nach-unten-Taste und lasse diese nicht mehr los.
Die gleiche Anzahl Dateien vom gleichen Speicherort 1 x mit Mp3tag 2.84e und einmal mit 2.85c:
und
Die beiden AniGifs zeigen mein Bauchgefühl ziemlich treffend. 2.85c ist gefühlte 3 x langsamer. Man beachte auch den Unterschied, dass in 2.85c der Refresh der Covers nicht mehr mit kommt. In 2.84 wechselt das Cover auf dieser Auswahl 4 x
Guter Hinweis, Danke poster! Das wusste ich nicht.
Da ich aber ausschliesslich *.mp3-Dateien in meinen Verzeichnissen habe (z.B. keine Bilder, keine Text oder HTML-Dateien), sollte eigentlich die Anzahl im Fortschrittsbalken mit der Windows-Explorer und Mp3tag-DB-Anzahl übereinstimmen?
Bei mir zeigt das Eigenschaftsfenster des Ordners exakt die gleiche Anzahl Dateien an wie MP3Tag in seiner Fortschrittsanzeige.
Hast Du die db3-Datenbank mit einem SQLite-Viewer durchleuchtet oder wie hast Du die DB-Anzahl festgestellt?
Was ich nicht weiß ist was Mp3Tag in seiner Datenbank mit Dupes oder Symlinks macht.
Mp3Tag war nie in der Lage mit Symlinks umzugehen, indem es sie als solche betrachtet sondern sieht immer nur das physische Ziel des Links.
Ich habe hier nicht den direkten Vergleich und habe es auch nicht überprüft, indem ich nacheinander zwischen verschiedene Versionen einen Zeitvergleich gemacht habe.
Mir fällt gefühlt halt kein störendes langsames Verhalten auf.
Der Unterschied wird wohl darin liegen, dass die Informationen nicht mehr komplett im RAM liegen sondern teilweise von der Festplatte kommen.
Ich vermute, dass hier meine SSD, auf der ja meine Datenbank liegt, das Verhalten so entscheidend beschleunigt, dass ich keine störende Verlangsamung feststellen kann.
Es ist wohl generell empfehlenswert, die Datenbank auf einer SSD zu haben.
Gratis-Tool ohne Installation: SQLiteSpy
https://www.yunqa.de/delphi/products/sqlitespy/index
Anzahl Dateien:
Entweder in SQLiteSpy auf die Tabelle mtfile doppelklicken oder
SELECT COUNT(id) FROM mtfile
ins rechte, obere SQL-Kommandofenster copy & pasten und F9 drücken.
@poster: Du hattest Recht mit der Datenbank auf SSD! Danke für den Hinweis!
Wenn ich die "mp3tag.db3" auf eine SSD speichere, dann ist der Wechsel von einer Zeile/Datei zur nächsten wieder gleich schnell wie in früheren Versionen. Anscheinend sind die einzelnen DB-Zugriffe auf einer herkömmlichen HDD deutlich langsamer.
Ich bitte @Florian deshalb, den Datenbank-Speicherort in den Optionen einstellbar zu machen. Z.B. unterhalb vom bereits wählbaren Pfad für Cover-Dateien im Eintrag "Verzeichnisse".
Sicherheitshalber die Frage an @Florian:
Ich nehme an, dass Mp3tag diese DB nicht für jede Datei erst öffnet, dann liest/schreibt und danach wieder schliesst?
In der aktuellen Version v2.85h ist die Datenbank jetzt unter "Optionen > Bibliothek" optional aktivierbar.
Wenn die Bibliothek aktiviert ist werden die Informationen in eine interne Datenbank geschrieben, die im Mp3tag Konfigurationsverzeichnis abgelegt ist. Den Speicherort werde ich nicht konfigurierbar machen. Falls Mp3tag auf einer anderen Festplatte speichern soll, kann es einfach mit der Portablen Installation dort installiert werden.
Beim ersten Einlesen werden die Metadaten aus den Dateien gelesen und in der Bibliothek abgelegt. Beim nächsten Einlesen werden die Metadaten dann aus der Bibliothek gelesen und ggf. aktualisiert, falls sich das Änderungsdatum der Datei verändert hat. Zusätzlich dazu, werden Album-Cover und andere Binärdaten ausschließlich in der Bibliothek gespeichert, was sich positiv auf den Speicherverbrauch auswirken kann.
Zusätzlich kann unter "Optionen > Bibliothek" die Verwendung der Datenbank auf einzelne Verzeichnisse eingeschränkt werden. Metadaten von Dateien die außerhalb dieser Verzeichnisse liegen, werden nicht permanent in der Bibliothek gespeichert.
Viele Grüße
— Florian
Es drängen sich mir noch die folgenden Fragen auf:
Löscht MP3tag die Einträge aus der Datenbank, wenn die Dateien nicht mehr da sind oder wächst und wächst die Datenbank?
Gibt es eine Art Hintergrund-Prozess, der die bestehenden Dateien aus dem zu "überwachenden" Ordner mit dem Inhalt der Datenbank abgleicht? Denn es ist ja durchaus möglich, dass in dem Ordner, der MP3tag genannt wird, Dateien hinzukommen oder entfernt werden.
Dies würde speziell für Sammlungen von z.B. Podcasts gelten, wo in regelmäßigen Abständen einzelne neue Dateien hinzukommen, die dann aber, weil zumindest die öffentlich-rechtlichen Erzeuger es nicht schaffen, eine einheitliche Benennung hinzukriegen, nachbearbeitet werden und in eigenen, anderen Ordnern landen. Nicht alle Schritte müssten unter der Kontrolle von MP3tag ablaufen.
Werden alle Dateien aufgenommen, die jemals mit MP3tag gelesen wurden? Also auch z.B. Bilddateien oder Cue-Files - egal, ob die dann der Tag-Bearbeitung unterliegen?
Kurz und gut: wie kann ich die Datenbank pflegen?
Ich werde sie alle paar Monate mal löschen. Sie wird ja dann wieder komplett neu aufgebaut.
Damit wäre dann der gewonnene Geschwindigkeitsvorteil wieder hinüber.
Oder ich beschränke mich dann doch auf die dynamischsten Verzeichnisse und lasse die Option mit der Datenbank für den Alltagsbetrieb ausgeschaltet.
Ob das allerdings aus Entwicklungssicht die ganzen Mühen mit zusätzlicher (Datenbank-) Schnittstelle (und damit Fehlerquelle) wert ist?
Ich habe 3 Gattungsordner in denen meine Dateien nach etlichen Bearbeitungsstufen landen. Und genau nur die sind in MP3Tag für die Datenbank konfiguriert.
Für die alltägliche Tagarbeit von neuem Material benötige ich keine Datenbank, weil die Anzahl der Dateien so gut wie nie die Zahl von 1000 überschreitet.
Um ab und an die große Sammlung zu bearbeiten und vor allem per Export auszuwerten ist es schon von Vorteil, dass die dann schnell eingelesen wird. Vor allem aber ist die Auslagerung der Cover nützlich, um mehr Platz im RAM zu haben. Und ein erneutes langsames Einlesen hat mich in der Vergangenheit besonders dann genervt, wenn MP3Tag z.B. wegen RAM-Mangels abgestürzt war.
Ab und an kann man wie ich schrieb auch die ganze Datenbank löschen und durch Einlesen frisch neu aufbauen lassen. Dass dafür der PC mal 1 Stunde braucht stört mich nicht wirklich, denn sowas macht man halt in einer ruhigen Stunde beim Kaffeetrinken nebenbei, wenn man ohnehin nicht arbeiten will.
Sie wächst dynamisch, ich plane jedoch eine Funktion zum Bereinigen der Datenbank im Optionen-Dialog einzubauen. Damit können dann bei Bedarf verwaiste Dateien aus der Bibliothek entfernt werden.
Für hinzugekommene Dateien passiert automatisch beim Einlesen des Verzeichnisses. Für außerhalb von Mp3tag entfernte Dateien kommt die Bereinigungsfunktion zum Einsatz.
Noch fehlen die Erfahrungswerte und ich glaube, dass das schon unter Fein-Tuning fällt. Die Verzeichnisse die eine hohe Fluktuation haben, können ja in den Bibliotheksoptionen nicht eingeschlossen werden.
Momentan ja, aber das kann sich noch ändern.
Im Idealfall musst Du sie nicht pflegen. Falls doch, kommt die Bereinigungsfunktion (oder die von poster vorgeschlagene Variante) zum Einsatz.
Viele Grüße
— Florian
Danke für die Klarstellungen.
Und schon ergibt sich die nächste Frage: wirkt die Angabe eines Ordners für die Datenbank dann wirklich nur auf genau den Ordner oder auch auf die Unterverzeichnisse?
Bzw.: wenn ich einen, sagen wir mal, "Sammelordner" habe, in dem ich die neuen Dateien sammele und aus dem sie dann nach Abschluss der ersten Bearbeitung verschoben werden, dann sollte der außerhalb des für die Datenbank angegebenen Dateibaums liegen, damit wegen der häufigen Änderungen die Datenbank nicht unnötig anschwillt?
Warum frage ich so skeptisch nach?
Ich habe Lösungen für Audio-Dateien in Form von itunes, foobar, kodi und wmp und Media Center gesehen, Lösungen für Bilddateien z.B. in Form von AcdSee und Adobe Produkten.
Ich verwende das Synctoy um größere Dateibäume (mit hunderttausenden von Dateien) zu synchronisieren - und immer dauert der Abgleich und produziert auch gerne mal größere CPU-Lasten und HDD-Auslastung sowieso.
Und bei allen ist die Bestandsaufnahme immer eine langwierige Angelegenheit, die eigentliche Pflege am Ende meist nur eine kurze Aktion. Aber ohne Pflege hat man binnen kurzem nur noch Datenschrott.
Der Nutzen ist allerdings ebenso unbestreitbar.
Die Anbindung einer Datenbank könnte meiner Ansicht nach noch ganz andere Optionen:
Verschiebung der Daten aus der mp3tag.cfg in die Datenbank und damit vielleicht Umsetzung die oft gewünschte leichtere Bearbeitung der Historienlisten für Filter und Konvertermasken.
Oder die Definitionen für Spalten mit unterschiedlichen Mengen von eingeblendeten Spalten als mehrere Konfigurationsinstanzen in der Datenbank, zwischen denen dann leicht hin- und hergeschaltet werden kann.
Und zu guter Letzt: die Duplikat-Suche. z.B. nach einem Export der Tag-Daten gibt es z.B. in Access ein vorgefertigtes Beispiel für eine (SQL-)Abfrage, die nach Duplikaten in den Access-Daten sucht. Wenn so eine Abfrage auch auf die Daten der MP3tag-Datenbank losgelassen werden könnte ...
Und für so eine Fortentwicklung sind starke Datenbankfunktionen ein solides Fundament.
Ich habe nach längerer Zeit mal wieder meinen kompletten Datenbestand einlesen müssen und stellte fest, dass dies sehr lange dauerte.
Zuletzt hatte ich hier in diesem Thread über die enormen Geschwindigkeitssteigerungen bei Benutzung des neuen Datenbankfeature berichtet:
Also habe ich nochmals meine Tests wiederholt. Inzwischen ist der getagte Bestand gewachsen und die MP3Tag-Datenbank ist auf 2,653 GB angewachsen (bereinigte Datenbank). Beim letzen Test waren es noch 2,293 GB.
Das Einlesen ohne Datenbank dauerte diesmal ca. 85 Minuten.
Mit bestückter und aktivierter Datenbank dauerte es genauso lange, was mich verblüfft und ratlos zurücklässt, denn beim letzten Test waren es ja nur 5:20 Minuten nach Neustart.
Meine Hardware ist unverändert. Die MP3s liegen nach wie vor auf einer klassischen internen SATA-Festplatte, Windows und das Profil mit dem APPPDATA-Ordner befinden sich auf einer SSD.
Mein Windows 10 ist inzwischen 2 Upgrades weiter: 1809 (Build 17763.168).
Wie sieht es bei anderen aus?
Was könnte diese radikale Veränderung bewirkt haben, denn anscheinend hat die Nutzung der MP3Tag-Datenbank bei mir überhaupt keine Auswirkung?
Ich habe die Tests auch wiederholt, nachdem ich die angelegte Datenbank gelöscht hatte. Es wurde eine neue angelegt - bei der Geschwindigkeit änderte sich nichts.
Veränderungen bei der Einlesegeschwindigkeit treten nur auf, wenn kein Neustart vorgenommen wird, also wohl Cache-Vorgänge Einfluss nehmen.
Das Einlesen ohne Datenbank dauerte diesmal ca. 85 Minuten .
Mit bestückter und aktivierter Datenbank dauerte es genauso lange
Wirklich keiner hier, der das gleiche Problem hat oder nach Test es ausdrücklich nicht hat?
Das Vorhandensein bzw. Aktivieren der Datenbank, das ja so eindrucksvoll das Laden großer Bestände gefördert hat, zeigt inzwischen keine Auswirkungen mehr bei mir. Es dauert ohne Datenbank genauso lang wie mit aktivierter Datenbank. Im Prozessexplorer kann ich jedoch sehen, dass MP3Tag auf die Datenbank zugreift.
Du erwartest jetzt nicht von jedem Forumsleser ein:
Nein, keine Veränderung 
, oder?
Bist Du sicher, dass das Windows-September-Update Dein %appdata% nicht wieder auf die langsame interne SATA verschoben oder geändert hat? Zeigt der Prozessexplorer als Pfadangabe wirklich auf Deine schnelle SSD?