Emby 4.8 is still ignoring embedded cover art in Music Library

[wordlover 104]

A surprise finding/bug (?) in the Emby TV app offers more data re: suboptimal behavior of Emby in handling of Music library Album covers. I accidentally noticed that the Emby TV app (tv.emby.embyatv, v. 2.0.98g) does NOT display some cover images that the Emby Android app (3.3.66) and the Emby Web interface do display. Example -  noticed an album without cover image in the TV app (4th album below, Ramones, "1-2-3-4- Die"), but which DOES display album coverin Web and Android apps.

Emby TV:

 

Android app 3.3.66:

 

Emby Web interface:

 

I cleared cache on TV app, restarted it, and still found same result. So I investigated and found that there is no cover.jpg/folder.jpg in that Album directory. Adding a 'cover.jpg' and rescanning the Ramones folder then properly showed a cover on TV app. Great! But why initially did two apps show a cover image but the TV app does not? If that information is presumably on the server, why would different apps display the same album differently?

To start fresh with a different album, I tested the eighth album, "Leo Kottke 6 & 12 Strong Guitar", which originally displayed correctly in all three apps. When I looked at the "Primary" image for that album, it turns out there were two images. And when I deleted one (apparently imported from 'cover.jpg'), then the TV app showed a blank album cover. 

 

 

 

 

Checking the file system, the cover.jpg FILE was deleted. Manually re-creating a cover.jpg returns all 3 apps to the same correctly album cover display. So this leaves several questions and issues, after updating to 4.8.3.

1. Why are there two album cover images for so many albums? More importantly, where does the 'first' one (the non-'cover.jpg/folder.jpg' one) come from - was that pulled from an external source? (For some other albums I found entirely different 'first' and 'cover.jpg/folder.jpg' album images.) Question: Why isn't TV app recognizing these (apparently) externally retrieved images, when Web and Android apps do? If that information is presumably on the server, why would different apps display the same album differently?
2. Problem: deleting the cover in Emby's Album images screen (as above for "6 & 12 String Guitar") literally deletes the cover.jpg in the album folder, not just remove it from Emby's database/display - this is not good! Even if user has delete privileges, the Album cover image screen shouldn't be able to completely delete an image file (especially since it doesn't even move it to recycling bin).
3. Question: Where in the database do these externally retrieved images reside, and how can a user make Emby override retrieved images in favor of embedded images (which is still a problem in 4.8.3)?
4. Suggestions: the Album cover image screen needs modifications, including a. the ability to see all Album images (such as those multiple ones that were listed as Primary), to decide which to use or delete, and b. change functionality so that removing an image in that screen doesn't completely delete the image file from the file system, and c. add an "Undo" function for any such deletions even just from Emby server, since once an Album image is deleted by accident or choice, there is no way to retrieve it. 

embyserver.txt

[Luke 37259]

Hi, this has been resolved for the next update to Emby for Android TV. Thanks. @ebr

[wordlover 104]

Great. And re: the other questions/suggestions/concerns? 

[Luke 37259]

Quote

Why are there two album cover images for so many albums?

There aren't, but songs can have their own images, so you might have been seeing a song image.

Quote

•  
• Question: Where in the database do these externally retrieved images reside, and how can a user make Emby override retrieved images in favor of embedded images (which is still a problem in 4.8.3)?

The best thing to do is delete the unwanted images using the web interface. Hacking the database isn't a solution because if the files are still there then future library scans will just bring back whatever you delete.

[Luke 37259]

Quote

More importantly, where does the 'first' one (the non-'cover.jpg/folder.jpg' one) come from - was that pulled from an external source? (For some other albums I found entirely different 'first' and 'cover.jpg/folder.jpg' album images.) 

I can't tell you what happened in the past, or where the file in your folder came from. You may have had it there already, or Emby may have downloaded it. If it did, then I would look at the enabled image fetchers on the library and that will most likely answer where it came from. But again it happened in the past, so the best way to move forward is to delete the unwanted image.

[wordlover 104]

That's the problem - there is no apparent way to delete those unwanted, downloaded images. They don't exist in the file system, and as you can see in the screenshots above, the ONLY option for an image to delete in Emby's image management screen is the 'cover.jpg' image.

[Luke 37259]

28 minutes ago, wordlover said:

That's the problem - there is no apparent way to delete those unwanted, downloaded images. They don't exist in the file system, and as you can see in the screenshots above, the ONLY option for an image to delete in Emby's image management screen is the 'cover.jpg' image.

