Album cover art not showing up for new albums

[marktaff 12]

I added 9 new CDs to my collection today, and the cover art for none of them is showing up.  Emby recognizes the albums and tracks correctly. The cover art for all my previously-existing CDs is fine. Most new albums just show a blank CD icon. Three show an artist image in place of the cover art.  The cover art is embedded in every flac file, as well as in a file located "...flac/Artist/Album/Artist - Album - Cover.jpg".  The filesystem permissions and user/group all seem fine (same as for existing albums without this issue).

I've tried refreshing the metadata (including images) on a couple of them, with no effect.  I've also tried restarting the client, no effect. Tried restarting the server, so effect. Server is 4.6.2.0 Linux, client in emby-theater Linux 3.0.15. When I go to 'edit images', there is no option to tell it to just read it from the audio file.

Any ideas what is wrong and how I can fix it?  Thanks!

[Carlo 4331]

Hi, take a look at our music naming convention for proper graphic naming that will be recognized by Emby.
https://support.emby.media/support/solutions/articles/44001159113-music-naming

[marktaff 12]

2 hours ago, cayars said:

Hi, take a look at our music naming convention for proper graphic naming that will be recognized by Emby.
https://support.emby.media/support/solutions/articles/44001159113-music-naming

Thanks for the reply, but that link isn't helpful.  Quoting the link: "Images are supported in both artist and album folders, as well as images embedded within audio files". 

All my files have embedded jpg coverart.  It works fine for the 741 CDs previously (over years) put in emby, it is just the last batch of 9 CDs that doesn't work (and I have another 50 to add to my collection).  I'm using the same scripts that I wrote in 2014 to manage my music collection. The only recent change to those scripts has been to add two more custom tags to the files to store actual album and song original years in tags that MusicBrainz won't overwrite with wrong data (and to correct MusicBrainz when it writes wrong data to the Original Year tag).

The actual JPEG coverart file isn't there for emby's benefit.  It is there for my scripts to maintain the embedded coverart in an application-agnostic way.

Clementine is a Linux music player I use as part of my process for importing CD into my collection; all the embedded coverart shows up fine there.  I've also used ffprobe to ensure the embedded coverart is there.

Any other ideas?

[Carlo 4331]

Hi, could you zip up one of the CDs and give me a link to download it to test with?

[marktaff 12]

Thanks. I can PM one album for testing (would take two messages due to data size).  Does that work for you?

[Carlo 4331]

Sure

[Carlo 4331]

I renamed your files to match our naming convention so it looks like this:

And I get this:

Edited June 30, 2021 by cayars

[marktaff 12]

If you have some plugin or such that makes the image look like a CD case, that is the right image (even if the aspect ratio is distorted).  If not, that in't the correct image.

In either event, it appears it is not reading the embedded image.  Renaming the cover image file to destroy the unique information in the filename is a non-starter.  Again, that image is not there for Emby's benefit.  Emby is not the only software that uses this file tree. Prior to 4.6, Emby had no problems reading the embedded coverart.  Just a month or two ago, I added about 25 CDs to my collection, and it read the embedded cover art just fine.

If it matters, I recently crossed over the 10,000 song threshold.

I've just upgraded from 4.6.2 to 4.6.3 and rescanned the library, no effect.  This seems to be a regression in 4.6.  Reading the embedded coverart is a critical feature. Hopefully this bug is fixed soon.

[Carlo 4331]

Yes I'm running the coverart plugin.

That's the same image in the tracks itself.

My Music library is set to 

So if I'm going to add files on my system they should be in the artist\album\track format.  Only the "perfect" options will load artwork from disc.

You really should rename your files to that format as every software I've ever used will use that format and is what they prefer. Using the same folder name for both artist & album if frowned upon.

[marktaff 12]

Quote

So if I'm going to add files on my system they should be in the artist\album\track format.  Only the "perfect" options will load artwork from disc.

Everything is in artist/album/filename format. The filenames are [artist] - [title].  I am not going to destroy vital disambiguation information (artist) from the filename.  I do *not* want emby to load the artwork from disc.  I want emby to load the embedded artwork, as it has done up until 4.6.  That image file is in the folder for the sole purpose of maintaining and validating my collection, as well for for fixing my collection if unruly software removes or modifies the embedded artwork. It is *not* for emby, and I make no promises I won't move them all to a single "good covers" folder if maintaining my collection makes that prudent.  If emby happens to use that image file as the cover, it won't hurt anything, but it should be using the embedded image--as the documentation expressly states it does, and has done until now.

Clearly, Mp3tag v3.0.7 can read the embedded coverart.  Emby needs to do the same.

Has this grievous bug been brought to the attention of the developers? I feel like I'm getting the run-around here; like you are intentionally ignoring everything I say.  Or perhaps like level-one tech support telling me to reboot my computer.  Quite frustrating.

[Carlo 4331]

The 2 zip files you provided were not in this format of artist/album/track naming.

