Dann liegt das langsame Einlesen wohl wirklich an Deiner per Netzwerk angebundenen Datenquelle.
Bei mir ist es von der internen Festplatte (MP3s gelesen auf einer internen Festplatte, Cover gespeichert auf einer SSD) um den Faktor 3 schneller.
Dass das Sortieren der Spalten durch MP3Tag etliche Sekunden dauert ist bei einem so großen Datenbestand im RAM klar. MP3Tag zeigt dann auch immer "Keine Rückmeldung" und man muss halt einfach abwarten.
Nachdem ich mit verschiedenen Möglichkeiten die Einlesegeschwindigkeit gemessen habe (Firewall ein/aus, Virenscanner ein/aus, symbolischer Link auf NAS, Daten auf direkt angeschlossener USB 3.0-Platte) komme ich für meine Datenmenge zum Schluss:
Das funktioniert leider nicht.
Weder für eine brauchbare Teilmenge, geschweige denn für meine Komplettsammlung.
Die "schnellste" Variante ist das Einlesen der identischen Daten von einer USB 3.0-Festplatte. Da kann ich rund 173'000 mp3 einlesen (erstellt 12'910 Dateien im \covers Verzeichnis in 65 Minuten), dann knallt Mp3tag. Stürzt ohne irgendwelche Angabe von Gründen ab. Man sieht nicht mal mehr einen Eintrag im Taskmanager.
Das Mp3tagError.log zeigt leider keinerlei Zeitangaben oder weiterführende Absturzgründe.
Erstaunlich sind auch die Einträge wie z.B.
File: smp3file2.cpp
Line: 1636
Message: read: bad allocation
(M:\mp3\B\BOB DYLAN\Highway 61 Revisited\1965\06 - Queen Jane Approximately.mp3)
00001AD4
All diese Einträge werden beim Einlesen nicht sichtbar dargestellt.
Das wars erstmal von mir.
Ich hoffe wenigstens, Florian liest mit (auch wenn er sich nicht dazu äussert).
Wie bereits gestern gesagt:
Für "kleinere" Datensammlungen oder die Verwendung pro Album funktioniert Mp3tag einwandfrei.
Für grössere Datensammlungen bleibt Mp3tag "by design" praktisch unbrauchbar. Workarounds mit kleineren Teilmengen und sich stupide wiederholenden Arbeitsabläufen sind IMHO Zeitverschwendung. Schade.
Damit ich nicht nur als Meckerer und Miesmacher rüberkomme, stelle ich mich selbstverständlich für Pre-Beta-Tests mit meiner Sammlung zur Verfügung. Eine PN reicht.
Nein? Ich glaube ich sehe eine morgana fata...
Temporär aufgebaut oder permanent mit aktualisierung (div vom dateisystem)?
Ich dachte jetzt schon eher an eine permanente Datenbank, die aber dynamisch aufgebaut wird. Sobald Dateien einmal eingelesen wurden, werden sie dann aus der Datenbank geladen.
Damit wäre ein wesentlich schnelleres Einlesen auch über einzelne Mp3tag-Sessions hinweg gegeben 
Eine Frage als relativer Laie:
Wie werden denn Veränderungen in den Tags, Verschieben von Files in andere Ordner, Löschen von Files usw. denn mit der Datenbank zuverlässig abgeglichen.
Ich stelle immer wieder fest, dass das bei Software, die ich nutze, manchmal nicht 100% funktioniert.
So nutze ich z.B. den hier schon zitierten Mediamonkey nur noch um auf Lyricssuche mit dem Lyricator-Script zu gehen. Das bedeutet, dass ich eigentlich die Datenbank ständig lösche und neue Files immer neu einlese. Tue ich das nicht und sage ihm nur, dass er den Dateien des Ordner xyp einlesen/aktualisieren soll, klappt das eben nicht jedesmal. Manchmal meldet er, dass bestimmte Dateien nicht mehr da sind, manchmal merkt er es gar nicht.
Hoffentlich findet Florian für Mp3tag eine zuverlässigere Lösung, als z.B. MediaMonkey.
In der Theorie ist das eigentlich nicht so schwierig. Man merkt sich z.B. pro eingelesem File dessen Attribute (erstellt, gespeichert, verändert-Datum). Sind diese Werte beim nächsten Zugriff nicht mehr identisch, müssen die Tags und Attribute neu eingelesen werden.
Noch genauer ist der Check mit einer Prüfsumme (CRC, md5, SHA...). Da reicht schon 1 geändertes Bit für die Erkennung einer Veränderung aus. Die Berechnung von Prüfsummen wird aber je nach Methode bei x-hunderttausend Dateien ziemlich zeitaufwändig.
Nicht mehr vorhandene Files würde ich anzeigen und zum Löschen vorschlagen. Verschobene Dateien zu finden ist auch wieder zeitaufwändig. In MM lösche ich die ebenfalls und lese die Verzeichnisse neu ein.
Bin also auch gespannt, wie das in Mp3tag gelöst wird. Der PrintScreen lässt schon mal grosse Hoffnung aufkommen.
Meine Liste ist natürlich noch etwas länger geworden (Cover, Binär-Daten, Änderungserkennung, Tests, ...) und ich hab recht viel umgebaut.
Im aktuellen Development Build Mp3tag v2.85b verwendet Mp3tag eine Datenbank zum Einlesen der Dateien. Folgendes Verhalten ist vorgesehen:
Viele Grüße
— Florian
Ist nicht gerade mein persönliches Problem, denn ich verändere mit jeder Änderung der Tags auch das Änderungsdatum, weil ich anhand dessen 2 verschiedene Lokalitäten synchronisiere.
Aus dem Forum weiß ich aber, dass wohl die Option "Zeitstempel bei Dateien beibehalten" von einigen genutzt wird.
@Florian: Danke schon mal vorweg, dass Du Dich diesem Problem annimmst. Die v2.85b läuft schon und liest nun mal die nächsten Stunden mp3 ein.
Verrätst Du uns bitte, unter welchem Namen in welchem Verzeichnis Du die DB speicherst?
Solange man Veränderungen innerhalb Mp3tag vornimmt, bekommt Mp3tag das ohnehin mit. Es geht vermutlich mehr um Änderungen die ausserhalb von Mp3tag gemacht werden (z.B. mit MediaMonkey, FooBar etc). Wenn diese externen Änderungen den Zeitstempel auch nicht verändern (dürfen), wird die Erkennung weniger offensichtlich und sowas wie Prüfsummen werden nötig.
%appdata%\Mp3tag\data\library\mp3tag.db3
Wahrscheinlich wirst Du auch damit wieder in die von Dir beobachteten Einschränkungen laufen, die Du auch mit der v2.85a hattest. Der Speicherverbrauch hat sich zwischen v2.85a und v2.85b denke ich nicht signifikant geändert — aber wir werden sehen
Genau dort. Es ist eine SQLite3 Datenbank, die mit einem geeigneten Tool auch extern von Mp3tag eingesehen werden kann. Ich bitte euch nur nichts darin zu verändern, das wird sonst schwierig.
Prüfsummen versuche ich zu vermeiden — damit wäre wieder Einlesen pro Datei und die Generierung der Prüfsumme nötig, was den Geschwindigkeitsvorteil wieder wesentlich kleiner machen würde.
Viele Grüße
— Florian
Ich konnte nicht warten, bis Mp3tag das Speicherlimit erreicht und habe deshalb erstmal nur meine Sonderzeichen-, Zahlen- und das \A-Verzeichnis eingelesen.
Das Positive und wirklich Erfreuliche zuerst:
Mein zweiter Einlesevorgang dauert für 106'329 Dateien gerade mal noch 6½ Minuten! (Das effektive Hochzählen und die Anzeige des Fortschrittsbalkens beginnt erst nach 75 Sekunden).
Diese 6½ Minuten beurteile ich im Vergleich zur Version 2.85a als extrem kurze Einlesezeit, was mich ebenso extrem freut. Diese Zeit hätte ich aufgrund meiner "langsamen" Netzwerk- und NAS-Festplatten-Geschwindigkeit niemals erwartet. Chapeau, Florian!
(Ich bin gespannt, wie sich das bei Benutzern mit sehr viel schnellerem, lokalen SSD-Speicher verhält. @poster???)
Die Datenbank wird 1.25 GB gross, der Arbeits-Speicherbedarf von Mp3tag liegt bei 1.18GB.
Damit kann man auch den unverändert langsamen, allerersten Einlesevorgang in die Datenbank relativieren, weil dieser für die allergrösste Dateimenge nur noch einmalig nötig ist.
Folgende Ungereimtheit fiel mir auf
(ich bin aber nicht sicher, ob sie wirklich mit 2.85b zu tun hat)
Wenn ich in der Liste innerhalb von Mp3tag von einem Stück zum anderen fahre (Cursor rauf/runter), spürt man eine kurze Verzögerung von einem Bruchteil einer Sekunde.
Gefühlsmässig behaupte ich, vorher konnte ich auf der Cursortaste stehen bleiben und die markierten Zeilen huschten schneller vorbei.
Ich vermute, die Differenz resultiert aus der Zeit, in der das Cover eingelesen wird? Oder hat sich da gar nichts verändert und mir fällt das nur auf, weil die Stücke in diesem Fall direkt von meinem NAS kommen?
Ich teste nun noch weiter 
wie sich die Geschwindigkeiten beim Filtern und Sortieren verhalten und melde mich später wieder.
Eine halbe Stunde später:
Die getesteten Zeiten mit obigen 106'329 Dateien:
Spalten-Sortierung: Pro Spalte jeweils rund 12 Sekunden, egal welche Spalte man anklickt.
Filter: Rund 6 Sekunden für einfache Textabfragen, egal, wie gross die Anzahl gefilterter Dateien ist
Filter: Komplizertere Regex können schon mal 10-14 Sekunden dauern
Bei der Sortierung und der Filterbenutzung schnellt nur 1 von 8 Prozessor-Kernen in die Höhe.
Soweit bin ich noch gar nicht, dass ich versucht habe, meinen Gesamtbestand einzulesen. Außerdem lese ich ja von einer lokalen internen Festplatte ein und auf der SSD landet nur die Datenbank.
Ich hatte gerade produktive Tag-Arbeit zu tun und das geht im Moment komplett mit der 2.85b schief, denn ich handele mir ständig Ausnahmefehler und andere Fehlermedungen ein, nach denen MP3Tag teilweise nicht mehr bedienbar ist und anschließend durch den Taskmanager aus dem Speicher katapultiert werden muss. Teilweise ist MP3Tag dann zunächst gar nicht im Taskmanager und taucht erst nach einiger Zeit dort auf.
Im Prinzip bricht bei meinem üblichen Workflow das totale Chaos aus und ich hatte noch nicht den Nerv, die auftretenden Probleme konsequent zu durchleuchten.
Ich schildere mal gerade meinen üblichen Workflow:
Mir scheint, dass das Bearbeiten durch Aktionen und das Verschieben des Albums mit den einzelnen Files, die während meiner Bearbeitung ja starker Veränderung unterliegen (Größe, Tags usw.) irgendwie mit Infos in der Datenbank kollidiert. Selbst das Verschieben mit dem Windows-Move-Befehl innerhalb MP3Tag führt zu einer Fehlermeldung. Wie gesagt, hatte ich noch nicht den Nerv, alles systematisch zu durchleuchten.
Hier ein Protokollauszug und in der Anlage Fehlermeldungen.
File: mtmainframeupdatehandlers.cpp
Line: 98
Message: Error: Size of file D:\MP3s\1\Edwin Holt\Second Time Around\11 - Edwin Holt - Right Reverend of the Blues.mp3 is reported as 13511232676757553 from the system
00001B2C at 23:52:38.120414
--------------------------------------------------------------------------------
In dem Zusammenhang interessiert mich was MP3Tag bei solchen Verschiebeaktionen eigentlich macht:
Wird die Örtlichkeit in der Datenbank ständig "umgebucht"?
Kümmert sich die Datenbank überhaupt um den Speicherort?
Werden die Files doppelt und dreifach in die Datenbank aufgenommen?
Wenn man mit MP3Tag arbeitet ist ja wohl bei den meisten Usern der Speicherort der Datei ständig verändert und damit einhergehend die Tags und der Dateinamen.
Sorry wegen Deinen aktuellen Problemen!
Was meinst Du mit "ständig verändert"? Bei mir gibt es nur zwei Speicherorte:
a) Ein Quell-Laufwerk, wo alle noch nicht getaggten mp3 drin sind (mit Verzeichnisstruktur pro Album)
b ) Ein Ziel-Laufwerk, worin alle fertigen mp3 verschoben werden (mit Verzeichnisstruktur pro Interpret, Album und Jahr)
Der einzelne Dateiname wechselt dabei genau 1 x, nämlich von alt auf neu.
Auch die Tags wechseln nur 1 x, von chaotisch auf möglichst nahe an meine Wunschvorstellung.
Deshalb meine Frage: Was meinst Du mit "ständig verändert"?
FYI,
ich hab den Download-Link für den aktuellen Development Build jetzt entfernt und werde versuchen, die Probleme zu identifizieren und natürlich zu lösen. Ich war tatsächlich recht optimistisch, aber anscheinend sind meine Tests noch nicht ausreichend.
Wegen dem Umbenennen: die Örtlichkeit wird in der Datenbank umgebucht, allerdings — soweit ich das jetzt sehen kann — in dem Fall der Aktion "Format Value" für _DIRECTORY nicht, was zu Problemen führt.
Viele Grüße
— Florian
Und: Danke für euer Feedback! 
Wenn ihr einen Fehler findet, dann nur her damit.
Viele Grüße
— Florian
Nachdem ich reichlich damit beschäftigt war, auftretende Probleme bei der Arbeit mit der Version 2.85b zu diagnostizieren, reiche ich mal meinen heute durchgeführten Geschwindigkeitstest mit dem Einlesen meines Alben-Ordners nach.
Konstellation:
Der Ordner Alben liegt auf einer internen per SATA-3 (6 G) angeschlossenen normalen Festplatte. Die Datenbank von Mp3Tag liegt auf einer an die SATA-3-Schnittstellen angeschlossenen SSD. Nach dem ersten Einlesen durch MP3Tag erfolgen also weitere Einlesungen der Tags ausschließlich von der SSD.
Meine Zeitangaben beziehen sich auf die Zeit zwischen Betätigung des Buttons zum Laden und das Anzeigen der gelesenen Tags in MP3Tag, beziehen sich also nicht nur auf das Einlesen der Tags.
Einlesen:
Dauer: 36 Minuten
MP3Tag-Speicherbelegung entsprechend Taskmanger: 1,351 GB
Datenbankgröße: 2,293 GB
Einlesen bei schon bestückter Datenbank:
Dauer: 3:45 Minuten
Da ich bemerkt habe, dass MP3Tag schon immer ein unmittelbar erfolgtes neues Einlesen eines Ordners etwas schneller erledigte (Cache ?), habe ich den PC neu gestartet und das Einlesen wiederholt.
Bei den Versuchen ist festzustellen, dass bei Nutzung einer SSD als Speicherort für die Datenbank die meiste Zeit auf das Registrieren der Files im Ordner der Festplatte fällt, wenn die Files einmal eingelesen sind. Das Einlesen der Tags aus der Datenbank geht dann sehr schnell.
Das konnte ich bei mir (zumindest gefühlsmäßig) nicht feststellen.
Das ist leider so. Bei rund 1.82GB verwendetem Arbeitsspeicher (seltsamer Wert) ist Schluss für Mp3tag: "Not enough memory available to complete the operation" -> Crash
Was dabei auffällt: Die Fortschrittsanzeige von Mp3tag zeigt 173'604 Dateien an, eingelesen in die DB wurden aber nur 108'338. Was passierte mit den restlichen 65'000 Dateien? Im Errorlog finde ich nur 1'195 "read: bad allocation" Einträge.
@Florian:
Siehst Du eine Möglichkeit, das erstmalige Einlesen in die DB "unabhängig" vom Speicherbedarf von Mp3tag zu lösen? Ich denke da z.B. an einen Kommandozeilen-Import ohne GUI-Anzeige und ohne direkte Bearbeitungsmöglichkeit.
Siehst Du eine Möglichkeit, den Arbeitsspeicher-Bedarf von Mp3tag laufend zu prüfen und bei rund 1.8GB weiteres Einlesen zu stoppen OHNE dass Mp3tag crashed?
Siehst Du eine Möglichkeit, das Mp3tagError.log ein wenig aussagekräftiger zu gestalten, z.B. welche Dateien wurden gar nicht eingelesen? Oder wie wäre es, mehrere Logfiles zu generieren, damit man diese entsprechend nach Fehlertyp abarbeiten kann?
Kannst Du vielleicht auch die Fehler selber aussagekräftiger schreiben? Was bedeutet z.B. "Error: Size of file...is reported as -9177729065054754806 from the system"?
Oder "read: ID3v2 tag parse error" (Welcher Tag? Frame?)
Oder "read: Invalid path syntax" (Was ist ungültig? Länge? Zeichen?)
Sind all diese aufgelisteten Daten doch eingelesen worden oder nicht?
