Emby 4.8 is still ignoring embedded cover art in Music Library

[wordlover 103]

Good news: new Emby 4.8 is now at least recognizing embedded cover images. Bad news: when there isn't a formal folder.jpg or cover.jpg, it isn't using them as its own album cover image. Example, with images below. On initial Music Library import (everything here is from a fresh & clean & new 4.8 install and Music Library creation and scan), despite every track in this directory having the same embedded cover image, Emby went to Discogs and grabbed some weird, wrong cover. When I manually went in and deleted the wrong cover, then the correct, embedded cover image (same in any of the tracks) immediately appeared, meaning Emby is correctly recognizing it. Could Emby please - as discussed many times previously over several years in prior threads - use this order of priority for cover art:

1. cover.jpg
2. folder.jpg
3. [filename].jpg if filename is identical to album directory name
4. [maybe any other .jpg in that directory?]
5. embedded cover art from first track in that directory, if it exists 
6. only if none of the above exist, reach out to external providers (Discogs, etc.)

YES, this will occasionally grab a wrong image (especially in 'various artist' albums), but that's still going to lead to incorrect album covers much less often than under current scheme. 

 

 

[Luke 37151]

Hi, please read the last page of this topic here: 

Thanks.

[wordlover 103]

Despite what it says in that thread, it is not apparently the case that "if there is no album artwork in the folder then the 1st found embeded image is used as the album artwork (inherited)" - my files DO have an embedded cover image, but Emby is nevertheless retrieving another image and using that instead. I don't want to turn off all album art retrieval, for any albums that have neither a cover.jpg/folder.jpg nor any embedded cover art in one or more of the files. Why isn't/can't Emby use the order above, especially "6. only if none of the above exist, reach out to external providers (Discogs, etc.)"?

[wordlover 103]

I am seeing this again and again as I scan through my brand new and very large 4.8 Music Library. Emby IS correctly scanning and recognizing embedded album cover art, but it is choosing to ignore that in favor of retrieved cover art. This isn't very "YOUR MEDIA, YOUR WAY."  When I manually delete the retrieved album cover, the underlying, already scanned-and-recognized cover art is instantly displayed correctly. And again, it's not a solution to just turn off external retrieval, because there are albums for which there is no cover.job/folder.jpg nor an embedded image in any of the song files, and that's exactly when Emby should be retrieving an image from an external provider. Please implement some version of this album image ordering - at least use external providers LAST.

1. cover.jpg
2. folder.jpg
3. [filename].jpg if filename is identical to album directory name
4. [maybe any other .jpg in that directory?]
5. embedded cover art from first track in that directory, if it exists 
6. only if none of the above exist, reach out to external providers (Discogs, etc.)

 

[Happy2Play 8321]

Will have to test but images do honor folder images but dependent on structure setting.

Music Images

Images are supported in both artist and album folders, as well as images embedded within audio files. Below is a table of the supported image file names:

Supported image extensions are jpg, jpeg, png and tbn.

Several image types support multiple file names. They are listed in the order that they're checked for.

Image Type	Supported file names
Primary	folder.ext
	poster.ext
	cover.ext
	default.ext
Art	clearart.ext
Backdrop	backdrop.ext, backdropX.ext
	fanart.ext, fanart-X.ext
	background.ext, background-X.ext
	art.ext, art-X.ext
	extrafanart (subfolder)/fanartX.ext
Banner	banner.ext
Disc	disc.ext
	cdart.ext
Logo	logo.ext
Thumb	thumb.ext
	landscape.ext

 

[wordlover 103]

Yes. The point is in instances (among my thousands of folders) where there isn't an image file that matches any of these - I am saying (as others have also been saying for a lonh time) that Emby should use other sources via priority 3, 4, 5, 6 above.

[Happy2Play 8321]

So in the end per other topics track extraction should be before provider image.

 

 

But personally, image extraction is saved to folder when I tag all my media before ever importing into Emby.

[wordlover 103]

Reasons why Emby should implement this soon:

