More > JRiver Media Center 25 for Linux

Cover Art not sticking

(1/3) > >>

Scobie:
Having a persistent – although admittedly not particularly serious – problem re getting album art to stick on some files. Going through the forum looks as though this has happened with past versions but not for a while.

All my music is stored in flac format, ranging from 44/16 to 192/24 on MC25.102 on Linux on a NAS. This issue has been around for some time. I don’t think it is related to folder permissions etc because most albums do have cover art, and they all have the same parent directory.

Occasionally, for reasons I can’t pin down, the cover art does not appear for some albums. I can manually select from file – the .jpg file is always there in the same folder – or select from internet, and the cover art is selectable and will show in the Tag sidebar (I have store in Tag selected) however the actual cover art thumbnail will either never appear in the MC display, or if it does it will only stick until I take an action, click somewhere for example, and then disappear. When this happens the image in the Tag side bar will also disappear and will now show something like <various internal images> or <various external images> or something like <cannot load image from file>.

If <various * images > is shown, and I select “View first file” it tells me there is no cover art to display.

Removing and re-importing doesn't seem to help, nor does selecting an image of a different size.

Oddly, after attempting all steps I can think of to populate the album art with no success, what I find is the Tag has actually stuck for each track. So, if I have the Tag sidebar open while clicking through the tracks the art will show up. However, the art for the album itself will not. This is also evident in JRemote or when playing locally in MC where the album art shows the default quaver symbol, but when the tracks start playing the album art is shown.

Any advice on tricks, techniques or best practices I’m missing appreciated.

Cheers

JimH:
It seems like a problem with something being read only.

Scobie:
Yes it certainly appears that way Jim but pretty sure I have ruled that out. MC imports the image files ok to write to disk and can also delete them.

RoderickGI:
It can't be a read-only issue if the image tag initially shows the correct information. i.e. The image is in the file.

The default note symbol appearing is likely a thumbnailing issue, not a Cover Art issue. But that could be caused by the Cover Art in the media files being changed by something else. Maybe Auto Import is checking the file, finds a change, updates the Library, and can't find the correct Cover Art, as indicated by the <cannot load image from file> message. If DBPoweramp or some other software used for tagging is running, it may be updating the file.

Why would that happen? If the FLAC file has more than one image file in it, as indicated by the <various internal images> or <various external images> messages, MC may not handle that correctly. Others have suggested this. You would hope that MC just used the first image it found in the file, but experience would suggest that doesn't work too well. If this is happening to specific files, open a example with a tagging application that can see multiple image tags, remove the incorrect ones, and see if that fixes the issue.

If the problem exists for files where both an internal Cover Art image is stored in the file, and there is an external Cover Art file, delete the external image and see if the problem goes away. MC may not be handling two sources of Cover Art well.

When you see this happen, refresh the Views and see if it corrects itself. If it is a transient problem, that points to files being updated by something. Or possibly thumbnailing stumbling.



--- Quote from: Scobie on September 30, 2019, 06:47:39 pm ---So, if I have the Tag sidebar open while clicking through the tracks the art will show up. However, the art for the album itself will not.
--- End quote ---

This would indicate that the thumbnail still exists in the thumbnail database, but the Cover Art no longer exists.



--- Quote from: Scobie on September 30, 2019, 06:47:39 pm ---This is also evident in JRemote or when playing locally in MC where the album art shows the default quaver symbol, but when the tracks start playing the album art is shown.
--- End quote ---

I'm not familiar with JRemote, but I don't think it uses the MC thumbnail database at all, rather it uses the internal image tag in the file. If you mean that you use JRemote to play to the MC installation, then JRemote can't find the internal image tag so shows the quaver, but when you play to MC it can find its thumbnail or the real Cover Art image, and displays that.

Does that give you some more things to check?

Scobie:
Thanks Roderick, yep all good suggestions, have already attacked the issue with most if these, with the exception of checking auto import, will have a look at that.

But in summary:
I have ensured that the folder the flac files are only contains one image file and pointed to that as the cover, no good. Additionally many if the albums that do work have more than one image file.
A view refresh has no effect save deleting the cover art image for the affected files.

Re
--- Quote --- If you mean that you use JRemote to play to the MC installation, then JRemote can't find the internal image tag so shows the quaver, but when you play to MC it can find its thumbnail or the real Cover Art image, and displays that.
--- End quote ---

Apologies this was possibly poorly worded by me, I was simply using JRemote as an example.

What I meant to indicate was the experience on JRemote aligns with that on MC itself. If I scroll through the album art on JRemote, or view the album art in MC, most of the album covers are there and those that are not display the quaver. However if I then play the album, either locally on the handheld with JRemote or locally on MC using MC itself, I see the art associated with each track as it plays. This aligns with what I see in the Tag bar. The tracks have a Tag image, the album however does not.

Navigation

[0] Message Index

[#] Next page