Compare what you sent to what I showed above for obvious difference in naming.
Emby will pull the album cover art from the tracks.

But really it doesn't matter that much in 4.6 because it's 100% tag driven.

[marktaff 12]

Quote

Emby will pull the album cover art from the tracks.

But it isn't.  It is supposed to, but it doesn't. That is the bug I have been trying, and obviously failing, to report for the past 21 hours!

I sent you an album, zipped as requested.  I did not send you my folder structure--I just zipped the relevant files.  Stop trying to pretend my folder structure or filenames are the problem.  I wasn't lying to you about my folder structure.  My structure is *explicitly* permitted by the emby docs, and has worked flawlessly for *years* for over 700 CDs.  Emby is properly finding and identifying my files, and properly extracting all the tag data--*except* for the embedded coverart.

@Luke Please help.  This guy seems to be willfully ignoring the bug I'm trying to report.

[Luke 37219]

Is the image embedded into the audio file?

[Carlo 4331]

Here is straight from the zip file with no file renaming after removing the old album and refreshing the library.

Emby loads this just fine.

 

[Happy2Play 8351]

On 6/28/2021 at 5:41 PM, marktaff said:

...flac/Artist/Album/Artist - Album - Cover.jpg

Still confused on this as this folder image has never technically been supported but @Lukewould have to comment if "anything  - Cover.ext" should work.  Is the issue of Emby not extracting/displaying a proper folder image?

[Carlo 4331]

1 hour ago, marktaff said:

But it isn't.  It is supposed to, but it doesn't. That is the bug I have been trying, and obviously failing, to report for the past 21 hours!

I sent you an album, zipped as requested.  I did not send you my folder structure--I just zipped the relevant files.  Stop trying to pretend my folder structure or filenames are the problem.  I wasn't lying to you about my folder structure.  My structure is *explicitly* permitted by the emby docs, and has worked flawlessly for *years* for over 700 CDs.  Emby is properly finding and identifying my files, and properly extracting all the tag data--*except* for the embedded coverart.

@Luke Please help.  This guy seems to be willfully ignoring the bug I'm trying to report.

But it is 100% tag driven and loads from the files regardless of naming.
The only reason I renamed/reorganized them the first time was to follow the "perfect" layout and to have the cover art named correctly.

[Carlo 4331]

Just now, Happy2Play said:

Still confused on this as this folder image has never technically been supported but @Lukewould have to comment if "anything  - Cover.ext" should work.  Is the issue of Emby not extracting/displaying a proper folder image?

It loads the image from the flac files just fine.

@Happy2Play I'll forward the 2 zip files over to you so you can test.  I'm sure the album will load fine for you also.

[Happy2Play 8351]

Yes library structure option will determine folder image usage also.

[Carlo 4331]

I actually was thinking backward on the first test thinking he wanted it to read the cover art file which is why I rename it.

But after re-reading what he said I removed the album, rescanned lib.
Then unzipped the 2 zip file without touching them and rescanning the music library again.

Works just fine for me reading the cover art from the flac files.

I added both Luke and Happ2Play to the PMs with the files so you can try this also.

[Happy2Play 8351]

Will have to do more testing but folder image is not used.  But would have to know and test library options.  But suspect naming but will have to test also.

2021-06-29 18:29:29.342 Debug App: Running MusicBrainzAlbumProvider for Amigo
2021-06-29 18:29:29.351 Debug App: Throttling MusicBrainz by 250ms
2021-06-29 18:29:29.609 Info HttpClient: GET https://musicbrainz.emby.tv/ws/2/release/?query=reid:4a296fa5-623b-493a-89df-2c75e52a5c86
2021-06-29 18:29:30.051 Debug App: Running AudioDbAlbumProvider for Amigo
2021-06-29 18:29:30.057 Info HttpClient: GET https://www.theaudiodb.com/api/v1/json/2139078587215309723505/album-mb.php?i=ebe42c16-9f35-39c0-bcdb-fdfc13f30d5f
2021-06-29 18:29:30.526 Debug App: Running MusicAlbumImageProvider for Amigo
2021-06-29 18:29:30.529 Debug ProviderManager: Saving image to C:\Users\Media\Desktop\Stable\programdata\metadata\musicalbums\Amigo-musicbrainzalbum-4a296fa5-623b-493a-89df-2c75e52a5c86\folder.jpg
2021-06-29 18:29:30.541 Debug App: Running BaseGenreCleaner for Amigo
2021-06-29 18:29:30.544 Debug App: Running MusicBrainzImageProvider for Amigo
2021-06-29 18:29:30.549 Info HttpClient: GET http://coverartarchive.org/release/4a296fa5-623b-493a-89df-2c75e52a5c86

2021-06-29 18:29:35.356 Debug ImageProcessor: Image encoding to C:\Users\Media\Desktop\Stable\programdata\cache\images\resized-images\3\3ff6eccf-e995-16ee-3ae2-37fc3acb9d43.webp took 24ms for C:\Users\Media\Desktop\Stable\programdata\metadata\musicalbums\Amigo-musicbrainzalbum-4a296fa5-623b-493a-89df-2c75e52a5c86\folder.jpg

 