1. An app like Emby should focus on honoring user preferences and effort whenever possible
2. Many of us have spent days and weeks and longer carefully polishing our large music libraries and adding cover images to the music files themselves, and to have them literally ignored and in fact overridden by a music app like Emby is ridiculous
3. It's not that hard to alter Emby code to implement this.
4. As Happy2Play indicates, "embedded images" are already retrieved and respected and used as Song Image Fetcher - please just add it to album & artist fetcher and let users decide what order they prefer.

 

[Luke 37151]

Quote

• An app like Emby should focus on honoring user preferences and effort whenever possible
• Many of us have spent days and weeks and longer carefully polishing our large music libraries and adding cover images to the music files themselves

Hi, Emby fully supports and honors your user preferences and embedded images.

[wordlover 103]

Luke this simply isn't true. I have posted example after example. As Happy2Play has posted about as well, preference for Embedded Images is an option for Songs only, NOT for Albums. My music library - since importing from scratch into a brand new install of 4.8 - is filled with Album cover images that were retrieved from one of the external services (which I want to use when there are no images embedded or otherwise for an album and it's songs) and which are being displayed INSTEAD of the embedded cover images in every single one of the song files. Why are you refusing to acknowledge this?

[Happy2Play 8321]

17 minutes ago, Luke said:

Hi, Emby fully supports and honors your user preferences and embedded images.

OP does wants embedded extraction to supersede online providers.  Only use online providers if no folder or embedded image exists.

 

Personally, I ensure there is a folder image when embedding images, so this is never an issue.  Unless structure is not honored then folder images are irrelevant.

Edited February 24 by Happy2Play

[Luke 37151]

Sorry, if it wasn't clear. The topic that I linked to acknowledges an issue and mentions a build with a fix as well as what to do when you have the build.

[wordlover 103]

Could you repost the link - I do not know what you are referring to.

[Luke 37151]

On 2/21/2024 at 1:22 AM, Luke said:

Hi, please read the last page of this topic here: 

Thanks.

 

[Happy2Play 8321]

9 minutes ago, Luke said:

Sorry, if it wasn't clear. The topic that I linked to acknowledges an issue and mentions a build with a fix as well as what to do when you have the build.

Don't follow either but it is order of precedence with providers superseding embedded per the image above.

 

  

 

[Happy2Play 8321]

1 minute ago, Luke said:

 

But don't believe this has anything to do with new beta 2.1.04 app

[Luke 37151]

4 minutes ago, Happy2Play said:

Don't follow either but it is order of precedence with providers superseding embedded per the image above.

 

  

 

I'm pretty sure the two topics are about the exact same thing, despite the title of the other one.

[Happy2Play 8321]

Just now, Luke said:

I'm pretty sure the two topics are about the exact same thing, despite the title of the other one.

But there is no fix as the server/web client will fetch online image before looking at embedded images per library settings, correct?

My example per that topic.

 

[Luke 37151]

1 minute ago, Happy2Play said:

But there is no fix as the server/web client will fetch online image before looking at embedded images per library settings, correct?

My example per that topic.

 

There was a fix yes.

[Happy2Play 8321]

2 minutes ago, Luke said:

There was a fix yes.

So it does not exist in the server/web client?

But will retest in 4.8.1.0 and 4.9.0.5.

[wordlover 103]

What on earth are you talking about @Luke!? I am running 4.8.1 and there is literally no setting in a Music Library to extract OR set priority for embedded images as Album cover. And the server is still overwriting embedded images with retrieved images. Are you not paying attention to what two of us are amply demonstrating?

[wordlover 103]

I beg all Emby staff to read that thread. Luke is gaslighting several of us paying users or just not paying attention to what we are amply demonstrating. This is infuriating.

[wordlover 103]

@ebrCould you or another Emby staffer please read this thread. Luke is not helping nor accurately responding to clear, documented, illustrated reports about this problem.

[Luke 37151]

The fix is in the 4.9 beta channel and will be back ported to 4.8.2.

[wordlover 103]

You could have shared this information many hours and many posts ago, but thank you for finally tacitly acknowledging what @Happy2Playand I have been reporting. Delighted to hear it will be addressed in a stable release soon.