Picard crashes when looking up Other Versions


*Edited to fix automatic link created in version info (Build for Win.10 created a link to a non-existent “dot rs” site)

I could use a little help either tracking this down, or learning how to live with it. I’m writing this post, and checking things as I think of them, in the hopes that it will help future searchers.

I have gone through over a hundred albums, mostly without a problem. I have seen this behavior with other albums as well. It seems like this has to be related to specific releases.

While trying to see if this could be related to the specific files, I tried to do a “Web Lookup” instead of a “Lookup.” Picard crashed with the selection of particular releases. Re-opening Picard, and clicking links from the browser has confirmed this. With no files loaded into Picard, specific links cause it to crash. Others have no problem.

Clicking the “Tagger link” for this specific release seems to crash it consistently.



  1. Drag folder to Left Pane. Click “Cluster.” Click “Lookup.”
  2. “album information” loads as expected.
  3. “Right Click” album, “Other Versions,” select any other version listed, and Picard crashes like below.
  4. Close Picard, Repeat process with a Different album, and works as expected.
  5. Without closing Picard, repeat process with previous album, Picard crashes as before.
  6. Other albums continue to work, although there are some problem albums besides this one.

MusicBrainz Picard, Version 1.4.2.
PyQt 4.10.3
Qt 4.8.5
Mutagen 1.36
Discid discid 1.1.1.
libdiscid 0.6.1
Windows 10 Home build 17025 rs
8GB Ram,
OS on internal SSD, music being processed is on WD 4TB Passport.

W: 19:34:34 CoverArtProvider: queue_downloads() was replaced by queue_images()

E: 19:34:34 Network request error for http://webservice.fanart.tv:80/v3/music/albums/d834faea-a8d2-3bc9-94b0-ff6b5d7df413?api_key=21305dd1589766f4d544535ad4df12f4&client_key=c1e61671e2efa3ca991474f185688921: Error downloading http://webservice.fanart.tv:80/v3/music/albums/d834faea-a8d2-3bc9-94b0-ff6b5d7df413?api_key=21305dd1589766f4d544535ad4df12f4&client_key=c1e61671e2efa3ca991474f185688921 - server replied: Not Found (QT code 203, HTTP code 404)


I tried replicating this with the exact same album, but for me it works every time.
Could it perhaps be some plugin or script that interferes here?


Didn’t try that. I reset all defaults, and it works.

Has to be something specific with that release, and how it interacts with my combination of plugins. My original post was the last entry in my logfile. Another logfile had the last as a problem connecting to Archive.org for cover art. I just tried it again, and the status bar shows downloading cover art. I’m tailing the Log file, and the last entry is “no wikidata url.”

I notice that there is no cover art on the MusicBrainz page. I wonder if that’s the issue. Shouldn’t that fail gracefully though?


Took a few minutes to poke.

Seems to be the “wikidata genre” plugin?

Went through all 11 plugins I use, and Wikidata Genre seemed to be it.
(I enabled the plugin, “Refreshed” and then tried to switch.)
when it crashed, I restarted and disabled the plugin. (Unselect, “Make It So.”)
Tried the album in question and it worked.
Back to settings, and “wikidata genre” is already checked!
Tried the album again, and it worked.
Tried a few more different versions and it crashed.
Repeated the process to get the number of times so I could post, and now I can’t get it to fail again.

Could this have been some issue in the Cache? I Deleted the folders under C:\Users<user>\AppData\Local\MusicBrainz\Picard\cache\picard. I will report back if this happens again.


I’ve sent a fair few albums through Picard, and I’ve had a couple of instances of strangeness like this occur.

Restarting Picard, and / or restarting Windows does not help. No harm seems to be done outside of mild irritation.

For the benefit of future users who are searching;

To clear the MusicBrainz Picard Cache in Windows 10;

  1. Close MusicBrainz Picard.
  2. Navigate to <Main Drive (C:)>\Users<User Name>\AppData\Local\MusicBrainz\Picard\cache\picard\data7.
  3. You will see a series of folders named sequentially; 0 through f.
  4. Select and delete all of these folders.
  5. Restart MusicBrainz Picard, and use as normal.


I also experience an occasional hang-up.
Picard would surely benefit from a ‘cancel all actions’ button. Now all you can do is force a close, and start over again, which is no fun when doing bulk actions.

I also have the ‘wikidata genre’ plugin active, but I can’t say for sure if that’s a cause for these hangups.


Hm, on second thought, ‘wikidata genre’ might indeed be a culprit.

Doing some identical bulk editing with- and without the plugin results in some hangups only happening with ‘wikidata genre’ active.


I’m going through some particularly troublesome albums right now, so my current batches are limited to a couple dozen albums at most. It seems I mostly had trouble when I was trying to process a few thousand tracks at a time.

