Crash/Freeze when choosing Preferences/Options on macOS 11.2.1 w/ Apple Silicon M1

I’m getting a freeze-up when choosing Picard: “Preferences” and the options window opens.

The window paints, but I get a round “beach ball” cursor and the Options never populates.

(At this point, Picard will not “Hide” using Apple-> Hide or (from the finder) Hide Others… it’s just stuck in an unresponsive state.)

I have to Force-Quit, which generates a crash report.

  • Picard 2.5.6
  • MacBookAir 10,1 (Apple silicon M1)
  • macOS Big Sur 11.2.1

This still occurs after reinstalling and restarting. But, not consistently; I was able to change preferences 1 or 2 times out of about 20 attempts the last 2 days.

Is Preferences/Options crashing for anyone else?
I can paste the crash report contents if it’s helpful.

I’m grasping at straws here, but it may be that you have a corrupted settings file. Try removing your settings file (or rename it) so that Picard creates a new file and see if that helps. The settings file is stored as $HOME/.config/MusicBrainz/Picard.ini.

It may also be a problem with one of your plugins. You can try removing all of them and then adding them back one at a time to see if it affects the problem.

Fixed. I had to delete not just

/Users/myname/Library/Preferences/MusicBrainz/
but also
~/.config/MusicBrainz/Picard/

and reinstall, now it is working. I didn’t know about the dot-config file the first time I reinstalled.

Thank you for the reply-- you’re right, it must have been something in the dot-config folder.

1 Like

Bummer-- not fixed. As soon as I make a preferences/Options change and close the window, then reopen the window, it goes back to the same state:

The only change I made was to paste-in a different file naming script, turn on “move files”, etc.

Try removing all plugins and then restart Picard. If it starts and runs properly, you should then add the plugins back one at a time, until you find the one that is causing the problem.

Again, I’m just guessing here because I don’t have access to a mac to be able to test any of this. You might be able to get some other ideas from one of the Troubleshooting topics in the Picard User Guide.

2 Likes

Thank you, and thanks for your marvelous work with your naming scripts and plug-ins!

Something about the Picard.ini file is getting messed up. I can replicate this:

  • Backup the Picard.ini file on a fresh install (cp Picard.ini backup.inny)
  • Launch Picard; Options; Paste in the awesome naming script and hit ‘Make it so’ (OK)
  • Options -> freeze-up.
  • Force quit.
  • Restore Picard.ini (cp backup.inny Picard.ini)
  • Launch Picard; Options opens with no problem.
  • Repeat cycle.

After force-quitting Picard once the options window freezes, I can compare Picard.ini and backup.inny using diff and this is the result:

