Picard 2.0.2 released! Signed macOS releases!

Allow me to answer myself. I ran the 2.0.2 installer on my Windows system, and all my 2.0.1 settings/scripts/plugins seem to have kept and untouched.

2 Likes

I haven’t been able to replicate this again. So either it was fixed with 2.0.2, or the release that I did experience it with has been a problematic one.

1 Like

thanks for your work @samj1912

3 Likes

Suppose you have a simple script like this:
$set(DISPLAY ARTIST,%artist%)
(note the use of capitals)

Using that, on a first run Picard will show ‘DISPLAY ARTIST’ in the first column of the bottom pane.
But when you save the result, and then scan the release again, it will display a populated ‘display artist’ (lower case), and add a second line with a blank ‘DISPLAY ARTIST’ that it offers to populate.
So you now have two display artists in the left column.

Is this expected behaviour?

edit:
This concerns flac files, mp3 seems to have no problem.

Thank you, Developers, for a new Picard release!
I downloaded 2.0.2, today, and it opened perfectly, after it had been released from the .dmg.
I was not aware that the new release did not need to be installed in my applications folder (but, where would I “keep” it, then?), so I installed the .app over my existing 1.4.2, and now 2.0.2 will not open, at all.
Is there a way for me to roll back to my old version, and then get the new version as a standalone .app?
Thank you, for any consideration and advice!

Hey Guys!
I got 2.0.2 to finally open with it installed into my applications folder. What is it that most tech support places often tell us? Oh, yeah, “please restart your computer.” I did that, and that was all she wrote.
Sorry to have taken up anyone’s time with this. Thank you, again!

1 Like

With some regularity I get a red disc icon indicating ‘error’ in the right side pane.

When selecting ‘info’, this is what it says under the ‘error’ tab:

Traceback (most recent call last):
File “picard\album.py”, line 330, in _finalize_loading_track
File “picard\metadata.py”, line 358, in run_track_metadata_processors
File “picard\plugin.py”, line 510, in run
File “C:\Users-\AppData\Local\MusicBrainz\Picard\plugins\standardise_performers.zip\standardise_performers.py”, line 38, in standardise_performers
for key, values in metadata.rawitems():
RuntimeError: dictionary changed size during iteration

For singles (single tracks), Picard 2.0 is still often excruciatingly slow in loading the release it guesses it comes from.

For example, let’s take the single ‘Dreadlock Holiday’ from 10cc.
It’s from the album ‘Bloody Tourists’.

Bloody Tourists contains 12 tracks.
So it would take some 12 seconds to load that release.

But, when you do a lookup or a scan in Picard, it will load some compilation album, containing maybe 100 tracks.
The result: loading takes about 10 times longer.

Ideally it would take 1 second (because you only require the data for 1 track)
If it is required for Picard to always load a complete release for a single track (I’m not sure if that’s the case?), loading would take some 12 seconds.
But in reality Picard will match some compilation album, and that will take one and a half minute. For one track.

I have tried the slider settings for preferred releases (compilation completely to the left, singles completely to the right) but I notice no difference whatsoever.

Am I doing something stupid, or is this a broken feature?

edit:
I was wrong in pointing at Picard for the terrible loading times for singles.
The culprit is the wikidata-genre plugin. Without it, single releases load at a normal speed.

Try the load as NAT plugin by @outsidecontext https://picard.musicbrainz.org/api/v2/download?id=loadasnat

Thnx. samj1912
A quick one-shot try with all the sliders reset gave a match with some release containing 165 tracks.
That’s a new record of 3 minutes :frowning:

But I’ll give it a more serious and thorough try later on with experimenting some more with the sliders.
Just curious for now: Shouldn’t the ‘compilation’ and ‘singles’ sliders already achieve something like this?
Without the need for additional plugins?

@samj1912 What WinOS versions are now supported? I assume XP is dead. What about Vista?

Also what version of Python is now required, and is that Vista compatible?

I ask as this thread has a guy with Vista 64-bit hassles. And I am assuming this could just be that he is out of luck as that is too old to be supported now. (But I can’t locate the minimum spec page in the docs)

