Picard 2.3.1 is available, please see:
7 Likes
Great, thank you guys.
I’m sorry to have the first actual reply here being some sort of bug report.
Well, probably not an actual bug, but it’s something I have been noticing occasionally for a while, but never could put my finger on to narrow down the cause.
Until just now…
Once in a while I find that when having dragged an album or separate recordings into Picard, some tracks have not been imported. Sometimes it’s easy to miss when that happens, but when loading an album a little bit easier to spot.
Today it happened again with some tracks from an album, and after some short investigation I now saw that it is most likely because of the path length of the files.
Above a certain length the tracks are simply ignored and not loaded.
This may well be a Windows restriction that Picard can do nothing about, but I thought to mention it in case a cure is possible, or perhaps some alert can be triggered when Picard is refusing a track for this reason?
Anyway, thanks again for the hard work and the new release!
1 Like
Best place to report things like this is the issue tracker 
But this is most likely the following known issue:
For a short summary: The Windows API traditionally limits the full path length to 259 characters. As it turns out this old baggage is not easy to get rid of and Microsoft has been struggling with removing this restriction while maintaining backward compatibility for years. But it is all not really satisfying, a lot of applications don’t support this, including the ones from Microsoft. There are ways to access longer paths by adding a special prefix \\?\. And starting with Windows 10 the restriction can even be completely removed, but it still needs an opt-in by both the user / system admin (with a change to the registry) and by the applications.
I haven’t looked into what is involved to enable this for Picard on Windows 10 in more detail yet, but I think if possible the Windows 10 compatibility would be the way to go. There is some hope MS will enable this by default in future Windows versions.
But actually, even in the year 2020, you are still calling for trouble if you use long file names on Windows. Applications might or might not be able to deal with it.
3 Likes
A short note to users of the Windows Store version: The update is still in progress and waiting for approval by Microsoft. In general according to Microsoft updating an app usually is a matter of hours but can take up to 3 working days + another 24 hours for updating the store fronts.
So far we had been lucky and updates went live after 1-4 hours, but this time it seems to take a bit longer. I guess we should add a note to the release post about this in the future 
4 Likes
I understand long parth names can be problematic, so I usually already have things in place that keep them from getting too long.
The point is more that usually you will get warned when an action or a program can’t handle or accept files(s) with a long path.
(Cuetools, extracation software, backing-up/syncing over a network, etc.)
So the reason for my post is twofold:
- making other users aware this may be happpening; not all files may be loaded in Picard, without you being alerted.
- to learn if Picard could perhaps display some notification when this happens. (I checked, there’s nothing in the error log too)
I can fully understand that ‘fixing’ this (if it even can/should be fixed) would be low on a priority list and probably not worth the time and effort involved.
If you think it’s useful I can try to create a ticket for this anyway?
3 Likes
Yes please. This issue of missing notifications applies not only to your specific case of too long file names, but also for example on not supported file types. Picard will just silently ignore any file you drop on it it does not support. I am currently not sure how this user feedback should be handled (e.g. I don’t think you should get a popup), but some note about “the following files have not been imported” should be made available somehow.
3 Likes
Done that. Please check for errors or missing information? :
2 Likes
@hiccup: I have some good and bad news regarding the long file name issue.
Good news: Opening the files via Add folder or Add files works for me. This includes later saving just the tags in place.
Bad news: Drag and drop is more difficult to implement then I had expected, but should be doable. Also saving the files with renaming will currently not work. Renaming and moving will work, but Picard will honor the 260 limit and generate a truncated directory structure.
Also Windows Explorer still only handles these files partially. You can browse such paths, but it will not allow you to rename anything inside it or create new files and folders.
But overall I see some chance that we can get Picard to handle loading those files. Also I think we could add an option to allow saving longer file names. I would still disable it by default, because you can easily shoot yourself in the food with this. Getting files that even Windows Explorer can not handle anymore would be bad default behavior.
Also implementation is a bit tricky, as it boils down to multiple issues that need to be handled.
2 Likes
Bad news; I thought to try that too before I posted the issue, and for me it gave the same result.
The Windows Store update has finally been approved, the update should come automatically or can be triggered manually in the Windows Store app.
2 Likes
Here is something I observed and find a bit odd:
To replicate:
Have a substantial amount of releases loaded in the right panel. (some 20 is enough)
Select them all.
Click ‘save’.
Saving will be very slow.
Deselect all by clicking something in the left panel; saving speeds up enormously.
While saving is still in progress, quickly select all releases in the right panel again.
Saving slows down a lot again.
I think this should not be hard to replicate.
If it is, I could try to create a gif?
4 Likes
I am still experiencing this.
(Picard 2.3.2 and Classical Extras 2.0.10)
Here are two videos.
The first is a short example. At the 14 second marker I click on the left panel so to take away focus from the right panel, and you see immediately that the saving of the files speeds up considerably.
Warning: the second video is like looking wallpaper dry.
Only at the 10:44 marker I am finally able to steal the focus away from the right panel, and only then the saving speeds up.
https://www.dropbox.com/sh/6vegz0n70pbkv15/AABXAUwva6QyVt6e2HXtylJwa?dl=0
1 Like