IPB

Welcome Guest ( Log In | Register )

> Hinweise!

Bitte vor dem erstellen eines Beitrag unbedingt den Beitrag Aktuelle Hinweise! lesen.

Lesen Sie auch die allgemeinen Nutzungsbestimmungen dieses Forums.

5 Pages V  « < 3 4 5  
Reply to this topicStart new topic
> mp3tag als 64 bit version, mp3tag als 64 bit version
Florian
post Dec 7 2017, 11:04
Post #61


Developer


Group: Admin
Posts: 8145
Joined: 12-December 01
From: Germany, Dresden
Member No.: 203
Mp3tag Version: 2.85h



QUOTE (poster @ Dec 7 2017, 10:28) *
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.

Mit der v2.85c sollte jetzt vieles besser funktionieren. Das Umbenennen von Verzeichnissen hat denke ich zu den meisten Problemen geführt.

QUOTE (LyricsLover @ Dec 7 2017, 10:52) *
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

sad.gif

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).


--------------------
♫ If you like using Mp3tag please donate to support further development.

Go to the top of the page
 
+Quote Post
poster
post Dec 7 2017, 11:54
Post #62


Member


Group: Full Members
Posts: 1476
Joined: 22-March 09
Member No.: 9241
Mp3tag Version: 2.85h



ZITAT(LyricsLover @ Dec 6 2017, 21:06) *
Sorry wegen Deinen aktuellen Problemen!Was meinst Du mit "ständig verändert"? Bei mir gibt es nur zwei Speicherorte

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:

1. 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.

2. 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.

3. 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. smile.gif
Go to the top of the page
 
+Quote Post
poster
post Dec 7 2017, 12:04
Post #63


Member


Group: Full Members
Posts: 1476
Joined: 22-March 09
Member No.: 9241
Mp3tag Version: 2.85h



ZITAT(LyricsLover @ Dec 7 2017, 10:52) *
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?

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.

ZITAT
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?

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.
Go to the top of the page
 
+Quote Post
poster
post Dec 7 2017, 13:33
Post #64


Member


Group: Full Members
Posts: 1476
Joined: 22-March 09
Member No.: 9241
Mp3tag Version: 2.85h



ZITAT
2.85c (2017-12-07)
FIX: actions that caused a directory to be renamed did not update the database entries (since 2.85b).

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.
https://forums.mp3tag.de/index.php?showtopi...umartdownloader

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.
Go to the top of the page
 
+Quote Post
LyricsLover
post Dec 7 2017, 13:59
Post #65


Member


Group: Full Members
Posts: 917
Joined: 21-September 06
From: Central Europe
Member No.: 3709
Mp3tag Version: 2.85h



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

This post has been edited by LyricsLover: Dec 7 2017, 14:03
Go to the top of the page
 
+Quote Post
LyricsLover
post Dec 7 2017, 14:11
Post #66


Member


Group: Full Members
Posts: 917
Joined: 21-September 06
From: Central Europe
Member No.: 3709
Mp3tag Version: 2.85h



ZITAT(poster @ Dec 7 2017, 12:04) *
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.
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?
Go to the top of the page
 
+Quote Post
poster
post Dec 7 2017, 15:17
Post #67


Member


Group: Full Members
Posts: 1476
Joined: 22-March 09
Member No.: 9241
Mp3tag Version: 2.85h



ZITAT(LyricsLover @ Dec 7 2017, 14:11) *
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.

Go to the top of the page
 
+Quote Post
poster
post Dec 7 2017, 15:45
Post #68


Member


Group: Full Members
Posts: 1476
Joined: 22-March 09
Member No.: 9241
Mp3tag Version: 2.85h



ZITAT(LyricsLover @ Dec 7 2017, 13:59) *
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

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.
Go to the top of the page
 
+Quote Post
LyricsLover
post Dec 7 2017, 17:32
Post #69


Member


Group: Full Members
Posts: 917
Joined: 21-September 06
From: Central Europe
Member No.: 3709
Mp3tag Version: 2.85h



ZITAT(poster @ Dec 7 2017, 15:17) *
Hast Du die db3-Datenbank mit einem SQLite-Viewer durchleuchtet oder wie hast Du die DB-Anzahl festgestellt?

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.

This post has been edited by LyricsLover: Dec 7 2017, 17:35
Go to the top of the page
 
+Quote Post
LyricsLover
post Dec 8 2017, 09:29
Post #70


Member


Group: Full Members
Posts: 917
Joined: 21-September 06
From: Central Europe
Member No.: 3709
Mp3tag Version: 2.85h



@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?
Go to the top of the page
 
+Quote Post

5 Pages V  « < 3 4 5
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 14th December 2017 - 11:26