username@MacBook-Air MusicBrainz % diff Picard.ini backup.inny 
65c65
< album_view_header_state=@ByteArray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\0\xff\xff\xff\xff\x1\0\0\0\0\0\0\0\0\0\0\0\x10\xf8\xff\0\0\0\r\0\0\0\t\0\0\0\x64\0\0\0\xe\0\0\0\x64\0\0\0\xf\0\0\0\x64\0\0\0\f\0\0\0\x64\0\0\0\r\0\0\0\x64\0\0\0\x3\0\0\0\x64\0\0\0\x6\0\0\0\x64\0\0\0\a\0\0\0\x64\0\0\0\x4\0\0\0\x64\0\0\0\x5\0\0\0\x64\0\0\0\n\0\0\0\x64\0\0\0\v\0\0\0\x64\0\0\0\b\0\0\0\x64\0\0\x1\x90\0\0\0\x10\x1\x1\0\x1\0\0\0\0\0\0\0\0\0\0\0\0\x64\xff\xff\xff\xff\0\0\0\x81\0\0\0\0\0\0\0\x10\0\0\0\xfa\0\0\0\x1\0\0\0\0\0\0\0\x32\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\x2\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\x3\xe8\x1\0\0\0\x64)
---
> album_view_header_state=@ByteArray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\0\xff\xff\xff\xff\x1\0\0\0\0\0\0\0\0\0\0\0\x10\xf8\xff\0\0\0\r\0\0\0\n\0\0\0\x64\0\0\0\v\0\0\0\x64\0\0\0\b\0\0\0\x64\0\0\0\t\0\0\0\x64\0\0\0\x6\0\0\0\x64\0\0\0\a\0\0\0\x64\0\0\0\x4\0\0\0\x64\0\0\0\x5\0\0\0\x64\0\0\0\x3\0\0\0\x64\0\0\0\xe\0\0\0\x64\0\0\0\xf\0\0\0\x64\0\0\0\f\0\0\0\x64\0\0\0\r\0\0\0\x64\0\0\x1\x90\0\0\0\x10\x1\x1\0\x1\0\0\0\0\0\0\0\0\0\0\0\0\x64\xff\xff\xff\xff\0\0\0\x81\0\0\0\0\0\0\0\x10\0\0\0\xfa\0\0\0\x1\0\0\0\0\0\0\0\x32\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\x2\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\x3\xe8\x1\0\0\0\x64)
69c69
< file_view_header_state=@ByteArray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\0\xff\xff\xff\xff\x1\0\0\0\0\0\0\0\0\0\0\0\x10\xf8\xff\0\0\0\r\0\0\0\t\0\0\0\x64\0\0\0\xe\0\0\0\x64\0\0\0\xf\0\0\0\x64\0\0\0\f\0\0\0\x64\0\0\0\r\0\0\0\x64\0\0\0\x3\0\0\0\x64\0\0\0\x6\0\0\0\x64\0\0\0\a\0\0\0\x64\0\0\0\x4\0\0\0\x64\0\0\0\x5\0\0\0\x64\0\0\0\n\0\0\0\x64\0\0\0\v\0\0\0\x64\0\0\0\b\0\0\0\x64\0\0\x1\x90\0\0\0\x10\x1\x1\0\x1\0\0\0\0\0\0\0\0\0\0\0\0\x64\xff\xff\xff\xff\0\0\0\x81\0\0\0\0\0\0\0\x10\0\0\0\xfa\0\0\0\x1\0\0\0\0\0\0\0\x32\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\x2\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\x3\xe8\x1\0\0\0\x64)
---
> file_view_header_state=@ByteArray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\0\xff\xff\xff\xff\x1\0\0\0\0\0\0\0\0\0\0\0\x10\xf8\xff\0\0\0\r\0\0\0\n\0\0\0\x64\0\0\0\v\0\0\0\x64\0\0\0\b\0\0\0\x64\0\0\0\t\0\0\0\x64\0\0\0\x6\0\0\0\x64\0\0\0\a\0\0\0\x64\0\0\0\x4\0\0\0\x64\0\0\0\x5\0\0\0\x64\0\0\0\x3\0\0\0\x64\0\0\0\xe\0\0\0\x64\0\0\0\xf\0\0\0\x64\0\0\0\f\0\0\0\x64\0\0\0\r\0\0\0\x64\0\0\x1\x90\0\0\0\x10\x1\x1\0\x1\0\0\0\0\0\0\0\0\0\0\0\0\x64\xff\xff\xff\xff\0\0\0\x81\0\0\0\0\0\0\0\x10\0\0\0\xfa\0\0\0\x1\0\0\0\0\0\0\0\x32\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\x2\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\x3\xe8\x1\0\0\0\x64)
130c130
< file_naming_format="$noop(\n########################################################################\n#                                                                      #\n#  Picard File Naming Script                               2020-11-15  #\n#  Bob Swift [rdswift]                                                 #\n#                                                                      #\n#  License: GPLv3.0                                                    #\n#                                                                      #\n########################################################################\n#\n#  This script... (cut for brevity)\n\n\n$noop(\n########################################################################\n#                                                                      #\n#  End of script.                                                      #\n#                                                                      #\n########################################################################\n)\n"
---
> file_naming_format="$if2(%albumartist%,%artist%)/\n$if(%albumartist%,%album%/,)\n$if($gt(%totaldiscs%,1),%discnumber%-,)$if($and(%albumartist%,%tracknumber%),$num(%tracknumber%,2) ,)$if(%_multiartist%,%artist% - ,)%title%"
174c174
< rename_files=true
---
> rename_files=false

