Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Soul_Rvr911]

I've configured Media Center to keep my cover art stored alongside my music files as folder.jpg, and not inside the tags. I've noticed that when doing a move/rename of my music to a different location, the cover art does not get moved with the music. This ends up breaking the cover art until I manually move the folder.jpg file, and then I need to cleanup the old empty directories myself.

I did a search for this issue and saw a few other people complain of the same issue, but I could find no resolution. Is this something that can be fixed? This issue and the "Convert high bitrate files" issue I posted about earlier are really the only gripes I have with Media Center.

Thanks!

[Alex B]

This has been discussed before and I agree that your request makes sense. It may seem a simple request, but in reality the issue is quite complex. The users may move only some of the files that are in a single folder or they may have files from various albums with manually linked cover images in the same folder. The users may also have other unimported files in the same folder (booklet images, rip logs, cue sheets, etc). The used renaming rule may also move files from one folder to two or more new folders.

A way to handle the issue would be to import all files and use an "all media" view for displaying also the additional files. However, you would also need to tag the additional files with at least the Album Artist and Album tags to group them properly.

[fitbrit]

I keep all my cover art in a "Cover Art files" folder. I'd extend this request to be more general; when you assign video cover art, it get's named: "Video - [name]". It would be great if we had the option to overwrite the existing cover art file when [name] is changed, rather than additional files be created.

[rhowland]

My question is about the music note that is present when there is no cover art. I see that in version 15 that this note can be displayed in at least two colors. My experience in past versions was that this note was displayed and in blue if the cover art is missing. In version 15, I now see this in at least 2 colors. What do these colors mean? Are there more than just 2. (YES, I'VE LOOKED ALL OVER THE PLACE FOR THIS ANSWER BEFORE I POST.) Thanks.

[bspisak]

This has been discussed before and I agree that your request makes sense. It may seem a simple request, but in reality the issue is quite complex. The users may move only some of the files that are in a single folder or they may have files from various albums with manually linked cover images in the same folder. The users may also have other unimported files in the same folder (booklet images, rip logs, cue sheets, etc). The used renaming rule may also move files from one folder to two or more new folders.

Agreed that this is not quite so simple, but it doesn't have to be overly complex either. If some of the files are being moved, the cover art should be copied along with them. If all the files are being moved, than the cover art should be moved as well. The cover art should be considered virtually attached to the files.

If there are other associated files in the directory, they should also be moved. Why would it make sense to move all of the audio files out of a directory and leave cover art and possibly other related information behind? It just seems silly to force me to manually clean it up. If there is truly a use case where this makes sense, make it a configurable option.

A way to handle the issue would be to import all files and use an "all media" view for displaying also the additional files. However, you would also need to tag the additional files with at least the Album Artist and Album tags to group them properly.

Sure, but adding tags to those image files is a manual process and for a large collection, quite a bit of work. Also, isn't it possible that renaming rules could utilize tag fields that aren't supported by the cover art files?

As things are now, the only way to work around this cleanly is to embed the image into the file and suffer with the bloat.