Picard daily builds

Something I wanted to have for a long time is finally here. I have setup public daily builds for Picard.

There are currently two builds available:

  • Linux AppImage
  • Windows portable

macOS builds might get added in the future. The latest builds are always available on Release MusicBrainz Picard daily builds · phw/picard-daily · GitHub

The builds are updated at least once a day.

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):

$ ./MusicBrainz-Picard-2.9.1-5-gddda49c6-x86_64.AppImage 
qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_base_id
qt.network.ssl: QSslSocket: cannot resolve SSL_get_peer_certificate
I: 10:52:34,155 config._save_backup:379: Backing up config file to /home/xxxxx/.config/MusicBrainz/Picard-2.9.0a1.ini
D: 10:52:34,174 tagger.__init__:327: Starting Picard from '/tmp/.mount_MusicBY1wQL2/usr/conda/lib/python3.11/site-packages/picard/tagger.py'
D: 10:52:34,175 tagger.__init__:328: Platform: Linux-6.1.41-1-MANJARO-x86_64-with-glibc2.37 CPython 3.11.4
D: 10:52:34,175 tagger.__init__:330: Versions: Picard 2.9.1, Python 3.11.4, PyQt 5.15.9, Qt 5.15.2, Mutagen 1.46.0, Discid discid 1.2.0, libdiscid 0.6.4, astrcmp C, SSL OpenSSL 3.0.9 30 May 2023
D: 10:55:58,733 webservice/ratecontrol.get_delay_to_next_request:122: ('picard.musicbrainz.org', 443): First request
D: 10:55:58,734 webservice/ratecontrol.increment_requests:147: ('picard.musicbrainz.org', 443): Incrementing requests to: 1
qt.network.ssl: QSslSocket: cannot call unresolved function SSL_get_peer_certificate
D: 10:55:58,903 webservice/ratecontrol.decrement_requests:155: ('picard.musicbrainz.org', 443): Decrementing requests to: 0
E: 10:55:58,904 webservice._handle_reply:511: Network request error for https://picard.musicbrainz.org/api/v2/plugins/ -> SSL handshake failed (QT code 6, HTTP code 0)
E: 10:55:58,904 ui/mainwindow.set_statusbar_message:468: Error loading plugins list: SSL handshake failed
D: 10:55:58,919 webservice/ratecontrol._out_of_backoff:231: ('picard.musicbrainz.org', 443): oobackoff; delay: 1000ms -> 1000ms; slow start; window size 1.000 -> 2.000

(Let me know if you need more information, but the rest of the debug output is pretty standard.)

Comparison with the official Picard package on the right:

1 Like

MX Linux in a VM. Started up the appimage. Nothing exploded.

Then got similar responses to above (including the empty plugins list)

And get a similar fail on SSL when I hit the search:

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.


It kinda knows it should be using the alternate language… but doesn’t fully commit to it

File Naming Script Editor even managed to get the buttons renamed…

1 Like

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 :upside_down_face:.

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.

1 Like

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

1 Like

Observation notes (don’t really need replies):

  • 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 :grinning:
  • 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.

AppImage team says this should not be bundled: https://github.com/AppImageCommunity/pkg2appimage/blob/14c255b528dd88ef3e00ae0446ac6d84a20ac798/excludelist#L38-L41

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.


The locale issue is now also fixed.

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.

1 Like

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.

Language now works. (but still no dark mode)

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…

That one should work. Check the listening port on the lower right if it doesn’t and try explicitly opening any musicbrainz.org release page with the tport=.... parameter (set to the actual port number). I also can only recommend GitHub - phw/musicbrainz-magic-tagger-button: Browser user script to automatically enable the green tagger button on musicbrainz.org . As I frequently have several picards installed and run with all different configs for testing I never really now on which port picard ends up listening on. But with that user script it just works.

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.

1 Like

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.

With Qt6 things will change anyway.

1 Like

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.

1 Like

You got it, boss :saluting_face: - I just gave it a shot and no crash on startup with Fedora 38. :+1:


Awesome. Thanks for the feedback.

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. :rofl:

Yeah, I know, dumb… but I test dumb. Tried doing the same on Windows version and only got the single instance.

This is why I found CTRL+Q don’t work

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.