Can't add cover art

I have tried to drag and drop cover art in 1.1 and it never sticks. Also, in 1.0 Roon use to offer multiple choices for cover art, that is now gone, or at least I can’t find it. Help please.

Click on the edit icon, Choose Edit Fields, 3rd option down is an option to add artwork.

Drag n drop has never really worked properly for me. Sometimes the cover shows up if I close and re-open the edit window. Usually now I just save the cover to the album directory as “folder” and then rescan the album.

I think this is a known issue, meaning its in the pipe for a fix, but I’ll check and let you know.

Fewer cover options sounds like a separate issue, but I haven’t seen any for a while either. Anyone else seeing this ?

That is what I do, Daniel. The point is that “drag files here” feature does not work.

I have my album covers saved in the folder as cover.jpg and I’ve never had Roon recognize those. You are saying Roon recognizes folder.jpg?

Yes, thats right. Covers saved as folder.jpg in the album directory will be picked up on a rescan.

Does cover.jpg get picked up, too?

Based on @jeremiah 's post in this thread:

I think so. But I haven’t tried it.

Does cover.jpg get picked up, too?

Yes. Images that contain “folder” “cover” or “front” in their filename are picked up. If there is only one image file in the directory, we also treat it as a cover image.

Roon defaults to using the largest square-ish image when determining the album cover. You can of course edit individual albums to use your artwork, and you can also multi-select albums and use the “Metadata Preferences” tab to set multiple albums to prefer file-level artwork, which will cause Roon to use folder/embedded images preferentially.

Thanks, Brian. As I mentioned in another thread, one of the problems I have is that my preferred artwork is sometimes different than that which is embedded in the purchased file. My experience is in that cas Roon chooses the artwork in the file and ignores the artwork in the folder.

Ok. There are a few reasons why this might happen:

  • The embedded images are larger/higher resolution than the folder images
  • The folder images do not match one of the naming schemes that we recognize (folder, front, cover OR the only image file in the directory)
  • The images are not next to the media files because you have subdirectories within your album folder structure (e.g. for disk sets).

If it’s the first problem, I recommend removing the embedded images from the files. You could also replace them with the folder images that you prefer. No use keeping around images that you don’t like.

If it’s the second problem, maybe Roon could be expanded to support the naming scheme for your files? We already support cover.jpg, but if you have other situations, some insight into what exactly the files are called might help.

If it’s the third problem, we’re working on it. Right now Roon recognizes folder images only when they appear in the same folder as the media files.

It’s number 1. Care to recommend a Mac OSX tool to batch remove cover art from a possible 30K files?

Many of our users use and seem to like Metadatics. I use it often for debugging Roon, but I’ve never been a heavy user of this type of software, so I haven’t gotten too deep into evaluating alternatives.

I fired it up, and it certainly seems to be capable of doing the operation you’re looking for.

Thanks. I switched to having the cover art files placed in the folder because that is what other programs prioritized. Does Roon see a shift in this? Is that why you prioritize the artwork in the file over a cover art file in the folder?

Roon actually doesn’t currently keep track of whether images came from the file or the folder–they are treated equally (i.e. we’re not strictly prioritizing one over the other).

The largest image with a sort-of-square aspect ratio wins, regardless of where it comes from.

This is really only a big deal with box sets and albums with alternate covers. But it would be nice to control what it chooses.

Hi fritzg,

The drag and drop problem is a known issue. No news yet as to a fix.