Picard 2.4 Beta 1

Tags: #<Tag:0x00007f7d009b5760>

We have released a beta for the upcoming Picard 2.4. More details in the blog post:


Some first impressions:
The issue of very slow saving when lots of albums are selected seems resolved, very nice.
The issue of having an error thrown when using $title in a script where a tag is empty seems resolved and is working now.
The auto-suggest feature when creating a script is very nice.

One difference I observed which may or not be intentional:
While having ‘Ignore MBIDs when loading new files’ unchecked, that works when adding a folder, but when adding the tracks within a folder it doesn’t anymore. (it does for previous versons of Picard)

A suggestion:
In the left panel, the 'Track No. column is a bit wider than necessary. But if you drag it to make it smaller, the digits disappear. The alignment could probably be improved to make that possible.

Great work outsidecontext, Zas, et al. Thanks for the continued work and improvements!

(Win 10)


Thanks a lot for testing.

That’s a regression, likely caused by the refactoring of the loading process. I added PICARD-1864 to track this. @gabrielcarvfer could you take a look at that?

I can’t reproduce this. Even in the smallest width I can set there is still room for 3 digits, with 4 digits or more an ellipsis gets added:


Could you show a screenshot? Is this maybe on some High DPI screen or something?

No scaling/high dpi.


You are actually not scaling the column but resizing the entire pane. The column is still wider, and you’ll get scroll bars at the bottom to scroll the entire table horizontally. That’s actually nothing we can change. As you have put this column to the most right position you can’t really see the real width of it, as it will expand to fill in the available space. But it will not shrink under it’s actual size.

If you grab slightly to the left of the pane separator and drag to the left you can actually resize the column to the minimum size. What we could do is making the default width of this column a bit smaller.


Ah yes, indeed.
I am accustomed to other software where you can have the right side of the most right column anchored to the side of the panel. In that manner the content is never covered when making the panel smaller.
Being used to that, I didn’t even think of trying something else here.

1 Like

I didn’t manage to reproduce the MBID issue. :confused:

Tried loading folders and files with the setting disabled, then tried again with it enabled, then tried changing the setting while loading and all of them worked as expected. Not sure if I missed something.

I’ve made some changes to speed up reading the settings that could cause this kind of error, but I’ve debugged line by line and didn’t catch anything wrong.

EDIT: I did miss something. Target != None. Thank you for testing. :slight_smile:

1 Like

Strange indeed, I can reproduce this here. E.g. using the file browser on the left I drag a folder, and the corresponding album gets loaded on the right. I drag a single file and it stays in “Unclustered” files. If you cannot reproduce, could this be a timing issue? I’ll try to debug this also.

1 Like

Nevermind, using the file browser did show the issue. Weird.

Another strange thing: Using the “Add files” menu action does not add anything.

Update: Now it works again, I have not idea what was happening. But also this ads files correctly with loading the album. I’m highly confused now :smiley:

Found my mistake. Moved before checking.


Selecting on file browser + add folder/files was supposed to load things?

No, it opens a file dialog. But nevermind, works as expected. I think it was me being tired.

Was hoping it would fix the issue with Picard opening on MacOS Big Sur. App seems to load but nothing shows up and it says “Application Not Responding” in the dock. I know I’m using a beta so maybe Beta 2 =)

Likely not, unless someone can test and debug this and do the necessary build changes :frowning: I myself can only test on macOS 10.12 and 10.15. And there is a separate issue about running on 10.13, which I also can’t test but I would like to see fixed more urgently then issues on a pre-release OS.

Also it’s quite likely we need to wait for an update of one of the components we use (Qt5, PyQt5 or PyInstaller) for macOS 11 compatibility.