The Classical Extras plugin mentioned in the log previously was installed prior to upgrade from 2.5.2 where this error did not occur, but now seems to be in a state where it is not installed but clicking the green download arrow does nothing and as no trash can icon is visible, I cannot disable or uninstall it.
@_iorgi Strange thing. These log outputs look normal, I assume Picard launched in these cases normally?
Could you check whether https://s3.eu-central-1.amazonaws.com/artifacts.picard.uploadedlobster.com/picard-setup-2.5.4.dev1.exe fixes the launch issues?
About the classical plugins issue best is probably to remove the plugin from
There should be a classicalextras.zip file. If you remove this and install it again from within Picard the issue with loading the plugin should be gone.
Hello. I also had the error “Failed to execute script tagger” after upgrading from 2.5.2 to 2.5.3. Using the dev version has fixed the issue for me.
For everyone affected by the Windows start issues there is now Picard 2.5.4 available, see
Thanks all of you for your help getting this fixed quickly.
2.5.4 resolved my issues. Thanks so much.
Oddities when updating in Windows. Not as smooth as usual
For some reason I have been asked to re-authenticate. Odd.
Next something weird has happens to the Sorting on the right hand side. The track list is upside down - 15 to 01. I try and correct it and none of the sorts work when I click the column headers. Even added Track No and still can’t get it to sort.
Will try to see it is just this one album… but very weird.
Yep - sorting is broken on the Right hand side, but works on the left.
This is very odd, but has been reported on IRC as well. But there it went away after a restart. I can’t reproduce this at all here. It could be for specific release (in which case it would be server side), could you share a link to a release where this happens? Also does it make a difference how you load the album (directly, or as the result of matched files)?
UPDATE: I could reproduce, added https://tickets.metabrainz.org/browse/PICARD-2071 . It is a very very odd issue. For me it only happens when loading more releases at once. The more I load the higher a percentage seems to be affected. The code responsible to inserting the items into the tree view gets them in correct order, though, independent of the result. Track items themselves are supposed to not change their order.
It looks like Picard 2.5.4 only matches half of the tracks in a cluster. In the following screenshot, I selected the cluster on the left, hit “Lookup”, Picard found a matching release, but only moved half of the tracks to the right…
Upside down tracklist: It also went away after a restart for me. But this was the same initial start that was nagging to reauthenticate so I put it all down to initial madness.
I was loading a new partially tagged album, dropped into left hand side. Then a Scan to find it and move to the right. 15 tracks. And they counted 15 down to 01. Bizarre.
But anything then added to the right stayed stuck. I push something in with the TAGGER and loaded up a previously tagged file as a test. All misbehaving the same. Restarted Picard and it seemed to settle down. Now it was at least in the correct order, but the sort is borked on the right. I can sort on the left but not the right.
To repeat sort oddities: Have album clustered on the left, Click on Track No column header and it will sort track numbers. Flipping to reversed list and back again each time I click as expected. Move everything to the right - and clicking on the column headers does nothing (the little arrow swaps direction, but no change of track order) Not a bug, but a feature…
I then got distracted that evening into tagging two HUGE bootleg boxsets - 24CDs and 10CDs. Much of that involved drag and drops of clusters or single files that went well. Didn’t see any real issues.
Though AcoustID was refusing to generate fingerprints for me again - but I know that is just me not understanding it
As a follow up to the report from @wlhlm - those two huge boxset behaved pretty well. I was mostly able to drag and drop clusters into the huge list of tracks and let it land on the correct CD. Nothing missed, just sometimes matched a different track name (but that was expected) I did not dare hit SCAN as this would have caused a chaotic match of wrong releases, so I was working manually.
Just a quick note to add a Big Thanks to the devs. The ability to manipulate those huge untagged boxsets using Clusters was excellent.
Being able to drop a single Cluster onto a point on the album on the right was great. I could cleanly drag CD8 and drop it onto file number 8-01 and it would all sift into place.
This was a job that would have been havoc to a SCAN, and the lack of initial tags made the task harder. (Early on I did load up MP3TAG and get it to auto-number the tracks with disc and track numbers as I guess this is what Picard was keying from.)
Umm… I am wondering now if my clean drag n drop matches is due to that trick of tagging with track numbers.
Excellent work by the coders. Don’t let a little bug report above think I don’t miss how clever this program is. Thanks.
Can you elaborate on this? What was happening?
Issue was reported and it should be fixed by https://github.com/metabrainz/picard/pull/1716
We’ll do another point release very soon that will include the fix.
I’m having an issue with Picard 2.5.4 on Windows 10 where if I lookup my Clusters, every other track in each cluster fails to get matched to the release that loads on the right. i.e., tracks 1,3,5,7,9,11 get matched, but tracks 2,4,6,8,10,12 remain in the cluster.
edit: I see that this issue is what the reply to the AcoustID issue is.
@yindesu this isssue should be fixed in latest release.
Tracks are fixed in order, they are not sortable by design. The sorting is for the releases. I think you usually expect tracks to be shown in order of the release. It would be rather annoying to sort releases by title and automatically get all tracks in all releases also sorted by title.
I only tried to sort them because they were initially displayed upside down 15 to 01. That is what lead me to try and “fix” the issue.
Hi, I just tried installing this new version but I get the error:
“MusicBrainz Picard.app” is damaged and can’t be opened. You should move it to the Trash.
I’m using a Macbook Pro OS version 10.13.6
8 posts were split to a new topic: Long filename support in Picard on Windows 10