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.
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?
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 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.
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.
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:
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