Now that I’m running smaller batches at a time, I haven’t seen the issue as often, but I have seen it. A quick cache clear as indicated above seems to take care of it. Restarting Picard does not. The frustrating part is that there is no consistency. I’ve noticed that I can’t replicate it after I “fix” it. Even if I go back to the same files.

It seems weird that restarting Picard does not fix it for me. Does that make a difference for you?


It’s hard to pinpoint, but a restart will get me along again, and I haven’t really tried what clearing the cache might bring.
I have the feeling it occurs more often when I drag some songs to other albums/compilations, or after having saved albums in the right pane, doing some new clustering in the left panel.
It seems to me the plugin gets confused when you make some alterations, or changes in grouping in the Picard panels.
Does it crash with you even if you don’t make any changes in the panels?
(order of tracks, dragging between panels/folders etc.)


I do recall moving tracks around before it crashed. Once it crashed, I was hooped for that album until I cleared the cache.

It might have something to do with quantities. I’ve been jockeying tracks around like a madman in my latest tagging sessions, and it has happened, but not often. Perhaps it’s just probability with how the wikidata information is stored. If it’s randomizing to the cache, the more tracks you are working with the better the odds that something will be duplicated? I’m just taking a SWAG, with no real evidence. It’s also really light on the “S.” I have no idea what I’m talking about, just throwing ideas.


I’m sure we are on to something.
What might become a workflow for me:
First run albums through Picard without the wikidata plugin, to get at least the albums and id’s correct, and save all.
Then restart Picard with the wikidata plugin active, and process the albums again.


I hate to think about duplicating effort, but the second run-through would be quick.

I wonder what clearing the cache does at different times in the process? Maybe moving things around, then clearing the cache before saving? Clearing the cache in the middle of a session? When I start doing more bulk sessions again, I’ll experiment with this. For me, the app crashing doesn’t pose too big a problem.

Once I get started on the bulk of my library, I shouldn’t have much track jockeying to do for most of the albums. This should help prove our theory about lots of moves confusing the wikidata plugin.


The wikidata-genre plugin just seems far from solid or stable. It regularly makes Picard crash for no apparent reasons.
Looking at the version number (0.2), that indeed suggests it’s some beta. (or alpha?)
But here:
It says there is a 1.0 version, but no matter what I try, it keeps showing 0.2.
Do you have 0.2 or 1.0 running?


Mine not only shows 0.2. Off to see what I can find.

Turns out, I haven’t been having problems, and wikidata-genre was not enabled. I bet this goes back to my previous point about disabling it and going back to the options to find it still enabled. I don’t like this level of strangeness.

On the plus side, I have confirmed for myself that re-tagging is incredibly fast and simple. (Just a small handful of albums with very specific changes I need to watch out for, and those are easy to spot.)


I believe that is a known bug, but there doesn’t seem to be much drive to fix it.
Just f.y.i.: my impression on MusicBrainz and Picard is that it is largely a playground for coders/developers.
There doesn’t seem to be much focus or interest on the experiences and opinions of end-users who are not that savvy in lingo and common practices in the world of programmers.
Perhaps there is a lot of activity behind the screens on development and improving Picard and the plugins, but on this forum it is very hard to find threads or useful information about it.
Just my 2 cents.


I’ve got the same impression. Honestly, it’s a big reason I stayed away from MusicBrainz/Picard for as long as I did.

My wikidata plugin is version 0.2. It looks like the next version of the API has Wikidata 1. The version for us mortals is 0.2. I think you are looking at the bottom of https://picard.musicbrainz.org/plugins/. That’s for the Dev version. The generally available version is listed in the middle of the page, in the last row of the “API version 1” table.

I found the MusicBrainz site on Github, and I may venture into the realm of the coders to see if I can make any sense of what’s happening up in the ivory tower. I shall be cautious, the map I have only shows the legend; “Here there be dragons.”


Ah, you are right.
I remember once looking for the Picard v2 unicorn, but if I recall correctly there wasn’t a beta available. (at least not for Windows)
Safe travels, and make sure you pack a lot of Coke and some spells in your back-pack.


It looks like the pace of development is pretty sporadic. I get the sense that this is not a priority project for the people working on it.

I’m tempted to download the code from GitHub, and see what happens when I try to use it. Not sure I want to open that particular can, though. Some kind of Beta version would be nice. I saw at least one developer note that they made a change, but couldn’t test.


I reported this bug some time ago, I guess there are bugs with higher priority to be fixed before this one. You can check out the report here: https://tickets.metabrainz.org/browse/PICARD-1067


I’ve had the same exact issue and when I disable wikidata-genre it’s fixed. I am on a mac using High Siera too.