# \[v3.13\] Overwrite locally stored coverart fails \[Regression\]
**URL:** https://community.mp3tag.de/t/v3-13-overwrite-locally-stored-coverart-fails-regression/56823
**Category:** Fixed Bugs
**Tags:** bug-fixed
**Created:** [March 26, 2022, 6:01pm UTC](https://community.mp3tag.de/t/v3-13-overwrite-locally-stored-coverart-fails-regression/56823 "2022-03-26T18:01:47Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@ms6676749](https://community.mp3tag.de/u/ms6676749)
#### Post date: [March 26, 2022, 6:01pm UTC](https://community.mp3tag.de/t/v3-13-overwrite-locally-stored-coverart-fails-regression/56823/1 "2022-03-26T18:01:47Z")
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.
---
### Author:  [@ryerman](https://community.mp3tag.de/u/ryerman)
#### Post date: [March 26, 2022, 8:23pm UTC](https://community.mp3tag.de/t/v3-13-overwrite-locally-stored-coverart-fails-regression/56823/2 "2022-03-26T20:23:17Z")
I see the same behaviour.
"Overwrite" fails.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 28, 2022, 8:29am UTC](https://community.mp3tag.de/t/v3-13-overwrite-locally-stored-coverart-fails-regression/56823/3 "2022-03-28T08:29:02Z")
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](https://community.mp3tag.de/t/17642), [#44589](https://community.mp3tag.de/t/44589))
I'll fix it to the next release.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 29, 2022, 2:33pm UTC](https://community.mp3tag.de/t/v3-13-overwrite-locally-stored-coverart-fails-regression/56823/4 "2022-03-29T14:33:51Z")
Fixed with [Mp3tag v3.14](https://community.mp3tag.de/t/455).
---
### Author:  [@micronaut](https://community.mp3tag.de/u/micronaut)
#### Post date: [March 30, 2022, 3:07pm UTC](https://community.mp3tag.de/t/v3-13-overwrite-locally-stored-coverart-fails-regression/56823/5 "2022-03-30T15:07:06Z")
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?
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 30, 2022, 4:06pm UTC](https://community.mp3tag.de/t/v3-13-overwrite-locally-stored-coverart-fails-regression/56823/6 "2022-03-30T16:06:20Z")
> [@micronaut](#):
>
> 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?
Yes. It's another regression — I've re-opened this bug report.
Thanks for reporting. I'll fix it to the next release.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [April 2, 2022, 5:34pm UTC](https://community.mp3tag.de/t/v3-13-overwrite-locally-stored-coverart-fails-regression/56823/7 "2022-04-02T17:34:38Z")
This should now be fixed with [Mp3tag v3.14a](https://community.mp3tag.de/t/455).
---
### Author:  [@ms6676749](https://community.mp3tag.de/u/ms6676749)
#### Post date: [April 3, 2022, 7:10pm UTC](https://community.mp3tag.de/t/v3-13-overwrite-locally-stored-coverart-fails-regression/56823/8 "2022-04-03T19:10:16Z")
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
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [April 3, 2022, 8:22pm UTC](https://community.mp3tag.de/t/v3-13-overwrite-locally-stored-coverart-fails-regression/56823/9 "2022-04-03T20:22:28Z")
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!
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [May 3, 2022, 8:23pm UTC](https://community.mp3tag.de/t/v3-13-overwrite-locally-stored-coverart-fails-regression/56823/10 "2022-05-03T20:23:11Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.