Saving files suddenly very very slow

To be clear, I’m talking only about the speed of saving files AFTER all the online stuff is done.

I’m running MB on an M.2 SSD where the input and output directories are on the same drive, so moving them should be blazing fast, but it’s happening more like one file per second, IF that. My SSD clocks at 1500MB/S.

Task manager shows the drive busy at 0% (idle) and CPU at 10-11%, essentially idle.

I’ve rebooted the system a couple of times for luck, no change.

What could be going on here? It wasn’t like this yesterday or the day before.

Hard to tell. Can you provide a debug log as explained on https://picard.musicbrainz.org/docs/troubleshooting/ ?

1 Like

Could it perhaps be related to this? :

3 Likes

I have it running with debug turned on, and experiencing the problem. Now the UI is grey, and I am saving files at a rate of about 1 per hour (guessing). If I ever regain control, I will pull the log and paste it here.

Something is definitively wrong. Hard to tell what with infos you provided til now.

1 Like

Sorry, but that’s all the info I have. It’s been an hour since I posted last and it’s still “saving” the same file.

What is the format of this file?
and its size?
Was it tagged before?
How long does it take if you copy the original file to the same target directory?

I don’t see how Picard (in fact mutagen) can be that slow on SSD.

1 Like

I can’t tell what file it’s working on everything is greyed out. The largest file in the dir is less than 17M

I gave up waiting.

I did discover that if I save the files in chunks while it’s working rather than waiting for it to be done, the saves are fast and I don’t get stuck.

There’s a dictum in IT support which unfortunately applies here: No log, no issue…

I suppose… How nice that the program hangs, preventing me from getting the log.

You might try starting Picard from the command line with the -d option, and redirect the stdin and stderr output to a file. That may give you something to work with, even if you end up having to interrupt the program. If you’re using Windows, there is some more information available in the documentation that I’ve been assembling.

I do see what Hiccup was talking about. If I select a batch of files to save, and save them, the progress is slow (but not glacial) until I click over on the left side, taking off the blue highlight on the right side, then it zips right along.

The slowdown is caused by an exponential number of checkings of the selected items during operations. The workaround works, but I’m working on a permanent fix for that. :slight_smile:

3 Likes

During saving? I don’t save till all the tagging etc is done.

Yup, it can happen in all sorts of operations (moving, clustering, lookup, saving).

You would be surprised by how much the UI can slow down the processing, but we’re working on that.

3 Likes