Picard 2.0.3 released: Crash-fixes and scripting improvements

9 Likes

Thanks for the fixes! I’ll test and report back ASAP.

1 Like

Great, thanks @samj1912
I was wondering, could you comment on this observation I have made earlier? :

.
And another thing I noticed:

The input for the ‘preserve these tags’ option seems to be case-sensitive.
I myself can not think of any useful reason that it is.
On the contrary, it makes it more troublesome to get it working, since you’ll have to worry about idiosyncrasies of other software and the different codecs you might be using.

Do you agree? Could it be made case-insensitive?

2 Likes

Looks good so far. Is track.orig_metadata available for plugins to use? At the moment, for Classical Extras, I have to get all the files that Picard has matched to an album and then do my own matching on disc/track number in order to get the file metadata for a specific track. It would be so much better if I could completely piggy-back off Picard’s matching, but track.orig_metadata doesn’t seem to return anything.

On the tags, things are looking good for now. I’ll continue to keep an eye on it.

The more I think about it the more I see that what you were attempting to do is a good idea, it’s just that there was something off in the execution. Maybe it’s as simple as letting users know how they can achieve the same thing after the update.

I did get a crash, oddly while trying to clear the error log. Consistently duplicatable.

1 Like

Could you or samj1912 explain in mortal language what this specific change/reversed change pertains?

(PS, Picard crashes with me too after clearing the log)

1 Like

Fixed with https://github.com/metabrainz/picard/pull/922

1 Like

I may not have this exactly right, but my understanding is that there was a desire to have existing metadata loaded into Picard so that it could also be manipulated with scripts, etc, maybe even without loading any data from Musicbrainz.

But how do you access it (from scripts or plugins)?