I have been noticing sluggish performance on this last build and it has gotten progressively worse. I do not see others reporting this, so maybe it has to do with my system, but other programs are not exhibiting the same "sluggishness."
Basically, when I select a tract to work on it, the track highlights and everything pauses for 3-4 seconds before I can work on any field. If I click on any field during this time, nothing happens. Once this 3-4 second pause happens, I can jump to any field and they are active to be edited immediately. Changes are recorded instantly. Once I make my changes and hit save, I experience another 3-4 second delay before my changes are saved. Even jumping from one track to another by clicking them will exhibit a delay. I also have noticed that there is a 2-3 second delay before the songs play, if I double click them. Lastly, scrolling has slowed to a crawl.
The files I am working with are on a Nvme SSD (SN850 Black); however there are files in my data set that reside in a external SSD, connected to an USB 3.2 port, but this has never caused a slow down before. My main drive is also an Nvme. I still have headroom on memory and cpu. Neither are even close to maxed out on the performance monitor.
Any ideas on what may be happening or how I can improve performance?
Thanks! I already had an exclusion for Mp3Tag and I even added another with the extension, as advised in the thread but unfortunately the sluggish behavior remains. This began about a month ago, so I would doubt it would be due to Defender, but I still am willing to try anything to get things working smoother.
I even turned defender off and the behavior remained.
I find at least 15 threads dealing with alleged slow reading of files.
So if you use the search words "slow reading" you may find threads that inspire you.
I am at the current version 3.19, and actually find the performance is noticeably faster than the previous versions. Especially loading with the library turned on, I can be up and running with all 25k songs in just a few seconds. And no lag when selecting individual files.
Just to be sure that Mp3tag is the (only) reason:
If you go back to a previous version of Mp3tag, can you confirm that an older version works without a 3-4 second pause?
I'm not sure about the reliability of this website, but they list different older versions:
I too had noticed that the present version was fast. I really don’t know what changed. I will see if I can downgrade and if that makes any difference. I will also check other threads and see if I can find a different solution.
Downgraded to 3.18. No improvement. I removed all files from the external SSD and only had MP3Tag deal with files residing in a Nvme which is directly attached to the MOBO with an M.2 slot. I still get the long delays when choosing files and stuttering scroll. This is with only 7300 files. Something is up. I will continue investigating and report back.
I do use the library and it uses the external SSD. I have not tried to rebuild it, but may do so. I did install Malwarebytes and when I closed the virus security of Windows, I got a message saying I had to restart the computer, so I am not sure if the exception for mp3Tag, with the .exe extension was actually in effect when the sluggishness persisted.
Anyhow, the problem seems to be alleviated somewhat. I have to do some further investigation, by turning off Malwarebytes and reactivating defender, to see if defender was the cause of the problem, which I suspect it was. I am not sure why it started becoming a problem only recently, but hopefully I can determine that as well.
Well, it seems as it was NOT defender because the problem persists with Malwarebytes. I cleaned up the library as well. I am now back with Defender. I completely turned off defender (and checked it was still off) and the sluggish performance remains. A bunch of spinning balls when I save or click on a different file. Worst thing is that I see nothing maxed out in the process explorer. I cannot figure out what is causing these pauses. I am using Light Room and Photoshop and they do not to be affected.
Any ideas on what I can use (event viewer etc) to try to find out the source of the issue. I am going to install MP3Tag on another computer and use the external SSD to determine if it is the environment.
I don't think that it is the external SSD because you wrote that you see this behaviour also with an internal SSD. Or am I wrong?
Anyway:
There is an important thing with external SSDs. A lot of them are not able to trim and therefore get slower over the time. It is important that you select a drive or a SSD-case with a controller that has the UASP-feature and supports trim. To check whether your external drive uses trim can be checket with trimcheck.
I had the phenomenon you describe some time ago with Mp3Tag. However, it wasn't persistent and disappeared after restarting Windows. If the Windows standard setting "Fast Boot" has not been deactivated by the user, a real restart is required and not a shutdown followed by a reboot.
Thanks poster! I will definitely check up on this. I did move all my files onto the SSD and tested the setup with a laptop and it seems the problem has to do with my main computer. The laptop performed much better. Scrolling is still slow, but not abnormally so. Now I have to figure out what the heck is going on with this computer. I am up for an upgrade...
Update: I upgraded to a super computer, i9-13700k, 128 gb of RAM, SSDs everywhere and things are definitely snappier. Still wish scrolling and importing of songs into the program was faster but other than that, things move quickly.
Couldn't you supply some real benchmarks?
Like: how long does it (really) take to read the file?
I just tried to read some 200.000 files from an external USB3.0 HDD and it took
10 minutes, 55 seconds
if MP3tag resides on the same external drive
8 minutes, 59 seonds
if MP3tag resides on the internal SSD.
It becomes
6 minutes 43 seconds
if MP3tag resides on an internal SSD and the data also on an internal HDD.
It looks to me like you can expect to read some 20.000 files/minute.
I will try to do some benchmarking asap, but your numbers seem accurate. A rough estimate of my last startup containing 86695 files loaded in 7 min 58 secs (I started timing at 13K after about 45 secs of uploading). This is using an NVMe (Samsung 990 Pro) for my main OS drive and an external SSD (WD Blue) using a USB 3.2 gen 2 connection, which will not throotle the speed of the ssd.
The thrust of my last post was just to report that things were better with my new build, but I will try to assess what you asked more accurately. I did time the last 20K files, using the lap feature on my timer, and that took 2 min and 14 seconds. So it looks like my set up takes twice as long to load files than your assessment.
I forgot: even though I use the 64-bit-version I still have the library switched on.
Also, I would like to point out that I got these benchmarks on no high-performance systems.
I used a plain SSD (no NVMe), a (slow) laptop processor, an ordinary USB3.0 connection to an ordinary HDD.
But the library was swtiched on ... perhaps that makes the difference.
51'857 tracks on a Samsung EVO 850 SSD:
Mp3tag on a NVMe SSD, Mp3tag library deleted, PC rebooted.
The first read of this 51'857 tracks takes 125 seconds.
This is about 414 tracks per second or 24'891 tracks per minute.
The direct re-read of this 51'857 tracks (with still enabled library) needs just 18 seconds.
(I assume some kind of caching is involved).
The re-read of this 51'857 tracks after a PC reboot takes 30 seconds with enabled library.
This is about 1'728 tracks per second or would be (extrapolated) 103'714 tracks per minute.