How can I tell that from the screenshots? Because your posting is talking an image that used to be there that was deleted. It's also talking about multiple things which makes it hard to discern what belongs to what.

Can you please show an example of what you mean? Thanks.

[viking19 24]

You can remove all the downloaded album art at once by deleting Emby-Server\programdata\metadata\musicalbums. Then make sure the album art fetchers are all unchecked and refresh metadata, in my case the art is pulled from the tag but should also work with the art in the folder. The musicalalbums folder will not be recreated and when checking an album image there will be no dimension under the image. This works with server 4.8.3.

Edited March 5 by viking19
can't spell

[wordlover 104]

37 minutes ago, viking19 said:

You can remove all the downloaded album art at once by deleting Emby-Server\programdata\metadata\musicalbums. Then make sure the album art fetchers are all unchecked and refresh metadata, in my case the art is pulled from the tag but should also work with the art in the folder. The musicalalbums folder will not be recreated and when checking an album image there will be no dimension under the image. This works with server 4.8.3.

Thanks. The issue, though, is for those albums in my large music library that don't have either a cover/folder image file nor an embedded cover in the individual mp3s, for which I would like Emby to download cover art.

[wordlover 104]

OK @LukeI will try to be crystal clear with a new example to show how Emby is scanning albums strangely and assigning cover art inexplicably. Example: a group of albums where Emby starts off with 8 individual albums, each in their own subdirectory, each (correctly) with the same Album Artist and different Album Titles. But then when Emby does a Music Libraray Scan (when other music is addedd), Emby

1. creates a brand new .nfo file that pertains to only one of the underlying albums in the subdirectories,

2. then randomly creates and assigns a folder.jpg image from one of the albums in the set, and

3. changes the .nfo file, and

4. then makes every album have the same album cover in Emby.

Again, the album artist is identical, the album titles are unique, and everything is properly nested in subdirectories. This is not being driven by external IDs - you can see from last screen shot that there are NO extrnal IDs associated with these albums/tracks - and there is no reason Emby should be seeing these as a multidisk set (think of them as sequentially issued albums, which they are.) Yet Emby is choosng ONE of these albums seemingly randomly - first Disc 5, then Disc 8 - and creating (or copying over) a brand new folder.jpg file at the top level which is overriding all of the individual albums' cover art. Even when I correct this manually, each time I do a Music Library rescan/metadata update for any other reason, the problem with these albums appears yet again. .nfo file AND for cover art. Step-by-step screen shots below, along with Emby log. How can this be fixed?

Initial state: correct.

No .nfo or spurious cover in top directory:

Folder view in Emby looks good.

But all goes haywire when doing a new scan (I did rescan and metadat update of just that folder/subfolders, to save the hour or more it would take if I scanned the full library - results show the same problem) 

Brand new .nfo file created, but it cites ONE of the albums in the subdirectories - that's like taking a directory/subdirectories of assorted Springsteen albums and creating and assigning a new .nfo file to "Born to Run". 

Missing image: after rescan/refresh, all albums still show cover properly, EXCEPT Disc 8, which has a blaknk album cover, even thous there IS a cover.jpg in that album directory. So I go to manually add it. 

But now all of a sudden, after uploading album cover just for the uniquely-named Disc 8, Emby has created/copied it to the higher level folder and reassigned the whole set of albums to be Disc 8 in the .nfo.

And ALL the discs have now been assigned the Dic 8 cover for no apparent - and no correct - reason.

No external databases are causing this:

embyserver.txt

Edited March 7 by wordlover

[jiggity 26]

The single album showing up as multiple ones looks like you have might multiple Album Artist tags

Open the album in MP3tag and highlight everything then press Alt+T  that will show you all the tags.  you want to use ALBUMARTIST  delete the duplicates and correct the tags.

You might need to pull the files, scan then add them back before emby will recognize them correctly

You also have the wrong discogs info?
This is the page your discogs release ID goes to
https://www.discogs.com/release/29924758-Various-The-Best-Classics-On-Compact-Disc-新名曲の世界

[Happy2Play 8356]

22 hours ago, wordlover said:

OK @LukeI will try to be crystal clear with a new example to show how Emby is scanning albums strangely and assigning cover art inexplicably. Example: a group of albums where Emby starts off with 8 individual albums, each in their own subdirectory, each (correctly) with the same Album Artist and different Album Titles. But then when Emby does a Music Libraray Scan (when other music is addedd), Emby

