MediaMonkey forum

There's a couple of things I'd like to see changed about how MM4 is handling file naming for image files.
Firstly, the behaviour for linking to files has changed as discussed at http://www.ventismedia.com/mantis/view.php?id=8188. After folder.jpg is taken MM is going to name the files so they can be usefully reused if the db is lost, so wouldn't it be handy if the album art type was appended to the name (e.g. cover_back, media_label, etc.) and probably more useful than <album name>, <album name>_2, etc. The two don't need to be mutually exclusive, but I remember in MM3 if a file was named cover_back and was associated as album art it would be automatically recognised as a back cover.
Secondly, if I want to tag an album that has already been infested with WMP 200x200 / 75x75 images, I open the 'edit album art' dialogue, delete those images and start adding new ones. Currently this won't create me a folder.jpg because one exists in the folder, even though I'm trying to get rid of it by deleting it and replacing it. I can delete the images, close the dialogue box, agree to the images' deletion, then go back in and add the new images, but that seems less slick. If I've deleted all of the associated images and then add a new one I'd like a "replace folder.jpg?" option or similar.
[edit]
Related to this, if I'm trying to link to an existing folder.jpg that's in the correct place, I can't do so, MM4 suggests <album>.thm or if I change it to folder.jpg creates folder_2.jpg. I know it seems like this situation shouldn't arise but it does. e.g. I have a music video from a CD of a music album, I want to give the video the same thumbnail as the songs get so I point to folder.jpg and the above occurs.
Also, if any image exists in the folder, MM defaults to <album>.thm, even if no Folder.jpg exists. Assuming it's one album in the folder I'd like MM to offer Folder.jpg unless that's already taken, regardless of whether other images exist in the folder.
Thanks

Tommycrock,

Thanks for the feedback. I've added a link to bug 8188, and will take this into account when we change it for 4.1.

-Rusty

Thanks very much. Since I wrote that I've also been thinking that the .thm extension isn't so great either . It means that the files won't open with their native apps (I might like to open .jpgs with one app and .pngs with another). Also, if I associate .thm with an image editor, some of them (e.g. IrfanView) object to the files having the wrong extension. I expect other media players would be less likely to find *.thm than *.jpg, etc. If you're trying to do something that will increase the ability for other programs to use the album art files, IMHO you should use their standard extensions. However, perhaps it's a different matter for video thumbnails (don't have them currently so don't know)?
[edit 13-01-12]
Actually, even MM doesn't see it as an image. I just tried adding album art to one album from another but they aren't listed as image files so I can't.
[edit]
Continuing this, now I've played around with video, I just want to check that there's a reliable way of getting them back if it all goes wrong - and using them in another media player/manager. I'm assuming the thumbs are named using CRC hashes of the address as in XBMC? Do their names get updated in the case of renames/moves? If we can't configure the folder specifically (discussed http://www.mediamonkey.com/forum/viewto ... =6&t=55666), how would we share these with another application. Since the user is (rightly) allowed to choose the frame that thumbnails are generated from (rather than just automatic) it's important those don't get lost.
This placement of thumbnails for videos (and them getting a png extension) makes me question the changes to music art further, since it doesn't seem to affect video, which seemed to be part of the rationale?