Lately, Picard has been locking up on me. I can’t get the logs since the app has locked up so I can’t get into the Help screen.
Using Picard 1.4.2 and Xubuntu 16.04.3.
It seems to lockup on either the album art (which I’ve disabled) and on looking up other versions of an album. I’m also getting different results when scanning a cluster.
I was able to get the log in debug mode going before the freeze. I do a Cluster, then Scan, then right mouse click on the album in the right pane and then do a right click, Other versions, and choose one of the other albums.
The last entry in the log is (I can’t copy past it):
D: 08:25:12 WSREQ: Last request to (u'musicbrainz.org, 443) was 71679 ms ago, starting another one
And then it freezes up. I hit the close in the upper right and it says the window might be busy or not responding.
Wait a minute - I think I got it!
Turns out the wikidata-genre plugin was the culprit!
I disabled it, deleted it from .config, and now Picard is behaving.
The hunt for a genre plugin continues…
1 Like
man, your comment was a lifesaver. I have been cursing at Picard for a year not knowing why it triggers a crash if certain albums get queried. it was that damn plugin the whole time.
they should remove it. can’t believe how much time I’ve wasted because of that thing.
1 Like
Just a quick update on the wkidata genre plugin.
I have identified where the problem is and have a potential fix for the problem.
The plugin has a problem when there are multiple wikidata url’s linked at a release, artist or work level. This may happen if there was an entry for the original release and a re-issue of the release and someone created an entry for both.
This fix is currently in the 2.0 branch but needs some work before it can be merged there.
As just about everyone is running the Picard 1x branch I will need to make the same code changes to that branch and get it applied.
Hopefully I can get this applied in the next few weeks.
Please disable the wikidate genre plugin if you are having trouble.
6 Likes
Any chance of this still getting some love?
I’d like to add that it locks up hard for me on linux. Closing the gui doesn’t kill the process. I’ve been running picard in debug mode and you can’t “CTRL+C” to kill it either.
^CD: 18:47:30,878 /usr/lib/python3.7/site-packages/picard/tagger.signal:733: signal 2 received
Just hoping to see a fix.
Cheers
I just submitted a PR for this plugin: https://github.com/metabrainz/picard-plugins/pull/181
Let’s see if we can get some joy with this thing 
2 Likes
Update… This PR is still cooking. The maintainer wants some additional structural repairs before releasing. But it looks like it will be accepted in a modified form and the official wikidata plugin updated in the near future. However, that could take some more time. Until then, you can download a vastly improved wikidata.py file here:
You just replace your wikidata.zip with the wikidata.py file at that link. On Windows, the location is like:
C:\Users\[username]\AppData\Local\MusicBrainz\Picard\plugins
You will need to restart Picard if its already running. Once the new wikidata plugin is released, I will follow up here & remove this post. Those who implement this manual workaround may need to delete the wikidata.py file at that time to get new wikidata plugin updates.
3 Likes
Thanks GrokMan, much appreciated.
This version seems to resolve the hanging issues I very often experienced with this plugin.
1 Like
@GrokMan Thanks for your work.
This plugin is complex and if you can work out a better way of doing it that would be great.
I discovered the issue with the wikidata plugin crashing Picard almost a year ago. I ended up just using the last.fm plugin for genres. (I regret that now.) I’m getting ready to revisit my library metadata, and I came across the recent work on Picard, and the Wikidata plugin.
I tried to look at the Github conversations, and it turns out I don’t speak programmer. Can I get some insight on how much better the temporary script is than version 1.1 which is installed? Would the future changes make it necessary for me to re-run albums? Do they need testers?
The results it produce are the same as the previous versions.
This fixes some bugs where picard would not finish loading albums so it should work more consistently.
2 Likes
Is there a thread to discuss the script?
I installed the script, and cleared the cache to test it. One of my test albums works fine, but I found one that does not. I’m also a bit confused on how to use the plugin. It does not seem to do what I expected.
Edit to add; There seems to be some weirdness. The album I mention, works fine if I cluster, and “lookup.” It finds the entry based on the MusicBrainz ID already embedded. If I scan the files without clustering, Picard no longer crashes, but the albums show as “[loading album information].” I can still use Picard to process other works.
This here already is a thread discussing the loading issues caused by the wikidata-genre plugin. A fix for this is being worked on. Feel free to open a new thread for other questions.
What exactly did you expect? What it does is setting the genre tag based in information from Wikidata.
1 Like
I expected that I would get genre information based on the release, but it looks like I get all the genres associated with the artist instead. (I can’t prove it’s not a combination of both.)
Is there a way to select only the first “X” number of items found in the genre list, or do I need to come up with a creative way to do this in the tagging script? I couldn’t find any options that control the plugin.
I’d be ecstatic if I could pull the genres from the “release group” for the album, directly from MusicBrainz, but I don’t see how to do that.
Its currently pulling a combination of genres from all 3 of: release _group, artist, & work. I rather agree that pulling all 3 and applying them to each track is not what most people want. The reason being that some artist can have wide-ranging music which could cover many genres and certain tracks from one of their genres would not be considered of another genre which the artist also covers. I’ve already run into this myself. It seems like the original design wanted to pull in everything - perhaps to cover cases where they were coming up short.
I believe the right solution to this would be to have a plugin UI, as do some other genre plugins already, like last.fm.
Unfortunately, I don’t think it would be appropriate to make this change in the current “repair” work that is underway here. Its usually better to encapsulate the work even though it may take a bit longer for all the work.
However, I can create a feature request (FR) ticket and perhaps work on that once this is done. Maybe this is a good time to welcome input for such a FR. Eg, one idea might be to have check boxes for each of the possible genre sources to pull in for a given track.
EDIT: Another improvement here - in addition to the straight use/don’t use for each genre source might be to have an option to only apply the genres from the additional sources for cases where there is no genre found for a given track.
Other thoughts and ideas welcome
2 Likes
@Pha3drus Does disabling the wikidata plugin solve the “stuck at loading after a scan” issue you see for the one album? Just asking because - while more rare now - I still occasionally get stuck at loading with our without the wikidata plugin running. With the modified version here, I haven’t been getting this issue except from other plugins or the app itself. If you know or think the wikidata plugin is causing it, maybe you can provide some details on the release in question in case there is something unusal about it which I could reproduce on my side here.
@dns_server yeah there’s a lot going on in this little plugin! I saw you did work on this plugin before. Feel free to join in on the PR with any ideas or suggestions that you might have. I think right now the improvements are just mainly to get it working and some structural cleanup. But it always helps to have more eyes.
Another area that needs some work is the thing where the plugins are modifying private members of the album class. phw mentioned there is a ticket for that so there will likely be work needed there.
Anyway, hopefully by EOW this week I will be finished with this second iteration & get the official version working.
This seems wise. I’d appreciate the options. Let’s fix it before we start trying to optimize.
It might be nice to have a separate variable to work with in scripting, otherwise, I can’t think of anything.
Once I manually installed the plugin script properly, cleared the cache, and restarted a couple of times; my test albums processed without hanging.
2 Likes