Despite Picard’s termination, these two variables from the topic remained at values of 37m34s and 2254.
At the beginning of Picard’s run, they decreased correctly. At some point, they stopped while Picard was adding albums.
The screenshot shows the last Picard process, the current time, and these variables.
That means there are still 2254 pending network requests not completed. Most likely cover downloads, they will take a while. The remaining time is an estimate based on file loading and request times. Given that the default MB rate limit is 1 request per second 2254 pending requests are roughly 37 minutes.
I don’t think so. The “loading album information” is no longer visible like in the other sessions.
There needs to be sorting, for example, by artist.
In Picard 3 some types of requests can be non blocking. They will update the release once completed
In the first screenshot, Picard ended its run at 10:37:41.
At 10:39:04, the numbers were still the same.
Take a look at a similar example. This is what the end of my album loading process looks like.
!DelaDap moves up one row per second.
2346 pending requests. They haven’t changed in an hour. There should be 32 of them, the same as “loading album information.”
The last screenshot still shows albums loading. Picard doesn’t know in advance how many requests it will take to load everything, this depends on the data returned and the plugins being used. The estimate is based on the current active requests (running and queued), but additional requests might be needed.
When a specific album is getting loaded and you have remote cover art sources or other plugins doing requests, the album fetching requests will have ended, but new requests are queued up.
OK, but I didn’t have this problem with other Picards back in the day. And I haven’t changed my methods.
If you consider the matter closed, don’t reply. I won’t be offended. 
