I have 57k songs in my library. I have been able to load that in the past but now over the past 2 days Mp3tag gets to about 52k then crashes. Why does the software hold all in memory instead of paging and writing to the UI in chunks? I still have quite a bit of work to do on the lib and this is causing me pain.
Has anyone found a workaround?
I am running windows 10 with 8gb of RAM.
You have to preselect part of your files and cannot load all files.
You can use for this:
For using the advanced query syntax you have to include your music-folder(s) in the windows indexing.
If you've done so it gets very very fast.
https://msdn.microsoft.com/en-us/library/aa...1(v=vs.85).aspx
With this syntax you can filter on some music tags too.
What has changed during the last 2 days?
I would check the integrity of your system in respect to drive integrity (chkdsk).
Also, I would check the integrity of the newly added files and see if any corruption occurs in the files (e.g. mp3val or mp3diags).
Then I would try to load the files into MP3tag again.
Embedding just some additional covers can hit the limit.
The experence with my kind of mp3-files is, that the limit lies between 40-60.000 files. I am used to split by ca. 40.000-chunks to be on the safe side.
You are quite right: if nothing else helps - split it up.
Still I would assume that some 70000 files should be feasible, there are reports in the forum of more than 100,000 files. So 53,000 seems to be a little low. I would still recommend the other checks.
What has changed is additional metadata added to the files, as I am always working on the lib to get the tags correct.
I doubt there is any corruption, but I will run CHKDSK for grins.
It sounds like MP3tag has a limitation, and the lib needs to be split, which is another step to add to the process.
Thanks all!
There is no lib in Mp3Tag.
Just don't load not all files/folders.
yeah thats an option, of course, but thats not what I want to do. I am trying to rename my lib according to artist / album / track - it is much easier to do this on the whole lib than to select folders. Right now there are close to 2000 subfolders and since they cannot be multiselected it is very onerous.
I am trying a few more options, but even splitting the lib up into multiple directories is a task that is extremely time consuming.
It doesnt make sense to my why mp3tag would need to pull so much into memory.
Mp3tag offers much more features than a simple tagging application, and it has a built in transaction system, which allows the user to step back in the history of the last work steps.
This transaction subsystem needs machine memory too.
DD.20160126.1747.CET
There is no need tp split. You can mark as many of the directories you want and drag them into MP3Tag.
yeah this is what i'm doing. This is a good workaround. Thanks!
hello
i found out that for large bibs the artwork is causing memory failures.
I have copied my 10.000 files to another directory and removed the art work and the memeory consumption dropped with 75 % making mp3tag working fine again.
It's not a workaround, but maybe it gives the developers a clue how to handle
Similar situation: I get poor performance just playing tracks from a large (69k tracks) collection.
For playing, my directory structure is:
\Music
\MusicPart1
\Artist
\Album
\Album
\Artist
\Album
\Album
\MusicPart2
\Artist
\Album
To speed up player, I keep multiple logins in Windows which allows each login to have it's
separate library in WMP
MusicUser1
MusicUser2
.....
Each user gets pointed to it's own sub-directory. You may then include your music files classified by
genre, artist, or whatever you desire. I agree there is a memory leak issue editing large numbers
of files. I'm going to break down my library into additional smaller MusicPartX sub-parts to look for
a work-around. This will still accommodate the two users and two library files which is giving
OK playing performance.
The only short-coming is that this complicates finding duplicates from different sources and
standardizing and fixing different or bad tag data and/or accommodating different ripping software. This will
require exporting and loading into database software for identifying differences. Using custom
SQL queries and sorting, I can then go back to MP3Tag for correction.
My experience is that tag data from most online sources is, putting is nicely, very poor quality and needs
vast amounts of editing, which is why I depend on MP3Tag so heavily.