Prefering scraped album art to embedded images
#1
A feature I have been asked for, and happened to have my head into the right part of the code to be able to implement quickly (don't fall over in shock) is the option to prefer scraped album art over that embedded in music files.

While some of us embed high resolution album covers into our music files, and would not want the scraper to replace them, others have old poor quality art in there and would rather see the new pretty art that the scraper can fetch. In v17 and below that means manually selecting the album art from the list of scraped possibilities to replace the embedded art that Kodi uses by default.

To recap, in v17 and below the album thumb (cover) art is automtically allocated in the following priority:
  1. Local folder art e.g. folder.jpg in album folder, or however named in <musicthumbs> in advanced settings
  2. 1st embedded art found while processing the music files for that album
  3. 1st remotely scraped artwork
This means that if the album has local folder art, or art embedded in at least one music file, the scraped art does not get automatically used.

The song thumb (seen on player OSD and song lists) art is automtically allocated in the following priority:
  1. Art embedded in that music files provided that all songs on an album do not have the same embedded art
  2. Falls back to local album folder art e.g. folder.jpg
  3. Falls back to common embedded art that is the same in every music file in the album
  4. Falls back to 1st remotely scraped album artwork
This means that if the embedded art is a jumble, say one music file with a different image, then the musc playerOSD will show the individual embedded art not the album cover however it is set.

With the new setting "Prefer scraped album art" enabled (it will be disabled by default), the automatic way album art is allocated will be:
  1. Local folder art e.g. folder.jpg in album folder, or however named in <musicthumbs> in advanced settings
  2. 1st remotely scraped artwork
  3. 1st embedded art found while processing the music files for that album
When scraping remote sites, either when adding a music source,on library update or when clicking the "Refresh" button on the album information dialog, the first art found will replace any use of embedded art for the album. Note it does not remove the embedded art, or change the music file in any way, just what Kodi holds as the current album thumb. 

If you follow the above logic you will notice that what gets seen on the player OSD is can also be effected by the "Prefer scraped album art" setting. The implicit fallback behaviour that happens when all the embedded music file art is the same AND there is no local album folder art, means that the album art is shown. Initially this album art would be that common embedded art from the music file, but with "Prefer scraped album art" enabled it could be automatically replaced with scraped art.

You will also realise that the the player OSD will contnue to show the embedded song art when it varies between songs on the album. You might say "but my embedded art is a mess, I don't want to see it ever". Well my immediate response is fix your tags - if you tag it then Kodi will use it! It is better to have that art than nothing, so I do not skip scanning embedded images, nor do I want to come up with a convoluted algorthim to decide when to use it and when not. Another sensible solution for those that don't want to ever see embedded art is for the skin to optionally show album.thumb on the OSD explicitly (rather than use the implicit fallback of song thumb to album thumb),  so ask your friendly skinner Smile

I have done the work and am ready to PR it, but comments welcome
Reply
#2
Yep this is a long held feature request that has thrown up some weird artwork over the years. Great stuff!

With the content and artwork available on metadata sites these days, it really is nice to have a prefer online artwork option.

Am I right in thinking that Kodi only reads it once and creates a thumbnail going forward in the userdata folder? I never bothered with embedded artwork as I assumed it was a performance concern as I have all my music on a slower NAS device.
Reply
#3
I ALWAYS put the art of my song in mp3/flac tags (it's only a question of taste).
In this case, I just need to use "Prefer scraped album art" in off right?

I'm also AWAYS have a folder.jpg in song folder (this is the same art that i embeed on my files).

Cheers.
Reply
#4
Looking forward to seeing this feature.  Thank you!
Reply
#5
Awesome work Dave, giving users a choice is always welcome. And now I know why some of my artwork looks different than what the folder.jpg is.
Reply
#6
(2018-04-23, 15:13)docwra Wrote: Am I right in thinking that Kodi only reads it once and creates a thumbnail going forward in the userdata folder? I never bothered with embedded artwork as I assumed it was a performance concern as I have all my music on a slower NAS device.
On scanning Kodi stores the full music file name as the location of the embedded image in textures database, and like all images fetches it into cache (files in the folders userdata/thumbnails/[0 to f]) the first time the GUI displays it. For embedded images that means reading the image from the music file metadata, which I guess could be slower than reading a folder.jpg. The usual cache hash checking the applies, so the image is only read from tags once (or again if the music file changes) so not a terrible performance concern.
 
(2018-04-23, 15:39)sagrath Wrote: I ALWAYS put the art of my song in mp3/flac tags (it's only a question of taste).
In this case, I just need to use "Prefer scraped album art" in off right?

I'm also AWAYS have a folder.jpg in song folder (this is the same art that i embeed on my files).
Like me you don't need this new feature, so yes just leave "Prefer scraped album art" disabled.

The folder.jpg takes precedence, so although it is the same as embedded art it is what Kodi is using.
 
(2018-04-23, 18:11)Powerhouse Wrote: And now I know why some of my artwork looks different than what the folder.jpg is.
Yes, I'm sure quite a few users will have accidentally ended up with mixed embedded art and not realised that therefore the player is showing that embedded art not the folder.jpg album cover they see in the album lists.

PR raised PR13812 test build to follow.
Reply
#7
PR13812 has now merged, and this new option will be available in the next nightly - enjoy Smile
Reply
#8
(2018-04-29, 18:11)DaveBlake Wrote: PR13812 has now merged, and this new option will be available in the next nightly - enjoy Smile

Hi Dave,

Love this feature, thanks Smile - but its not working in the Kodi 19 nightly. I replaced some embedded album art in some test files then added them to my library. With this setting enabled, it still uses the embedded art.

https://kodi.wiki/view/Settings/Media/Mu..._album_art

If i open Information > Refresh, nothing changes. If i open Information > Choose Art > Thumbnail - the "Remote Art" is listed, although it takes a few seconds to populate the first time.

I am using the Generic Album Scraper but have tried the Universal Album Scraper. My files are correctly tagged with Picard. If i don't embed album art, the correct album art is scraped.


I want to leave the album art embedded for when i copy the files to my phone but the online art looks so much better in Kodi. Smile

Any ideas?
Reply
#9
This feature was introduced for Leia v18? so is it still working ok for the v18 builds? in other words is this just an issue with v19 nightlies. Is this the first time you've run a v19 nightly? have you used past nightlies? if so have any of the past nightlies worked ok for you?

Could you provide a debug log_file (wiki) taken while you scrape some files.
Reply
#10
@WinR I'll take a look and see if I can reproduce, I am doing some other stuff with music art at the moment anyway. No need for log etc., thanks for reporting.
Reply
#11
(2020-07-28, 12:02)DaveBlake Wrote: @WinR I'll take a look and see if I can reproduce, I am doing some other stuff with music art at the moment anyway. No need for log etc., thanks for reporting.

Thanks Dave Smile

Happy to provide the debug log if required - let me know.
Reply
#12
Humm, odd. Not reproduced with v19, but on v18.7, I'll have to dig in.
Reply
#13
Oops, looks like when I added the facility to automatically fetch any art type for artists and albums PR13848 I partly broke this feature. The design flaw is that it will only attempt to replace the embedded thumb with a scraped one if there are other types of art missing too. So if you have an album art whitelist setup (in advanced settings, GUI setting is WIP), with say "discart" or "spine" then the "Prefer online album art" setting works, but if not then it doesn't. At least that is what I think you found @WinR, does that match with how you were using it, and then found it was not working?

This will get fixed in v19 alpha2, until then @WinR having a whitelist is a workaround.
Reply
#14
(2020-07-31, 14:16)DaveBlake Wrote: Oops, looks like when I added the facility to automatically fetch any art type for artists and albums PR13848 I partly broke this feature. The design flaw is that it will only attempt to replace the embedded thumb with a scraped one if there are other types of art missing too. So if you have an album art whitelist setup (in advanced settings, GUI setting is WIP), with say "discart" or "spine" then the "Prefer online album art" setting works, but if not then it doesn't. At least that is what I think you found @WinR, does that match with how you were using it, and then found it was not working?

This will get fixed in v19 alpha2, until then @WinR having a whitelist is a workaround.

Thanks Dave, I'll check it out and let you know.
Reply

Logout Mark Read Team Forum Stats Members Help
Prefering scraped album art to embedded images0