Is it normal for "Loading album information" to take 1-2 minutes for a single track?

I’ve been redoing my entire music collection with Picard and I’ve now done most of the CDs where I ripped the whole album. But now I am mostly left with single tracks left to do (of which there are many).

Some tracks I get lucky and they take only seconds to look up. But most tracks are at least 30 second look up times and many times it’s 1min 30sec+

I didn’t really notice it doing the albums because I just assumed that it was normal to take longer looking up a whole album. Even then though, a large multi disc album could take 10 seconds while a small EP could take more than a minute which I thought was weird.

When I’m needing to tag hundreds of albums and thousands of tracks, it’s making the whole process incredibly slow.

It’s especially egregious when it fetches the wrong album, making one song take more than 5 minutes from dropping in to finally saving (some songs can take upwards of 15 minutes because it will repeatedly fail to load and then be the wrong album, etc.).

I’m on gigabit internet on a fast machine so it’s not either of those things. I even accidentally completely reset Picard after a forgot to back up the config switching to a different Linux distro.

I’ve tried disabling plugins but it makes zero difference. Even songs that I’ve previously tagged and redo (because I made a mistake or changed my naming script) can take longer than expected to load.

EDIT:
Operating System: Artix Linux
KDE Plasma Version: 6.6.5
KDE Frameworks Version: 6.26.0
Qt Version: 6.11.1
Kernel Version: 7.0.10-artix1-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 5600XT 6-Core Processor
Memory: 32 GiB of RAM (31.2 GiB usable)
Graphics Processor: AMD Radeon RX 6800 XT

Picard Version 2.13.3

Python 3.14.5, PyQt 5.15.11, Qt 5.15.19, Mutagen 1.47.0, Discid discid 1.4.0, libdiscid 0.6.5, astrcmp C, SSL OpenSSL 3.6.2 7 Apr 2026

Some days are worse than others. Depends on the server load.

Some days it is just easier to give up and try a different day.

Also, big tip, do your initial lookups without artwork download. I always do lookups with artwork disabled. Nothing worse that waiting 20mins to download some huge 20MB PNG file only to work out it is the wrong release selected anyway.

Do the detection stages without artwork. Then once everything is ID’d, return another time and turn on artwork and do a fresh lookup. Now you are safe to know that the only artwork coming down is correct and you can walk away and leave Picard to it. Safe in knowing you don’t need to do any other checking.

1 Like

Unfortunately it makes no difference what day or time of day I try. I’ve been working on my collection over the last year and it’s been this slow the whole time, every day, any time :confused:

I’ll give disabling cover art a go (although it’s already very restricted - only front cover, one source and limited to 500px).

How many tracks are you loading up? Can you do them in smaller batches?

Personally I rarely load more than a few dozen tracks at a time.

Debug logs might give hints. The problem could also be anywhere between your network and MB servers. Is the MB website working fine?

2 Likes

You can enable debug and check logs: General Troubleshooting — MusicBrainz Picard v3.0 documentation

Also, when reporting an issue here, please indicate which Picard version, your OS, and related releases.

How many tracks are you loading up?

One at a time. It’s either a whole album or a single track. I’ve rarely done more than a few tracks a time (I learned the hard way when I was first trying out Picard, not to add a folder of 900+ tracks to tag lol)

Is the MB website working fine?

Yep, works no problem. The only time I get any slowness on the website is occasionally when going to cover art.

I’ll check out the debug while doing some testing and post the results back here.

Also, when reporting an issue here, please indicate which Picard version, your OS, and related releases.

Apologies! I meant to do that but was tired, had a brainfart and forgot to include it after writing out the issue. Fixed my op to include that.

If I understand correctly, maybe you are hitting a rate limit on Picard’s use of the MusicBrainz lookup interface. MusicBrainz wants us users to do lookups at most once per second. If you are looking up a single music file, but Picard figures out that the file corresponds to a track on an album, then Picard has to do the work to look up that album just to have the information for that one track. I am not clear on the details, but getting the information for an album might take more than one MusicBrainz lookup.

When Picard is holding up lookup calls due to rate limiting, it draws a little hourglass icon at the bottom of its window with a decreasing number followed by “s”. I understand this as Picard’s estimate of the number of seconds of rate-limit delay until it has completed its lookups.

The next time you get a slow EP, look for the hourglass at the bottom of the Picard window.

I hope this helps,
—Jim

It is probably also worth noting that Cover Art is run by the Internet Archive and not Metabrainz. And downloading cover art takes two or more Internet Archive calls - one to see what is available and at least another to download the actual art.

P.S. Internet Archive is run by the US Government, the current incarnation of which has a history of making snap decisions to cut costs and save money without understanding or considering the consequences. It could disappear at any point.

This needs some correction: The Internet Archive is not run by the US government. It is a US based non-profit. They are for sure under frequent legal pressure and, being dependent on donations, have to deal with limited resources, though.

6 Likes

Yes - my mistake. I should have checked. However, funding is not guaranteed and it could disappear at any point for lack of funding or due to losing a copyright case or because the current US Government doesn’t want a historical record kept by them of statements that they now wish they hadn’t made.