WARNING: The binary packages provided here are built from Picard’s latest development code and might be unstable or contain bugs. Use at your own risk and always make backups of your files.
Also these builds should be considered unofficial.
To add to the above I would appreciate if Linux users would test the above AppImages. Distributing binary images on Linux is always tricky. This will not work everywhere, but it would be great if it runs on the most popular current Linux distributions.
The AppImage itself gets build on Ubuntu 20.04 and I know it works on Ubuntu 23.04. So if you are running Linux please test this and let me know whether the Picard AppImage runs on your system or not. And if not how it crashes.
I’m not very familiar with AppImage, but MusicBrainz-Picard-2.9.1-5-gddda49c6-x86_64.AppImage works for me under Debian 11.7 in a container on an amd64 Chromebook. It doesn’t run under Debian 12.1 on an armv7l/armhf Raspberry Pi 3 B+ (exec format error), but I think that’s expected since it’s an x86-64 ELF executable.
The AppImage runs on Manjaro Linux 23.0, but it ignores theme settings (note the different button order and some very low contrast button icons) and is unable to do network requests (SSL handshake failed):
GUI looks fairly okay, apart from being the wrong colour. I also don’t think it picked up the default language as it is US instead of British English.
With colour theme - it started as “default” but a swap to “system” didn’t change anything. Same with attempts to change language are ignored.
Okay - languages are “odd”. The main GUI is not changing, but it is pulling alternate error text. And even loading the file managers in the alternate language. (i.e. attempt to load a plugin and that page is now in the correct colour and language.
NOTE: My OS is British English so all Japanese text here is from Picard and if I repeated the SSL test it shows the error message in Japanese.
Thanks for all the testing. I’ll see if it is possible to make this thing work on those other distributions. The SSL issues are likely due to the newer distributions all ditching openssl 1.1. Actually I now think that I might have openssl 1.1 (unofficially, as it is no longer provided) installed on my Ubuntu 23.04 install. I’ll check, likely it will fail for me the same way if I remove that.
On Linux settings are saved in ~/.config/MusicBrainz/
Thanks for settings… notice I just updated the post about the language and colour settings. And yes - I had restarted Picard after changing language.
Also note this is a very fresh and very new install of this MX Nix.
-=-=-
Kinda silly question - why has the < Make It So! > button moved? Am I right in saying this has been shuffled on every dialog? I still have 2.8 as my daily driver and realise you have swapped button orders around. That can be really confusing for some people .
-=-=-
Sideways question while I am poking at this app today…
“Lookup CD from log file”
On Windows this opens in the application folder. On Linux it opens in the home folder.
On Windows, opening in the Apps folder is miles from where I need to be. If it could at least follow the same location the Add Folder button does this would be more useful.
Or remember where it was last opened like the Add Folder button does. Each time I exit Picard it just reverts back to the Application folder again.
The Debian 11.7 install where I successfully ran it also has openssl 1.1.1n-0+deb11u5 installed, for what it’s worth.
Just for fun, I tried it on an amd64 VM with Debian 12.1 (openssl 3.0.9-1). No X11 forwarding so I knew it wouldn’t bring up the UI, but I think it failed earlier:
Traceback (most recent call last):
File "/tmp/.mount_MusicBkUEdkd/usr/conda/bin/picard", line 4, in <module>
from picard.tagger import main
File "/tmp/.mount_MusicBkUEdkd/usr/conda/lib/python3.11/site-packages/picard/tagger.py", line 63, in <module>
from PyQt5 import (
ImportError: libGL.so.1: cannot open shared object file: No such file or directory
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/tmp/.mount_MusicBkUEdkd/usr/conda/bin/picard", line 10, in <module>
crash_handler()
File "/tmp/.mount_MusicBkUEdkd/usr/conda/lib/python3.11/site-packages/picard/__init__.py", line 112, in crash_handler
from PyQt5.QtWidgets import (
ImportError: libGL.so.1: cannot open shared object file: No such file or directory
(I don’t have libGL installed, so I’m not sure if this is expected or if the package should’ve included its own copy.)
copied my picard.ini from my v2.8.5 on the Windows box to the MX nix box. Picard fired up with it fine.
surprised to see this also means I am now logged in as me. Had assumed logins would be more tied to a device and not just a text file.
copied my plugins folder from v2.8.5 Windows to MX nix OS. Found the only plugin being listed or loaded is one I hacked myself.
Reload List of Plugins fails (assume an SSL thing).
manually trying to “install plugins…” with some of the other default plugins fails with error message (even when I point at them separately)
maybe a MX OS thing. I have the MX OS GUI set to show me hidden files (as I wanted to look into .config). When using the Plugins file open window I don’t get to see those hidden folders. So can’t see how to reach the .config folder if I wanted to…
When in my Windows config folder it made me laugh when I saw 20 old picard.ini files. Maybe add to the “Options\Maintenance” page a “Clear out old ini files” button that wipes out picard*.ini*? There were even some in there called “Picard.ini.HJxhRb” and variations… yeah, they don’t take up much room, but it will get messy
I hit SCAN on 160 FLACs knowing it would fail due to the SSL. Maybe error handling could abort when when it sees the multiple SSL fails instead of continuing to get the same error on all 160 files.
Still failed to really break it… but with no SSL it means no tagging yet. Does load up FLACs fine.
Thanks for all the feedback. Definitely more then I had expected. Please be sure I read all of the above, but I will for now only respond to a few things.
The libssl issue should be fixed, libssl1.1 is now bundled. @rhetticent This might also fix the issue you reported. Can you check.
It is definitely a requirement to have this on the system installed.
Downloading a plugin from Available Plugins - MusicBrainz Picard , e.g. the additional_artists_details.zip , and installing it manually worked for me. Does it work for you after an update (maybe it was also related to the SSL issue) or still giving an error? If yes, can you please check Help > Show Error/Debug log for details?
Don’t know MX OS. What desktop environment is it using? That can influence what file picker you are dealing with. In any way, the file picker should give an option to show hidden files. In the GNOME / GTK file picker it is available in the context menu. The KDE file picker has a small settings menu on the upper right.
Qt sets the button possitions depending on the system it is running on. Different environments have different conventions on the button ordering.
We have a ticket for this. But please keep this discussion here about issues with running the daily builds. For general feature discussion please do open tickets or open a new thread here on the forums.
That’s actually exactly right. In this case it could not find the translation files. But Picard’s translation files are only part of the story. The other parts are Qt’s default translations (e.g. for standard buttons like Ok or Cancel) and the desktop environments translations for the file picker.
I kinda guessed that was the case. Its why I swapped to Japanese as at least I know what the Cancel button looks like.
“MX OS” is MX Linux. https://mxlinux.org (Was linked in one of my earlier notes). I’m messing with it in a VM to see if I can get used to it in case I decide to bail from Windows one day.
Will attempt to rebreak the rest of the items now SSL is working… but got some calls to deal with first.
Search now works. Loading an album and downloading a ton of artwork now works.
Plugins are now back and fully listed instead of a blank screen. (I think my attempt to “install plugin…” from a folder on the desktop was failing due to them being “not compatible” versions copied from v2.8.x.x on the Windows PC)
Hidden Files - MX Linux as explained above. Have now found I need to Right Click the GUI to enable hidden files.
Moving OK buttons - that makes sense it is a per OS thing.
Will also only focus on trying to break things.
Not sure why the Tagger button not working… but I blame that on Me and OS confusion for now…
Actually that’s kind of normal. On my standard GNOME setup Qt applications also don’t take up the dark color scheme. Under KDE they do. It’s possible though to have Qt applications take up the color scheme somehow. E.g. if you install Picard’s flatpak version it will be dark if GNOME is dark. The flatpak runtime somehow takes care of that.
It somehow depends on the platform plugin being used for Qt. I once looked that up, but don’t remember the details right now.
Found the theming thing: The magic is done by having the QGnomePlatform plugin installed. On Debian based systems the package should be qgnomeplatform-qt5. Then launching Picard with QT_QPA_PLATFORMTHEME=gnome would use the color scheme set there. When running actually GNOME this would already be set automatically. Dark / light theme detection requires QGnomePlatform >= 0.9.
That won’t work with the AppImage though, unless it would have the QGnomePlatform plugin bundled. Which I won’t do. The AppImage currently uses the Qt5 binaries provided by PyQt5 from PyPI, and QGnomePlatform needs to be compiled against the proper Qt version.
That would mean essentially fully compiling Qt5 and PyQt5 for the package, and I have zero interest investing any time doing so. Also QGnomePlatform seems to be no longer maintained.
Dark mode - okay, so Gnomes don’t like being dark. Not a worry, just an observation really. (I don’t know the difference between a Gnome and KDE at this time…)
Tagger button - that was just PEBCAK. Something about the way I have Brave setup. Works perfect from Firefox.
I think most of my breakages are covered for now…
Should add I am tagging files without crashes. i.e. Picard is doing all the stuffs it should be doing. And doesn’t seem to care I though a ten CD boxset at it as that initial test.
When the “New User Warning” dialog box on screen you cannot close the app with CTRL+Q
TL:DR; details - did you realise that if you double click the app 20 times in quick succession it will spawn 20 instances on MX Linux… or at least tried to until it just jam my VM requiring me to Shutdown to get it back.
Yeah, I know, dumb… but I test dumb. Tried doing the same on Windows version and only got the single instance.
I found out that AppImage allows the user to store configuration in a folder next to the AppImage. If you create a folder with the same name as the AppImage but with .config added this will be given as config file location to the app. So in our case if you don’t rename the Picard daily AppImage create a folder MusicBrainz-Picard-daily-x86_64.AppImage.config. Picard’s config and plugins will end up there.
For more details and options see Using Portable Mode in the AppImage user documentation.
.
- I just gave it a shot and no crash on startup with Fedora 38. 
