Picard as portable Windows app

There have been several requests for a “portable”* Windows version of Picard.

I started looking into this and a test build for the current 2.2.2 release is available at https://ci.appveyor.com/api/buildjobs/b4635xc49s55jsr4/artifacts/dist%2FMusicBrainz-Picard-2.2.2.exe

This provides Picard in a self contained exe file, which can directly be started from anywhere. Configuration and plugin data is placed in a folder “MusicBrainz-Picard” next to the exe.

I would like to get some feedback and testing on this. Does the application work for you? Does the application fulfill your expectations to a portable app? Would you like to see something changed?

@jesus2099 and @hiccup, as you both have expressed interest in this your feedback is especially welcomed.

*) Portable in this context means, the application can be run without installation and the application data is self contained (e.g. does not save config on the system).


This is great!
I’ll surely be testing this out. I’ll give my feedback this weekend at the latest. (or earlier if I run into any serious issues)

Call me super anal if you like but it does leave traces in the registry. :stuck_out_tongue:

HKCU\Software\MusicBrainz\Picard << empty
HKCU\Software\QtProject << you might not have control over this??

Plenty of other “portable” apps do it as well so not really a major issue.

edit: it also leaves a MusicBrainz folder in %localappdata% which appears to hold some kind of cache.


Is there any chance that this could present any problem when having both an installed and a portable Picard on your system?
Or e.g. when having three different portable installs?

Reporting back after the first testing rounds, using all the scripts and plugins same as I used them in the installed version.

Here is the list of the problems I encountered using this portable version:


Either this message got away on you, or it’s a pretty short list. :wink:


This one is interesting, because we don’t get it if running the installed version. That must have to do something with the way we handle config loading, maybe this can be fixed.

EDIT: This one is caused by the code that attempts to copy old settings formats if there are not settings. If you already have the Picard.ini for your portable installation this registry key won’t get generated. I wonder if we should ignore this part when starting with a specified ini.

As you suspect this probably cannot be controlled, that’s Qt storing some data (file dialog settings mostly in my tests). But I will take a look if this can be redirected into a file.

I think this is Qt’s HTTP cache. Same as above, I will take a look.


There seems to be a problem with loading performers.

Never mind, I accidentally unchecked something :frowning:


I have updated the portable build. Now the cache data is stored in the local folder and the MusicBrainz registry key is no longer created. I haven’t found a solution for the QtProject config yet, still not sure if this can be influenced.

The latest build can be downloaded from https://ci.appveyor.com/api/buildjobs/3cy5egc6wuneyy99/artifacts/dist%2FMusicBrainz-Picard-2.3.0.dev1.exe

Note that this is now a build from the latest development version. It contains some changes (fixes mostly) over the last version, which was based on the 2.2.2 release.


Please don’t hate me for asking @outsidecontext:

Any chance you could share a portable dev version that contains the fix for the unicode tags?
(I’ve got some time to waste coming up :wink: )

1 Like

Here we go, latest build: https://ci.appveyor.com/api/buildjobs/dccadc4jnj5ohbco/artifacts/dist%2FMusicBrainz-Picard-2.3.0.dev1.exe

I have also submitted my changes for review. As soon as the changes get merged we will have continously new portable builds of the development version. I think this also makes it easier for me to ask about feedback on specific new features.


Thanks again for your continued efforts on making Picard better and better.
(and all other developers too of course)