0017640: Deleting and then adding new artwork cause the new arwork to always be added as .thm - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0017640	MMW 5	Tagging / organizing (properties / auto-tools)	public	2021-03-08 19:11	2023-09-28 13:59

Reporter	rusty	Assigned To
Priority	urgent	Severity	minor	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	5.0
Target Version	5.1	Fixed in Version	5.1

Summary	0017640: Deleting and then adding new artwork cause the new arwork to always be added as .thm
Description	In cases where the user has first deleted all linked AA for track(s) (belonging to a single album and stored to a single directory), if the Add Cover > Options are configured to save the first image as a jpg, the Add Cover UI will force the image to be saved as a THM. (the workaround is to delete the image, click OK in the Properties dialog, and then add the new image). 0 Ensure MM has default tag settings of: - Save image to file folder - First image per album/series: folder.jpg - Format for multiple images: $if(<Album>,<Album>,<Filename>).thm 1 For a set of tracks belonging to a single album within a single folder, Open Properties > Artwork 2 Delete existing linked images 3 Lookup image, and in the Add Cover dialog, Save image to file folder --> The new image cannot be saved as folder.jpg even though it is the first and only image! A solution is a bit complicated because the first image (e.g. folder.jpg) can be linked to multiple files. So if only a single file i the album/directory is selected, and the user deletes the artwork and then adds a replacement for only that single file, MM would in fact end up changing it (i.e. deleting it, and adding a replacement) for all of the files to which it links. Perhaps for such cases, MM could prompt the user something like: 'The change in artwork at path/albumart.jpg will apply to x other files on the album. Do you want to proceed?'
Additional Information	Reported at: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=98562 Possible solution that was rejected: a) Adding an 'Apply' button. Not great because it's really just an improvement on the current workaround. It doesn't solve the problem of unmet user expectations and it also adds an often-confusing button to the UI (confusing because of its implication that 'Previous'/'Next' buttons don't commit changes).
Tags	No tags attached.

Fixed in build	2800