Picard 2.0.2 released! Signed macOS releases!

MusicBrainz Picard
21

This is next on my list to fix. This problem arose due to PICARD-259

We are temp. reverting this feature.

2 Likes
22

Thanks! As I said in the ticket, all I really want is a way to tell Picard to never, ever under any circumstances touch certain tags. I hope for it to be less complicated to use & program, not more.

3 Likes
23

Thanks for investigating it.
It was certainly not a deal-braker issue, but I was curious if 2.x would be more forgiving and robust when you make changes to settings, scripts and plugins.
With 1.4 I learned to restart every time I just even looked at the options panel :wink:

I can’t remember the exact release I experienced this with, but it happened with a few, and also after some restarts.
I’ll install 2.0.2 and see if I can replicate it again.

Will running the 2.0.2 installer leave all my 2.0.1 settings/scripts/plugins intact?

24

I was curious, isn’t it so that Picard 2.0 is x64 only?

There’s a good chance I misunderstand what this means exactly:

But if it does mean what I think, on Windows shouldn’t it install in the ‘Program Files’ folder instead of in the 'Program Files (x86) folder?

25

Ah yes, the default installation path needs an update. Will fix.

2 Likes
26

Absolutely! 64-bit apps into “Program Files” and 32-bit into “Program Files (x86)”

Or more accurately - it should be %PROGRAMFILES% to handle different languages. Please make sure you don’t have C:\Program Files\ hard coded as this changes for different countries.

27

We need to update this to PROGRAMFILES64

I didn’t realize the current value would resolve to x86 dir until later.

2 Likes
28

great.
I also searched for the location where the scripts are stored for 2.0 but I couldn’t find it.
(that could be handy for back-up/restore purposes)
Anybody?

29

See the notes for ini files

http://doc.qt.io/qt-5/qsettings.html#platform-specific-notes

1 Like
30

Thanks, so the contents of the scripts are integrated in the ini file.
I was looking for separate script files in some appdata folder that might be back-upped separately.
Restoring a saved older ini to a newer installation might not be such a great idea.
Or is it completely safe to do that?

31

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
32

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
33

thanks for your work @samj1912

3 Likes
34

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.

35

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
36

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

37

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.

38

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

39

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?

40

@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…