[Carlo 4331]

Did it load ok for you @Happy2Play as far as album and cover art like I showed?

[Happy2Play 8351]

Just now, cayars said:

Did it load ok for you @Happy2Play as far as album and cover art like I showed?

Yes as it grabbed the same online image.  So folder/Album view shows the image from C:\Users\Media\Desktop\Stable\programdata\metadata\musicalbums\Amigo-musicbrainzalbum-4a296fa5-623b-493a-89df-2c75e52a5c86\folder.jpg.

[Happy2Play 8351]

You can see images from exact track being extracted also.

2021-06-29 18:42:37.398 Debug App: Running FFProbeProvider for C:\Users\Media\Desktop\Videos\Music - emby metadata\David Ball\Amigo\David Ball - Amigo.flac
2021-06-29 18:42:37.398 Info MediaProbeManager: ProcessRun 'ffprobe' Execute: C:\Users\Media\Desktop\Stable\system\ffprobe.exe -i file:"C:\Users\Media\Desktop\Videos\Music - emby metadata\David Ball\Amigo\David Ball - Amigo.flac" -threads 0 -v info -print_format json -show_streams -show_format
2021-06-29 18:42:37.429 Debug MediaProbeManager: ProcessRun 'ffprobe' Started.
2021-06-29 18:42:38.404 Info MediaProbeManager: ProcessRun 'ffprobe' Process exited with code 0
2021-06-29 18:42:38.411 Debug App: Running BaseGenreCleaner for C:\Users\Media\Desktop\Videos\Music - emby metadata\David Ball\Amigo\David Ball - Amigo.flac
2021-06-29 18:42:38.411 Debug App: Running AudioImageProvider for C:\Users\Media\Desktop\Videos\Music - emby metadata\David Ball\Amigo\David Ball - Amigo.flac
2021-06-29 18:42:38.411 Debug ProviderManager: Saving image to C:\Users\Media\Desktop\Stable\programdata\metadata\library\66\668714b9b5601c87a4510d4d4f782f22\poster.jpg
2021-06-29 18:42:38.417 Debug App: Running FFProbeProvider for C:\Users\Media\Desktop\Videos\Music - emby metadata\David Ball\Amigo\David Ball - Just Out of Reach.flac
2021-06-29 18:42:38.418 Info MediaProbeManager: ProcessRun 'ffprobe' Execute: C:\Users\Media\Desktop\Stable\system\ffprobe.exe -i file:"C:\Users\Media\Desktop\Videos\Music - emby metadata\David Ball\Amigo\David Ball - Just Out of Reach.flac" -threads 0 -v info -print_format json -show_streams -show_format
2021-06-29 18:42:38.424 Debug MediaProbeManager: ProcessRun 'ffprobe' Started.
2021-06-29 18:42:39.290 Info MediaProbeManager: ProcessRun 'ffprobe' Process exited with code 0
2021-06-29 18:42:39.292 Debug App: Running BaseGenreCleaner for C:\Users\Media\Desktop\Videos\Music - emby metadata\David Ball\Amigo\David Ball - Just Out of Reach.flac
2021-06-29 18:42:39.292 Debug App: Running AudioImageProvider for C:\Users\Media\Desktop\Videos\Music - emby metadata\David Ball\Amigo\David Ball - Just Out of Reach.flac
2021-06-29 18:42:39.293 Debug ProviderManager: Saving image to C:\Users\Media\Desktop\Stable\programdata\metadata\library\c1\c1d752509a31447105e930d1ca622bd5\poster.jpg

Will do some more testing on a clean build since existing image in metadata folder will always be used as it is by mbzalbumid.  Not sure exactly but may have been from my first test and did not properly clear all existing metadata on second test.

[marktaff 12]

12 hours ago, Happy2Play said:

Still confused on this as this folder image has never technically been supported but @Lukewould have to comment if "anything  - Cover.ext" should work.  Is the issue of Emby not extracting/displaying a proper folder image?

Thanks.  This jpg image has nothing to do with the problem.  I do *not* expect emby to use that image--it is not in that folder for emby's use.  Pretend it doesn't exist.

The issue is that emby is not reading the embedded coverart from the files, like it is supposed to.  For the 9 albums I added two days ago, emby doesn't display the embedded coverart--it just show a CD icon for most (for 3 it shows an artist image).  Emby is supposed to use the embedded artwork, as it does for the 741 CDs I added prior to 4.6.

[marktaff 12]

And here is my folder structure, to prove everything is in artist/album/tracks hierarchy.

There are obviously two bugs here.  The first is whatever bug caused emby to not read the embedded artwork, (I'm guessing on import).  The second bug is that emby doesn't validate its database to ensure it is correct and consistent.  And there is no command I can issue that tells emby "hey, you screwed up on this album, ignore what you think you know and try importing this album from scratch".

folder.structure.txt