Picard crashes when looking up Other Versions


Not having looked at the bug list before, I’m a bit sad now that I have. There isn’t a whole lot of activity. Not the first time I’ve dealt with software in this level of development. I’ll just soldier on, and make it work, somehow.

Thanks all.


Actually, there has been a lot of development on Picard lately, comparing to what it used to be before. If you fancy a read, you should check out this blog post from the dev himself: https://blog.musicbrainz.org/2017/08/31/500-commits-of-summer-my-story-of-foss-and-gsoc/. There wasn’t much Picard development over the last couple of years until he arrived to the community :slight_smile:


This might come across a bit blunt, but it’s certainly not intended as such:

Proof is in the pudding.
Where the heck is the pudding?


I don’t want to sound un-grateful, because I respect people who contribute to FOSS. I appreciate that they use their free time to give to a community of strangers they will never meet.

The GitHub Insights page tells a very different tale. Since that blog post was made in August, there have been very few commits to the project. If you look at the statistics in bug tracking, you see the average age of issues is over 1000 days. Maybe what they are working on just doesn’t show there, but I can only use the information I have.

For the most part the current version is stable. I’ll find work-arounds as I need them. They have new people who are probably just coming to terms with the project. Maybe we’ll start seeing some development in the coming months.

I like pudding.


As an open-source non-profit project it pretty much is that.
But it’s a double edged sword - you really can’t point your finger at the ‘developers’ and say “why haven’t you done much”, because you’re not really pointing your finger at anyone. If you want to have something done the onus is on you just as much as anybody else.

OK, that’s not 100% true as MetaBrainz has employees, and I definitely agree that the lack of end user experience focus hurts MB and Picard. But they really are very busy, and although progress can be slow, I do recommend following the blog! It gives you some appreciation for the size of the to-do list that people are working through for us :slight_smile:
Also it shows the progress that is being made, which is often actually pretty impressive.


It’s good that you point that out, and I never doubted individual efforts, talents and accomplishments.
‘you haven’t done much’ is certainly not a representation of my thoughts on this.
It’s just that it took some time for me to understand why things related to development and communication are going a bit differently here, compared with where the OP and I are coming from and have gotten a bit used to.

I am impressed on a regular basis with the thoughts that have gone into MusicBrainz and Picard, and how well and clever very many features work and are implemented.

So especially to all coders and volunteers: all the best for 2018!


I wrote the wikidata genre plugin and I’m sure it has bugs (reports welcome).
Feel free to contact me through musicbrainz https://musicbrainz.org/user/dns_server/contact
It’s best not to paste your full logs to a forum but you could paste them somewhere and link them here.

If you can give me the release group id’s of what you are trying to look up and i’ll try them on my end.


Thank you very much for the plugin. I appreciate your work on it. I also appreciate that you’ve chimed in to help.

I’m not convinced that this is your plugin as much as it is Picard. In fact, I saw you post as I checked in before writing my latest findings.


  1. Picard crashes sometimes when looking up albums.
  2. It seems to happen more often when using the wikidata-genre plugin.
  3. Re-arranging tracks, or making changes in the right pane seems to make it happen more. (This includes "Rt. click; other versions.)
  4. For me; once it crashes, the same album will crash Picard again, even if it is the only album in queue.
  5. Restarting Picard, or Windows does not fix it for me.
  6. If I clear the Picard cache, everything is fine.
  7. My latest discovery, Picard crahsed when I tried to work with albums before they were all loaded. I have not tested this without the wikidata-genre plugin enabled. I was NOT checking other versions.

I also seem to have independently discovered the visual bug with “disabled” plugins marked as “enabled.”

To be clear, this is not related to any specific release. This has happened with multiple releases.

I am happy to help in any way I can. Let me know what testing you would like me to do.


So I tested some more.

Not that it seems to matter, but I’m processing my 16 AC/DC studio albums

This is what I did and found;

I have wikidata enabled, I let all 16 albums finish processing and tried a different version. CRASH
End task, remove wikidata from “enabled plugins” in the ini file, and restart. (no confirmation in settings window)
For the first release that populated a value, I selected a different release. CRASH
Clear cache, and open Picard. Checked the plugins dialog, and found no confirmation that wikidata was disabled. Clicked the checkbox, and checked ini file. Found a tangent that different plugins are enabled, which means any testing I have done relying on the dialog box is irrelevant because I have no way of knowing what was really enabled. (That is a frustrating bug for a user.)
I cleared the enabled plugin section of the ini, except for wikidata. Settings dialog shows nothing enabled.
While releases were loading, I tried a different version for a different release, and the one I did before. WORKED PERFECT
(Closed and reopened Picard) I enabled my previous list of plugins in the ini file, and repeated the test. (Settings dialog seems to match the ini file contents.) WORKED PERFECT
I enabled the wikidata plugin, and confirmed in the ini file. Closed and reopened Picard. Tried to find an alternate version while the rest of the releases were loading. CRASH
Cleared cache, restarted Picard, and waited for everything to finish. I did not interact with Picard while everything was loading. Tried to find an alternate version of a different release. CRASH

Cleared the log file, restarted Picard, and loaded same albums, but only did lookup on a single album. Tried different version. CRASH
Cleared cache, loaded same albums, did lookup on same album. Tried different version. No interaction with Picard while loading. CRASH
Cleared cache, loaded single different album. Select other version. (Happened much quicker.) CRASH
Disabled wikidata in the ini file. Tested with what I think is the same album. different version. WORKED PERFECT
Repeat test; With wikidata disabled, all albums loaded, and set to lookup, change versions. WORKED PERFECT

It looks like an interaction with another plugin that is causing the issue. Here is my full list from my ini file. I’m quitting for a while. Let me know which plugins are the most interesting, and I will start my testing with those. In a perverse way, I’m enjoying this.

enabled_plugins=featartist, standardise_performers, viewvariables, fanarttv, wikidata, release_type, albumartist_website, albumartistextension, smart_title_case, soundtrack, discnumber.


I just send you a link to a track that makes Picard hang every time when your plugin is active.
It is a very common and popular track, so it is probably either some corruption in the file, or conflicting/wrong info in the tag frames present.
(I believe it is a track that I have used earlier to do some Picard experimenting on)
I hope it gives you some clues.



I encountered another issue that can be traced back to the plug-in:

Any chance that it could be addressed?


I’m still looking at the problem.
From the samples you sent me both have 2 wikidata entries on an item.
The plugin should be able to query both entries and then merge the results but it is getting stuck.

Because this is multi threaded code i have some thread locking code to only allow one thread to update the tags.
I know roughly where the problem is but this kind of thing is hard to debug.


Good luck, and let me know if you need a guinnee pig.

My previous reply just above this one is probably much related to this ‘user experience’ and the notion/observation that your plugin crashes Picard.

If you do some bulk scanning, and there is even only one ‘single’ track between them, Picard will match it with some (seemingly random) large compilation album.
Without your plugin active, that is not a big problem, and things still move quite quickly.
But with your plugin active, the whole process is slowed down immensely. Let alone if there are several single tracks in the bulk.
It will result in ‘Picard not responding’, giving the impression of a crash, whilst there actually may be background activity going on.
But as an end-user, you have no way of knowing the difference between the actual bug you are investigating right now has occurred, or that Picard (your plugin) has stumbled over ‘orphan’ tracks, or incomplete albums, and is taking an extremely long time in loading all info from all other tracks from large compilation albums.

Just curious, can you replicate this behavior too?
You could try only one popular song and you should see what I mean.