1. creates a brand new .nfo file that pertains to only one of the underlying albums in the subdirectories,

2. then randomly creates and assigns a folder.jpg image from one of the albums in the set, and

3. changes the .nfo file, and

4. then makes every album have the same album cover in Emby.

Again, the album artist is identical, the album titles are unique, and everything is properly nested in subdirectories. This is not being driven by external IDs - you can see from last screen shot that there are NO extrnal IDs associated with these albums/tracks - and there is no reason Emby should be seeing these as a multidisk set (think of them as sequentially issued albums, which they are.) Yet Emby is choosng ONE of these albums seemingly randomly - first Disc 5, then Disc 8 - and creating (or copying over) a brand new folder.jpg file at the top level which is overriding all of the individual albums' cover art. Even when I correct this manually, each time I do a Music Library rescan/metadata update for any other reason, the problem with these albums appears yet again. .nfo file AND for cover art. Step-by-step screen shots below, along with Emby log. How can this be fixed?

Initial state: correct.

No .nfo or spurious cover in top directory:

Folder view in Emby looks good.

But all goes haywire when doing a new scan (I did rescan and metadat update of just that folder/subfolders, to save the hour or more it would take if I scanned the full library - results show the same problem) 

Brand new .nfo file created, but it cites ONE of the albums in the subdirectories - that's like taking a directory/subdirectories of assorted Springsteen albums and creating and assigning a new .nfo file to "Born to Run". 

Missing image: after rescan/refresh, all albums still show cover properly, EXCEPT Disc 8, which has a blaknk album cover, even thous there IS a cover.jpg in that album directory. So I go to manually add it. 

But now all of a sudden, after uploading album cover just for the uniquely-named Disc 8, Emby has created/copied it to the higher level folder and reassigned the whole set of albums to be Disc 8 in the .nfo.

And ALL the discs have now been assigned the Dic 8 cover for no apparent - and no correct - reason.

No external databases are causing this:

embyserver.txt 84.86 kB · 0 downloads

I will guess here as your structure and naming will break Emby structure setting of perfect creating images at wrong level.

Also folder name not matching Album name will break things also as multi cd (boxsets) are usually one album.

Folder view

 

Album

All discs merged to one album

[wordlover 104]

As noted above in this thread, I have Discogs as LAST external info source and don't want Emby to be overwriting data or images when that information already exists in the actual files. *I* didn't make that Discogs association - it isn't in the underlying files and I don't want to use it. Dear Emby - please stop overwriting! - I want to use it only for files where there is no other cover image/metadata. Priority should be embedded USER DATA first. See screenshot below - the metadata is correct and indicating DIFFERENT albums, yet Emby isn't respecting that. 

