[v3.13] Overwrite locally stored coverart fails [Regression]

As shown in the screenshot below, I attempted to have tmp jpg coverart, obtained from the itunes websource, overwrite a locally stored artwork file "00. Front.jpg" by clicking the overwrite option. However, when I checked the directory, the old (smaller resolution) artwork file remained there. I also made sure that the local artwork wasn't read only or protected.

I tried checking the tickbox underneath the album art when clicking overwrite, but that only embedded the album art into the file (local album art remained unchanged) and something I generally avoid because I don't embed albumart in my files personally.

I also tried placing album art from a different album as "00. Front.jpg" in the local directory and saw the same result: the locally stored album art remained and was not overwritten despite selecting the option to overwrite it.

This function worked fine in v3.12 and every version before that as far I can remember.

Steps to reproduce:

  1. Look up album using any websource that pulls album art.
  2. Select "overwrite" when presented with the notification window shown in the picture below.

I see the same behaviour.
"Overwrite" fails.

1 Like

Thanks for pointing! It's a regression from v3.12 introduced while working on

NEW: added option to don't show the message that asks for keeping existing cover art again at Tag Sources confirmation dialog. (#17642, #44589)

I'll fix it to the next release.


Fixed with Mp3tag v3.14.


I noticed something after updating to 3.14: When using "Save image to disc", it is indeed replacing the existing artwork as it did before.

However, when I choose "Extract Cover" and then manually select the file to replace (see screenshot), it is not replacing it even after I confirm it. In fact, even when I try to save any artwork via "Extract Cover", it is not writing any file at all on the disc. Can someone confirm this behaviour?


1 Like

Yes. It's another regression — I've re-opened this bug report.

Thanks for reporting. I'll fix it to the next release.

1 Like

This should now be fixed with Mp3tag v3.14a.

Thanks Florian. I just wanted to add that v3.14a release fixed the first regression described by the other "extract cover" does not result in the found album artwork writing to the folder. Also, v3.14a fixed a second regression that I encountered where no album artwork is written to the the album folder when "save image to disc" is selected and no cover art (specified by filename) is found in said folder. Looking back, it seems that these two regressions are maybe one of the same.

Best regards

Overwriting locally stored files was fixed with v3.14 whereas saving cover to discs when no cover was there yet was fixed with v3.14a.

Complex code doing lots of different things — should be fine now (and much easier to maintain in the future). Thanks for confirming the fix!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.