If I get time later I’ll boot up a old Vista box I have here and see if that is 64-bit. That will give us some test feedback. Vista is a fussy old dame and may need special poking of Python or summit.

I’ll sharpen my special PokinStick™ and see what can be found…

I’m giving up on this. The results are so erratic that it’s gonna be pretty much impossible for me to draw up some coherent report.

@hiccup, we have a PR(https://github.com/metabrainz/picard/pull/920) to improve upon this. It will be released with 2.0.3. Also are you sure you are using Load As NAT plugin correctly? It provides a context menu option to load appropriate releases iirc.

1 Like

I haven’t tested it on Vista either but we build Picard on a win10 machine. I have personally tested it till win 7. Not sure about Vista.

Python version is irrelevant for the installer. It ships with the required version of Python with it. (However I have noticed py3.6 builds of Picard don’t work on win7, which is why we use py3.5 in the package). The minimum required version to run picard is py3.5.

Thanks for getting back to me @samj1912. If you check that other thread you’ll see that I have now done a test on 64-bit Vista for you. And got a Python error. I wonder if 64-bit Python even works on Vista now it is an abandoned platform?

I am happy to do any tests you want on there if it helps.

This was version 2.0.2 so it was still installing to C:\Program Files (x86)\

(I did try manually changing that to C:\Program Files\ without any change of the Python issue)

This Vista PC will be around for a while, so happy to throw any tests at it you want.

I was wrong in pointing at Picard for the terrible loading times for singles.
The culprit is the wikidata-genre plugin. Without it single releases load at a normal speed.

I notice no differences when using the ‘load as non-album tracks’ plugin.
And I can’t find any context menu that you are mentioning for it, but since loading times are back to normal, I don’t think I would have much use for it anyway…

So, case closed, all is hunky-dory again.
The worst part is, I am pretty sure I already knew about this problem with the wikidata-genre plugin.
(and that with certain releases it even makes Picard crash)
I must have completely forgotten about it.

Thank you @samj1912 for the suggestions and for looking into this!

1 Like

The “Load as non-album track” plugin does no additional lookup, just some tag trickery to make a track behave like if you loaded the recording directly as NAT (non-album track). You find it in the Plugins context menu of any loaded track on the right pane, see this animation:

Peek%202018-08-14%2013-52

What it basically does is loading the selected track’s recording as a NAT and then move any files matched to that track over to the NAT recording. It also removes all tags that are album specific. It is useful if you e.g. have single files that might be from different albums and compilations and you don’t want to tag them against a specific release.

4 Likes

Thanks for the great explanation outsidecontext. I’m going to give the plugin another shot soon.

Oh, are plug-ins not automatic any longer? If that is the case, no wonder I cannot get them to work!
I will try what I see @outsidecontext is doing.
Thank you!

Nothing changed here. There have always been different types of plugins:

metadata processors: These plugins can access and modify the metadata when it gets loaded from MusicBrainz. Those are probably what you call “automatic”. The Classical Extras plugin is an example for this.

coverart providers: These plugins provide another cover art source. They are also “automatic” as they load album art without user intervention. The Fanart.tv plugin is an example.

scripting function: Some plugins just provide additional scripting functions for use in Options > Scripting or the renaming script. Keep tag, which provides the $keep function, is an example for this.

actions: Plugins can register actions that can be activated manually via the context menu. This is what the Load as non-album track plugin does. Another example is Generate Cuesheet.

formats: Plugins can also provide support for new file formats not yet supported by Picard. There is no good example for this I know of. videotools makes use of this functionality, but by far not complete to fully support something new.

Note that plugins are not limited to one of those areas, a single plugin could implement all of the above. But most existing plugins focus on one.

Edit: Added formats plugins

2 Likes

Thank you very much, outsidecontext! I cannot seem to get any of the plug-ins I have chosen to work, nor show up in the context menu.
For example, the “feat. artist in title,” plug-in is not working, along with a few others I installed.
Sorry, I do not mean to thread-jack.