Same issue (2.94), enabling library causes very slow tagging (1 file/second).
mp3 files, small cover art. No other program uses the drive they are on. mp3tag and library database are on another (NVMe) drive.
4500 files loaded in mp3tag, 220 MB database size.
How do you know?
Have you checked the files for integrity?
On what kind of drive are the audio files? A NAS?
Yes, a NAS which does nothing else than storing files. Files integrity is OK (check with mp3val, no error).
In fact I just tried putting files on a RAM Disk. Tag reading is blazing fast, but tag writing is as slow (1 file/second) on RAM!!
I disabled library, same thing, so it seems it is not related to library.
If you have your files on a NAS then you get a maximum of 1 gigabit/second whereas the SATA bus allows up to 6 gigabyte/second or 48 gigabit/second. That is much faster than the speed of the network access.
So I would investigate along those lines: how to get a faster connection between program and data storage.
I told you: same issue with RAM Disk (3 GB/s throughput) so I believe it's not a disk access issue.
Leaves the problem of the simultaneous access.
There were reports of virus checkers that block access or slow it down considerably.
also, you might want to follow this thread:
So a few more tests:
I disabled Windows firewall and antivirus.
From RAM Disk (no NAS, no Disk access, only RAM).
Library feature disabled.
Reading an album tags: almost instantaneous
Writing tags: 1-2 files/s.
I think it is a CPU bottleneck: one core is 90-100% load under tag writing. Other cores do nothing.
CPU: Ryzen 7 2700X.
and that is strange: usually that is just a i/o-bus activity with hardly any CPU load.
I would still have a look at what's happening with ProcessExplorer (freeware at the time of this post). THis program would also reveal whether there is someone else interested in the files.
So, I see there's a 32 kb text tag (all track infos + base 64 image i guess, though i can't decode it) among the tags. After removing this tag, write speed is much faster (30 tracks/s) and CPU usage drops to almost 0 when writing.
So definitely some tag processing is CPU hungry.
If you still have the original which causes the increased CPU usage, I'd be interested to analyze the issue.
Thanks for the example file.
This should be significantly improved with the current beta version, Mp3tag v2.94a.
Yes, very good improvement, thanks for the fast update!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.