Yeah, I probably should have said auto-notification.
I am used to get notified of a new version of a plugin when I open the plugins panel?
Now I see. Yes, the latest published version is 0.6. While the plugin received an update recently we haven’t yet updated the website. Currently the website needs to be re-deployed to show the latest plugins. That’s not fully automated yet.
2 Likes
A casual question to others to see if they’ve experienced this, I’m not sure its a bug in Picard so I am hesitant to submit it as such.
With 2.6 (windows x64) I have had this issue that occurs. no error messages appear or anything, but after a few uses Picard loses the functionality of being able to drag and drop files and clusters within the two panels. Not drag and drop into Picard from external, only the ability to manipulate from in the program itself. I can highlight something, but if I try to move it nothing happens. I can scan and lookup tracks but if on the right it groups from 1 album into 2 versions, I cannot consolidate those two together because of this issue.
closing and restarting the application does not resolve the issue. rebooting my PC will fix the issue, but after several uses the issue will reoccur with nothing otherwise unusual happening.
anyone else experience this?
I haven’t experienced that here, running 64-bit Windows 7. Strange that a reboot fixes it, but not stopping and restarting the program.
1 Like
yeah, it is. that’s why I suspect it’s a memory issue or something with my PC, but I’m not having any similar glitches or errors in any other applications except this one.
Does anything show up in the log for Picard? You might also try disabling all plugins and see if that works. If it still fails, then we’ll know it’s something in Picard itself. If it works with the plugins disabled, you can then re-enable them one at a time to see which one might be causing the problem. Thanks.
2 Likes
We have released Picard 2.6.1 with bugfixes, performance improvements and some scripting enhancements. See the blog post for details:
6 Likes
Here is a confused feature\bug in Picard.
I have a four disc boxset I am tagging. It is a bootleg and each track has a Track number and CD number set. Each track is labelled “Piste 1, 2, 3, etc” and the album is “Album inconnu (21/08/2019)” with similar “Interprete inconnu” garbage in the Artist name.
I have punched SCAN to get some AcoustIDs, knowing it will be wrong, but dragged it back to the left to re-cluster as I know the album this is from. Cleaned out the wrong matches on the right, and used TAGGER to get the correct album on the right.
Now I have tracks on the left with fingerprints and AcoustIDs, and one album selected on the right.
Problem 1 - I am trying to use Drag and Drop to move each cluster to line up to the album on the right. It does not seem to want to read the track\disc numbers so I have some manual shuffling. NOT a problem as this is badly tagged.
Now I have it all lined up neat… and I spend some time on MusicBrainz updating some tags\details from the booklet.
Problem 2 - I return to Picard and make a BIG mistake. I hit REFRESH. ARGH! Why has my carefully hand sorted tracks now all jumped into CD1? Why did refresh reorder the tracks that were carefully hand placed?
I can make this album available via WeTransfer or something for testing. Or is it planned for Refresh to shuffle all the tracks on the right like that?
Note: the newly shuffled order seems to have no sanity to it. Now attached to track 1-01 I have tracks 1-01, 2-01, 2-14… it is weird
Note2: Why the SCAN step? Because I want to read the AcoustIDs as I am trying to clean up some other issues in the DB connected with this. Yeah yeah, I could have done all the fingerprinting later but don’t expect this weird head to do anything in what you think is a logical order 
Yes, that means the similarity of the existing metadata of the files to the actual track metadata is not good enough for Picard to consider it a proper match. What you can check is your setting at Options > Advanced > Matching > Minimal similarity for matching files to tracks. By default this is set to 40%, maybe it is set to something higher. Or even if it is 40% try to lower it even more, maybe that gives better results.
Refresh currently works that way: It puts back all the files into unmatched state, loads the data again and then matches the files freshly to the tracks. I’ll add a ticket to improve this.
2 Likes
I was kinda hoping it would trust the track numbers\disc numbers first when it saw a repeating word. But that isn’t really an issue as it works pretty well if dragged\dropped in batches aiming at separate start points down the list. For example, if I drop just disc two files onto where disc two starts it matches well.
Yeah - that was kinda unexpected. I thought it was just going to Refresh the Data from the Website, not reorganise the way the files are lined up. If I wanted it to reorganise the files I’d drag it back to the left first to re-populate it that way. It feels like currently “refresh” is doing “lookup” as well without being asked.
I think some of the problem is the fact I was working on boxset that were either missing from MB or needed data updating in MB. I had loaded up Picard then swapped to Database Editor Mode and spent time on the website. It was the swapping back to Picard to copy that data across that caught me out. I should have hit the first SAVE a bit earlier to get the MBIDs into place and avoid refresh-reorganise.
Rest of the program is running well. Seemed speedy handling these four disc boxes I was working on last night.
OS: Linux Mint 20.1 x86_64
Kernel: 5.4.0-72-generic
MusicBrainz Picard Version 2.6.1
Since upgrading to 2.6.1 (from 2.6), I’ve encountered a new problem. It used to be that when I dragged a bunch of mp3s onto an album I know they belong to, it would show all the metadata in “Original Value” on the left so I could match it up on the right. Now the Original Values are almost all blank, and I have to look at the lower left status bar to see which file it’s actually trying to match up.
Did something change? Is there a setting I need to tweak?
Thanks for your help!!
I also get weird stuff like this when I right-click search for similar tracks, and the program becomes unresponsive. This happened once before; I think I switched away from the dark theme to “fix” it last time.
EDIT: I just confirmed when I switch back to “default” user interface (from “system” [dark]) this problem goes away.
EDIT 2: Side note - the button location is opposite between the “system” and “default” interfaces. I just accidentally restored all default settings when trying to switch back to the light/default theme. UGH.
I think the missing original values was due to this change PICARD-2170. There will be a switch to turn it back on PICARD-2171.
I don’t fully understand that, which buttons? The “default” setting will use Qt’s Fusion theme. This is the recommended setting, as it is the only one we can really support. If you set it to “system” Picard will use the Qt theme you have configured on your system. This might cause issues. If it works that’s fine, if the theme causes issues use “default” instead.
2 Likes
Default – “Make it so” is on the left
System – “Make it so” is on the right
I really wish I could use the dark theme.
1 Like
KDE’s Breeze theme works well, maybe try that.
1 Like
A short update on this: The issue happens if the files do not have title tags. In that case Picard guesses a title tag from the filename. Previously this guessed filename was shown as “original metadata”, in Picard 2.6.1 it instead shows up in “new metadata” for a loaded file. The reasoning was that this data is not part of the tags, and hence should be considered new, see PICARD-2170.
But since new metadata gets overwritten once you match that file to a track this guessed title is not visible. In practice the old behavior was more useful. And given that we had no complaints about this for over 10 years until PICARD-2170 I guess it was working well for most. So I think this change was a mistake and we’ll revert this change in Picard 2.6.2. For Picard 2.7 we will introduce an option instead to turn off this automatic tracknumber and title guessing for those who do not want this behavior at all.
5 Likes
We have released a bugfix release 2.6.2. It reverts the behavior how guess title / trackname are handled (as discussed above) and fixes an issue where plugin updates could fail. See the blog post for details:
6 Likes
And there is another update, Picard 2.6.3 provides some additional bugfixes:
I highly recommend that you update. This fixes a serious bug where some option changes did not get applied until a restart of Picard. It’s a rather huge issue that should not have slipped through into a release, but strangely we did not receive any bug reports for it. Anyway, it’s fixed now 
8 Likes