I see that the library file mp3tag.db3 is 1.7 GB! Why is this file so gigantic in size and is there a way to reduce it?
There is a function to clean up the library.
The principle size depends on the number of managed files.
So I see as the only way to reduce the size (after the clean-up): manage fewer files.
How many files to you load if you want to see your entire collection?
Are these mp3 files?
If you believe that this library is too big, you could just delete it.
It will be rebuilded if you load your tracks into Mp3tag again.
Please be aware:
Your first loading process after deleting the library will be MUCH SLOWER than you are used to, because all the details from your tracks must be read and stored in the database again - for every track.
For those interested:
mp3tag.db3 is currently 4,1 GB and I think that it does not include my complete collection.
looking at @Casual_Tea
I think I've only tried to use the library function once, quite some time ago. Over samba it took ages to scan and did not finish at all due to some error.
These days I simply copy a subset of files that I want to edit to a local m2 ssd, perform the changes I want and then copy the files back. To ensure data integrity I always copy with tools like FastCopy (if I want maximum speed) or TeraCopy (bit slower but replaces the default drag & drop on my pc so it's more convenient) with verification enabled in both. That means files are not only copied but the copy is then read out again and compared against the original via checksum to ensure they are identical.
How long did the scan take to reach that size and did you scan files that were connected locally to your PC or shared over the network (and if so, 1GBit/s or 10GBit/s and which protocol? SMB/NFS)?
I feel so tiny in comparison. My little db file is "only" 986MB for about 26k files. I haven't tried to clean that up though.
Good thing I haven't tried it recently then. If the db size scales linearly with file count my db would take up a bit over 32GB and my OS partition only has 25GB free haha. The same reason forced me to disable caching of artwork in tinymediamanager for my movie and tv show collection. The cache folder (even downscaled to 1000px) flooded my windows partition.
Interesting topic. I'm assuming since I don't use the Library function, I don't have the .db3 file (quick check... couldn't find one).
My laptop has two internal SSD drives. Nothing takes long to load. I just checked, my largest folder [Grateful Dead, 104GB, 7900 files] only took 18 seconds to load. My typical load time, for most actions, is less than a second.
Here is another thread about various performance times:
Interesting. I've added mp3tag.exe as an exclusion in windows defender to see if that affects the loading speed of files in mp3tag, however I didn't notice a major difference.
Thanks to this idea I loaded my Grateful Dead collection as well and timed it.
It took 3 minutes and 46 seconds over a 10GBit/s connection to the file server, where the music resides on a 8 disk wide z2 ZFS pool of 8TB hdds (as max performance I usually get 500-700MByte/s sequential during extended transfers of a couple hundred GBs).
The network load of my PC during the scan was inconsistent 10-250MBit/s. CPU load was 3-4%.
Edit: Forgot to mention that I used a samba share to mount the music.
So... I loaded my Dead folder again. First observation, it loaded this time in 5.5 seconds. I didn't think there would be much improvement from caching because it's an SSD, but clearly there is!
My Dead folder is 41 days, 55 minutes, so twice the playing time, but 2/3 the size. I'll venture a guess yours is FLAC. Mine is all MP3. With my hearing, there is no discernible difference (my hearing sucks).
Since I've already violated every rule of staying on-topic, might as well double down. Do you have Dave's Picks 49 yet?
Yup, I try to only collect flac. Mp3s only make their way into my collection if I have no other choice.
It's not in the main collection yet, but my father has already downloaded it in flac, so yes. Unfortunately he loves downloading stuff and hates editing metadata. Thus he has multiple TBs of unprocessed music.
And to stay a bit on topic:
My server also caches, loading the Grateful Dead folders again took 1 minute and 20 seconds the second time with a pretty much sustained network load of 200MBit/s.