So, there is definitely something different about the “header_state” preferences, but just a little bit – other than that, there’s nothing significantly different.

But, I replicated this three times so it seems repeatable.

Any way to tell if one of those preference states has something unexpected in the “@ByteArray”, I wonder?

It certainly doesn’t mean anything to me that ‘v’ becomes ‘xe’, ‘n’ becomes ‘t’, etc.

I guess I can paste the above issue into the MusicBrainz Jira to file a ticket that the “bad” Picard.ini is crashing [freezing] the app.

1 Like

if it is the naming script you may have to go without it. if i paste it in on my intel mac it does not freeze even if i quit Picard. it may be to do with that you are using an M1 mac. some 64 bit programs don’t run that well on them.

you can check your ram/cpu usage those macs don’t have a lot u may be maxing it out somehow

My suspicion is that this is another incarnation of freezes we have been fighting with since Picard 2.0. But actually we are just about to release Picard 2.6 beta 1 real soon, and this is supposed to fix the freezes. If your issue is the same it will be fixed. It would be great if you could test this and verify if it is solved.

The plan is to have the 2.6 beta builds available later today if all goes well, but definitely this week.

1 Like

Great! I will look for the beta release.
I hadn’t considered that the auto-parsing of the naming script could be crashing (even if the code is good).

I notice that 2.6.0b1 is available from the download page, but I don’t think it was announced anywhere?
Is this a release you would like to see tested, or could/should we wait for 2.6.0b2 which I also already saw referenced somewhere?

Yes, that could be tested. I already wrote @dishawol about it.

The beta 1 turned out to be kind of an internal beta. Just as we had the releases ready AcoustID went down, and we thought it would be kind of pointless to have a widespread announcement and ask for testing when such important functionality was unavailable.

There have been some additional improvements and we will have a beta 2 soon, that we then will also publicly announce again.

4 Likes

Picard 2.6 Beta 2 is now available, see https://blog.metabrainz.org/2021/03/06/picard-2-6-beta-2/

@dishawol Please let me know if this fixes the issue. If not, please provide the naming script and maybe also tagger scripts that you are trying to configure and which seems to cause the problems.

3 Likes

I could now reproduce this issue on my mac mini, but only with the 2.5.6 release, not with the 2.6.0b2.

I think this really is a special variant of the deadlock issues we have addressed for Picard 2.6. The core issue is very generic and could cause freezes in various situations, even though users mostly experienced it when editing tags or saving options.

1 Like

Hi, sorry for the very late reply but 2.6 completely fixed the issue for me and I’ve had no further problems. Thank you and the team.

3 Likes

@dishawol Thanks for the feedback, great it works for you. May I ask how Picard is in general performing for you on Apple Silicon?

Just asking because I have no ability to test on Apple Silicon and it might take a while until we can provide a native build of Picard. Ideally we would of course provide a universal binary with support for Apple’s ARM, but for now we’ll have to rely on the Intel builds. Apart from lack of hardware this mostly comes down to Picard’s dependencies having support for Apple Silicon (most importantly Python 3, PyQt 5 and PyInstaller).

4 Likes

I should have replied sooner, sorry.

But, yes, can confirm, Picard 2.6 through, now, 2.6.4 have worked just great on Apple Silicon (Mac Book Air, M1 chip, now running Mac OS 12.0.1.)

Thanks for all that you and the contributors do!

2 Likes

this should already be possible as of PyInstaller 4.6, please have a look here: macOS multi-arch support

so I hope you guys get busy implementing this humanely asap. apple will not keep Rosetta 2 around for ever i’m afraid…

PyInstaller is the least problematic part. The essential part is Qt. Official Apple ARM support for this is available with Qt6 and we will look into the ARM support once we have migrated to Qt6.

2 Likes