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.
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.
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.
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.
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.
@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.
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.
@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).
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.
