MinimServer Forum

Full Version: Album Art Oddity?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

don't treat this as a priority, as I have a workaround/solution in line with my normal practice. This is more for info, and out of "puzzlement".

I've edited this after further intervention. Please don't try to progress - see bottom of post.

Minimserver 2 latest version.

I usually enable artwork via the "folder.jpg" method, and this for both album and tracks is quite acceptable to me.


I have obtained a few new downloads with embedded artwork in each track. These particular albums display the expected artwork (at both album and track level) in the Control Point (more than one used) but don't display artwork within the renderer (a Cyrus Lyric - which normally displays art at track level).

Retaining the "folder.jpg" and removing all the embedded artwork (every track), however, fixes the issue. (and in fact due to circumstances, one of the albums only had embedded artwork in one of the tracks, but with the same result).

I can't see anything out of the ordinary with the embedded art, (500x500 and 800x800 jpg), though maybe I should play a bit more with my own embedding.

Anyway, as I say, I'm happy with what I've got now, but confused as to the issue.


The issue was consistent across my latest downloads. It was checked several times. Deleting embedded art immediately fixed in all cases.

So, I reinstated embedded art from a different source, at slightly lower resolution - it then worked OK. I then reinstated the original album art and resolution - worked OK??!

Patently, this is not something that can be diagnosed at distance, and it's working to my satisfaction now. Difficult to understand why, though. (Library has been rescanned at every change.
If any track in an album has embedded art, this is used (for the whole album) in preference to folder.jpg. To override embedded art with an external file, you can use albumname.jpg instead of folder.jpg. See this section for full details.
Thanks, Simon, I went through that section carefully before posting anything.

As I said, I can live with the current situation (totally acceptable) but am confused.

Much of my library has emanated from ripped CDs, and these end up with no embedded art, and I've always used folder.jpg as a quick way of getting the result I wanted.

In this case, I have some downloaded albums that do have embedded art, all the same but in each track. I still added a folder.jpg, though. That resulted in art being displayed (at album and track level) on the control point(s), but not (as has been the norm) on the renderer (which only displays at track level anyway).

It was consistent behaviour, and checked carefully. I edited the embedded art out of one of them (it had it only on one track, for reasons I understand but are not relevant). That then gave the expected displays at both CP and renderer. Editing all the "track" art from the next one had exactly the same effect.

But, subsequently retaining the folder.jpg and re-adding embedded art to the tracks (first at a reduced resolution, then at the original 800x800) didn't re-introduce the problem!.

Patently, the editing, or the processing of the art, might have made some difference, but as the CP display has been as expected throughout (with only the renderer displaying odd behaviour) I are confused.

There has been a rescan between each change. The artwork doesn't get cached separately and retained across rescans, does it? (It's about the only straw of explanation I can clutch at).

File it away as a memory in case something similar is raised, but I appear to have acceptable results at the moment. (albeit by a confusing path).

I do note that, as downloaded, the last one I tested has some very odd numbering of tracks and discs (being multidisc). It just might be screwing things up a bit, even though it navigates and plays OK. (No minimserver log issues).
It sounds like the original embedded artwork was incompatible for some reason with the renderer's display capability. When you replaced the embedded artwork after changing the resolution (twice), the artwork had been changed into a format that the renderer was able to display.
It does; I'm not sure that anything I did would have changed the original format of the art, though I suppose a few copies and some tag-editing could have had some effect.

Anyway, it's working now as expected desired, so enough said.

(I almost start doubting the original symptoms, but it was checked and rechecked as non-displaying, and only (immediately) started working when I did some editing).
Reference URL's