I am currently using Picard 2.10 on Windows 64bit. My music is stored on a linux server accessed via SMB.
This happens on nearly every single album (except the albums that do not have cover art downloaded), let’s use one as an example:
I have loaded an album that has previously been saved in Picard. The album is displayed indicating that all of the track require saving “Mask (15/15; 15*; 1 image)” with all of the tracks have a green recatangle for the icon.
I save the album and all looks ok "Mask (15/15; 1 image) and all the tracks have a green tick for the icon.
I remove the album and then reload it
I am back to the the same situation “Mask (15/15; 15*; 1 image)” with all of the tracks have a green recatangle for the icon.
I am not embedding art into tags, but if I disable ‘save cover images as seperate files’ the issue goes away. If I enable this option and disable ‘overwrite the file if it already exists’ the issue returns.
Does anyone else see this? Is it worth raising an issue?
Many thanks in advance for any light that can be shed on this. I am probably missing a setting somewhere!
I think that this is a long standing issue that no one has ever addressed - so I am not sure what is happening underneath the covers - but I am assuming that it does not verify the binary contents of the image art downloaded against the binary contents of the existing cover art files.
The issue is more complex than this. Generally saving cover art as files, especially if it is more then just saving a single front cover image, is pretty complex and it is often unclear how the different options should interact and comparing the expected state after saving to the current state of files needs to consider all of that. Which it doesn’t, it just compares a list of images loaded for the release to a list of images loaded from the file metadata.
Specifically the local cover art provider has some conceptional issues that are hard to fix with the current model of cover art providers. See the discussions on PICARD-1001 Rework local cover art handling by kepstin · Pull Request #1934 · metabrainz/picard · GitHub .
@zas also had stared an attempt to make the cover art handling more testable in preparation for further fixes, see
CoverArtImage: improve tests & coverage by zas · Pull Request #1502 · metabrainz/picard · GitHub . But again especially the file saving caused some unclear or undefined situations.
I think this needs a much more thorough overhaul. One key issue is that the current model for cover art providers is not really suited to handle cover art from local files (embedded in audio files or separate). The provider model was built around the idea that cover art is loaded from external sources based on the MB data for a release (e.g. loading from CAA, or the original Amazon provider). Local cover art got shoehorned into this but it doesn’t fit as it operates on information from the files not the MB release.
3 Likes