Looking at this further, the "local" cover art provider is actually just a broken mess. It's implemented in the wrong place - it shouldn't be a provider at all, since it's not something that can be loaded only based on the release metadata information.

I think, instead it should be handled by the File class, and be more in line with how cover art embedded in tags is handled. Since the presence of "local" cover art is based on proximity to a specific file; different files loaded into an album that happen to be loaded from different directories might even have different local cover art, for example.

I've been hitting this issue, or a possibly related issue, and did some debugging work to try to figure out what's going wrong.

In my case, I have the local cover art provider enabled, with highest priority. I have saving cover art embedding disabled. When I load up a track which has local cover art present, then the release is showing as "changed" despite there being no changes to save.

Looking deeper, I find that this "changed" status is indicated by the code the update method in picard/file.py where it's running the comparison self.orig_metadata.images != self.metadata.images

The local cover art images are only present in the metadata object, and are not present in the orig_metadata object. As a result, the track is marked as changed.

I suspect the solution here is that images loaded by the local cover art provider should be added to the orig_metadata object, since they are effectively "loaded from the file". That way the orig_metadata and metadata would match in this case, so there would be no changes detected.
 

I first noticed this in the downstream product Bliss, where it kept telling me to update my artwork over and over again.

I can confirm that under these conditions:

• using mp3 and wma files
• saving cover "front" into the files
• downloading other files (back, booklet, front, poster, tray) to the album folder

After saving the release, if I reload it the album is marked as "modified and complete".  Also, as Wieland Hoffmann said, running 'Generate AcoustID fingerprints' on affected file(s) resets the change indicator icon and sets the album to "unchanged and complete".

I see this has been open for several years, is there any chance of it being fixed soon?

That's really interesting and unexpected. If this is just because the files get updated it would indicate that we miss some update after certain cover art changes!?

Interestingly, running 'Generate AcoustID fingerprints' on affected file(s) resets the change indicator icon to the correct one (a green checkmark in my case).

Wieland: That's because these are two different causes, see the linked discussion. Hence I added PICARD-1696 as a separate issue.

Just to clarify since PICARD-1696 (which is specifically about ID3) has been linked: I'm also seeing this with FLAC files when not embedding cover art and only using front images on releases with only a single front image.

I added a separate issue for the problem with reorderd images

Also discussed in https://community.metabrainz.org/t/tracks-showing-changes-after-saving-and-reloading/455605/6

I could identify at least two different causes for the general issue.

I did some more testing today in Picard 2.1.0 dev2 and found out this is still happening. Additional info below:

• If you load a file that already has cover art in a local file, Picard indicates there is a change (which also causes your files to be re-tagged: https://tickets.metabrainz.org/browse/PICARD-300 + https://tickets.metabrainz.org/browse/PICARD-932).
• If you refresh the release, it will still have the checkmark even if you managed to remove the local file after your previous save