In hundreds of instances my folder name doesn't match album name - literally hundreds, including other multi-disc sets, but also plenty of folders with 10 or more albums by the one artist. Again, this ISN'T a multi-disc set EXCEPT when Emby starts monkeying around - the album titles are unique; I am not adding a Discogs (or any other external provider) ID; there is literally no image in the top level folder UNTIL Emby somehow/somwehere grabs one and makes it a BRAND NEW folder.jpg. AND that image CHANGES after each scan (it was correctly nonexistent, then it was disc 5, then it was disc   I am doing exactly what you say Emby requires, and Emby is still messing with these files. @LukeWHERE is Emby getting the brand new folder.jpg image it is putting at the top of the directory, and how do we make it stop assigning that to OVERRIDE the cover.jpg that's already IN each individual disc directory?  

Edited March 8 by wordlover

[Luke 37259]

The folders are named as if they are a multi-disc album. Therefore when you save album images or nfo metadata, it goes up a level and treats that as the album folder.

So that explains that. Try naming the CDX folders to match actual album titles, and then delete the errant files that were saved in the Persian Traditional Music folder.

[wordlover 104]

26 minutes ago, Luke said:

The folders are named as if they are a multi-disc album. Therefore when you save album images or nfo metadata, it goes up a level and treats that as the album folder.

So that explains that. Try naming the CDX folders to match actual album titles, and then delete the errant files that were saved in the Persian Traditional Music folder.

That worked - thank you very much. 

[Happy2Play 8356]

5 hours ago, Happy2Play said:

I will guess here as your structure and naming will break Emby structure setting of perfect creating images at wrong level.

Also folder name not matching Album name will break things also as multi cd (boxsets) are usually one album.

Yep as we have had this discussion before when structure and setting do not jive.

[wordlover 104]

FWIW, I did not name the folders to match the embedded data, I just changed from the "CD1," "CD2" naming to "Vol. [x] - Album info".

[Luke 37259]

7 minutes ago, wordlover said:

FWIW, I did not name the folders to match the embedded data, I just changed from the "CD1," "CD2" naming to "Vol. [x] - Album info".

Right. Anything other than cdx would have been fine

[wordlover 104]

So I have painstakingly gone through and manually extracted or downloaded cover.jpg/folder.jpg files for hundreds and hundreds of albums, since @Lukeindicates that these take precedence when there is a conflict with embedded cover images. But nope, that's not what's happening - here's one example where a proper cover.jpg is being ignored in favor of embedded image when viewing an album normally and in the ''edit images' screen.The cover.jpg is the correct (white/black) image and exists at the top level of a correctly-identified multi-disc set, while embedded cover in individual tracks is the 'wrong' (black/gold) image. Emby seemt to be doing two 'wrong' things - 1. creating album.nfo in the 'disc' one subdirectory rather than the main album directory, and 2. using the embedded images instead of what is supposedly Emby's higher priority, the actual cover.jpg file, which does properly reside at the album top-level. I edited and rescanned. Screenshots and Emby log are here. What is going on @Luke?

   

 

embyserver.txt

Edited March 15 by wordlover

[Happy2Play 8356]

But you have a structure/naming issue

Ray Charles / AlbumArtist

Genius & Soul / Album

Genius & Soul 1 / unknown

But Folder images per folder view are not neccessarily the same as Album view. 

If you want Folder views to be the same a other views ie Artist and Album you have to manually ensure folder contains images.

 

But per your structure is in not Artist/Album/Track so Emby will not play nice with folder levels.

 

 

 

 

Now a multi-disc will get merge to one album per cd x/disc x naming otherwise you have to break them out into their own albums.  Already posted example above for Elvis.

 

 

[Luke 37259]

I don't see tracks in that folder. The album folder is the folder containing tracks. If you want it to be multi-disc, then the folders need to be named appropriately as such.

So you need to choose between the following:

• Name the subfolders according to multi-disc conventions
• Get rid of the subfolders and put all of the tracks directly into the main album folder

Quote

But per your structure is in not Artist/Album/Track so Emby will not play nice with folder levels.

Ding ding ding. If you set the folder structure option to one thing, but your folders don't actually match that, then you're going to run into quirks.

[wordlover 104]

This is the opposite of the issue a dozen posts  comments above, where you told me that the folder naming forced Emby to treat Individual albums as 1 album, despite unique Album Names.

Emby is *correctly* identifying this set of discs/tracks as a single release and matching via external sources, but then isn't handling cover image based on the same understanding. I'd suggest that's something your code should handle more consistently. (If Emby can identify the right album that applies to all 5 subfolders, which is a common way actual human users organize their file systems for a 'box set', why can't Emby then ID and use the right image for.the whole album?)

In the meantime, what is the list of 'permissible' subfolder names so Emby uses the single, correct cover image properly?

Edited March 15 by wordlover

[wordlover 104]

This is the guidance from earlier, which is what is now confusing and frustrating:

"The tags will override the folders, so you could have them in two folders, but if the album name is the same they will be shown together.  In that situation, the folder name won't help sort the disks, only the "disc" tag.  If you have that, you are good to go in this respect." and below:

https://emby.media/community/index.php?/topic/94240-music-multi-cd-albums-naming-wiki-not-clear/&do=findComment&comment=975142

Edited March 15 by wordlover

[Happy2Play 8356]

But that is where views will always be affected. 

Just like I changed the Album image by putting in folder

 

inherited from first album before adding image to folder.

Album vs tracks

So Album folder will supersede track images assuming proper structure is followed.

Yes metadata can be used for this but physical structure becomes a guessing game, and images will be at wrong level as additional layers are unknown.

This is where folder view is confusing as it CAN have absolutely nothing to do with other generated views.  Now having images within said folder will have precedence if structure is applied to library or if unstructured then the images are ignored and only apply to Folder view.

[wordlover 104]

Yes, I understand. (I don't care about Folder view - I shouldn't have included that screenshot.) I'm asking @Luke how and why there is different guidance for how multi-disc SUBfolders are handled and what is the range of permissible naming. And the larger coding issue: Emby correctly identified a multi-disc album, so why isn't it also using the correct cover image, which is in the right location for the full album.