• 1(current)
  • 2
  • 3
  • 4
  • 5
  • 11
  •   
v18 Implemented feature request for Music library extended artwork support
#1
Updated: Implemented in Kodi 18. Dave took this request and ran with it, now the music library has complete support for extra artwork. Freely named artwork for the music library can be added to existing library items from the GUI and JSON-RPC (as described originally), plus scrapers can set extended artwork for new items and there are new advancedsettings options to identify additional artwork from the file system. Active artwork assigned from scrapers is also limited by the advancedsettings.xml configuration so each Kodi installation has a single place to configure all automatically added artwork, but the full list of available artwork is still saved for manual selection in the "Choose art" dialog.


The music library has some support for freely named artwork like the video library (for images like logos and discart), but it is missing a couple of interfaces to set this artwork: from the GUI and from JSON-RPC.

On the GUI side for music media items (artists, albums, and tracks/songs), there should be a "Choose art" button on the info window like the video library to replace the "Get thumb" and "Get fanart" buttons, which allows users to set any type of artwork for that item (screenshot of "Choose art" window in the video library).

For JSON-RPC, we need an optional param "art" for each media type method, to both get and set artwork.
A request to get all artwork for one particular artist would look like 
 
Code:
{"jsonrpc":"2.0","method":"AudioLibrary.GetArtistDetails","params":{"artistid":1,"properties":["art"]},"id":8}

And the result:
Code:
{"artistdetails": {
  "art": {
    "banner": "image://http%3a%2f%2fthetvdb.com%2fbanners%2fgraphical%2f80287-g.jpg/",
    "clearlogo": "image://https%3a%2f%2fassets.fanart.tv%2ffanart%2ftv%2f80287%2fclearlogo%2fcodemonkeys-80287.png/",
    "fanart": "image://http%3a%2f%2fthetvdb.com%2fbanners%2ffanart%2foriginal%2f80287-3.jpg/",
    "thumb": "image://http%3a%2f%2fthetvdb.com%2fbanners%2fposters%2f80287-2.jpg/"
  },
  "artist": "Code Monkeys"
  "label": "Code Monkeys",
  "artistid": 1
}}

The request and result should be similar for "AudioLibrary.GetArtistDetails", ".GetAlbumDetails", and ".GetSongDetails"; and the request will be similar but the result will be a list of items for the methods "AudioLibrary.GetArtists", ".GetAlbums", ".GetSongs", ".GetRecentlyAddedAlbums", ".GetRecentlyAddedSongs", ".GetRecentlyPlayedAlbums", and ".GetRecentlyPlayedSongs".
Comparable video library methods are "VideoLibrary.GetTVShowDetails", "VideoLibrary.GetTVShows", and "VideoLibrary.GetRecentlyAddedEpisodes".

"art" is a flat map of art type to URL/path of the artwork, image URL encoded.

To set artwork, we need a request like
Code:
{"jsonrpc":"2.0","method":"AudioLibrary.SetArtistDetails","params":{"artistid":1,"art":{"banner":"http://thetvdb.com/banners/graphical/80287-g.jpg"}},"id":8}

"art" is still a flat map, but the URL/path is not image URL encoded (or maybe just doesn't have to be). Art added this way is applied as an update to existing art, so any artwork that exists but isn't specified in this request stays as is. If the value is null, then the existing art with that type should be removed. The methods "AudioLibrary.SetArtistDetails", ".SetAlbumDetails", and ".SetSongDetails" need this param. A comparable video library method with this behavior is "VideoLibrary.SetTVShowDetails".

Posted at the request of @DaveBlake. Thanks for your time.
Reply
#2
Thank you for this nice clear request, I'll see what I can do for v18 Smile

Small issue is that at the moment only in the music library artists and albums have art, not songs. I think I will start there as a huge leap forwards, but it has started me wondering if in the longer term songs need art too? I am thinking in particular about singles rather than every track on an album having images. Then again v18 nows supports local art for song artists, so surely showing the artist image(s) for singles should be enough.
Reply
#3
TheAudioDB supports track artwork covers so that would be nice! Every popular album released tends to have 2 or 3 track covers these days for their popular singles.

Other artwork supported by TADB:

Artist
Thumb, Banner, Fanart, ClearLogo, ClearArt

Album
Thumb, CDart, Back Cover, Spine

Single
Thumb

Record Label
ClearLogo
Reply
#4
If I say that I only owned singles when I was a young child, including "A mouse lived in a windmill"  on 45rpm vinyl, then you may get how much I know about singles in the digital world. Tongue

So they have artwork, well, well....

Not making any promises for song art in v18, but I will keep it in mind.
Reply
#5
Yeah, song artwork has its uses, but if it's more trouble to implement then it can wait. Artist and album artwork gives skinners the full palette to work with.
Reply
#6
@rmrector a couple of questions (hope you are watching this):

You discuss the "art" parameter, which in current JSON types seems to be limited to thumb, poster, banner, and fanart, and does not include "clear-logo" in the set. Should that be added? I also find myself wondering if we want to limit the set and why?

Also how about the "Thumbnail" and "fanart" parameters? They are suported by VideoLibrary.SetTVShowDetails()  etc., but don't seem to do what I would expect.  Perhaps historic? In music lib we have both current selected art for the item (artist/album/song) and strings of URLs returned by scraping for possible other art held as strThumb and strFanart fields (in DB). So I would expect "Thumbnail" in JSON to add/return the string of thumb URLs, yet in video it seems just another way to add current art, same as "art" with <"thumb", URL> would do. Should I add support for these in AudioiLibrary, and what you they relate to? Any thoughts?
Reply
#7
The video db can accept "art" as a free string so you can use jsonrpc set any art. So there's only some fixed names by default and the rest is free to define. Simply specify the name of the art and the location and it will be added. The trick is to use some default we all agree on as name so skins can use it.
Get the music part to do the same
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#8
Martijn is spot on there.

In the video library, the separate 'thumbnail' and 'fanart' params are old, and have been kept around for backward compatibility (I think that's why, this 'thumbnail' has fallback behavior that rarely looks good), they've been reworked to use the art table rather than separate columns. It is past time that the video library drop these, but I just can't convince myself that we won't need at least one major Kodi version of deprecated support for them in the music library.

The video library does some fallback magic with 'thumbnail', but I don't think the music library should emulate that during the transition: 'thumbnail' should return the 'thumb' image in the art table, and if it doesn't exist then it's just null. API consumers that want to display images in a design (including skins) need to know what type of image they are getting, and 'thumb' is ambiguous enough without a fallback. I bring this up because I do want to change the "primary" image used in the music library: to 'cover' for albums and singles, and maybe 'portrait' or something for artists. I plan on posting a thread for opinions on naming conventions a bit later, but Kodi core shouldn't be concerned with the exact names chosen, beyond examples in API documentation.

One other useful thing about the art map from "Get" methods: when child items are requested, like albums and songs, include artwork from the parent artist and album, with keys like "artist.clearlogo" and "album.cover". Artwork cannot be set like this, Kodi just ignores it in the video library. "VideoLibrary.GetEpisodeDetails" gets TV show and season artwork this way (as 'tvshow.*' and 'season.*'). This can be more troublesome in the music library, with multiple artists on a track or album, and "Various Artists" albums. Just pick the first listed artist when multiple are available. "Various Artists" albums and its ilk will only be able to grab artwork assigned to "Various Artists" directly, but songs inside can have specific artist artwork if they are tagged with an actual artist.
Reply
#9
Currently the API returns fields "thumbnail" and "fanart" for artists, albums and songs, and that willl continue of course. But my thinking is that they do not need adding as valid parameters to SetArtistDetails(), SetAlbumDetails() or SetSongDetails() because those methods will all have "art" as a parameter that can be set including those types of art. Seems silly to make two ways to set the same thing.  You agree?

Yes the db will take art as a free string, and so does the JSON API in practice. But I am a little confused by the type used for the "art" field
Code:
 "Media.Artwork.Set": {
    "type": "object",
    "properties": {
      "thumb": { "type": [ "null", { "$ref": "Global.String.NotEmpty", "required": true } ], "default": "" },
      "poster": { "type": [ "null", { "$ref": "Global.String.NotEmpty", "required": true } ], "default": "" },
      "banner": { "type": [ "null", { "$ref": "Global.String.NotEmpty", "required": true } ], "default": "" },
      "fanart": { "type": [ "null", { "$ref": "Global.String.NotEmpty", "required": true } ], "default": "" }
    },
    "additionalProperties": { "type": [ "null", { "$ref": "Global.String.NotEmpty", "required": true } ] }
  },
Looks to me like an attempt (or intention) to limit the values JSON will accept. But here my JSON knowledge runs thin, so unless Montellese appear to explain or someone else knows, I'll just be happy that any free text works as type.
Reply
#10
There is now a branch in my repo with the API changes needed for this. I need a prior PR to be reviewed by Montellese and merged before raising it. But I can get a build up if you would like to test out the API additions.

On the GUI side the artist/album info dialog needs some rework for other reasons (e.g. moving the fetch of data onto a separate thread from the main UI) so I would look at the button change as part of that.

Moving forwards Smile
Reply
#11
Excellent news! This fills a huge gap in music functionality that I've always hoped would get brought up-to-date.

Can't wait to try it out.

Thanks!
Reply
#12
Rock on, thanks!

Agreed that we do not need "thumbnail" and "fanart" as explicit params on the "Set*Details" methods.

On the JSON-RPC side, I think the "additionalProperties" signifies that it also accepts other properties not explicitly listed.

If it's not too much trouble for a Windows 32bit build I would appreciate it. I have just the worst time trying to recompile it after a couple of months.
Reply
#13
(2017-11-21, 22:53)rmrector Wrote: If it's not too much trouble for a Windows 32bit build I would appreciate it. I have just the worst time trying to recompile it after a couple of months.
No trouble at all Smile
Test build for win32 on the mirrors JSONSetArt (other platforms accordingly)

This build includes other breaking JSON changes described here 13051 (PR) to GetAlbums, GetAlbumDetails, SetAlbumDetails, SetSongDetails (mostly sorting out properties). I feel "breaking" makes it sound so dramatic when it really isn't.

Feedback welcome.
Reply
#14
A PR has now been raised for this work 13101 (PR)

Testing (by any interested JSON API consumers) and feedback will aid the merge process
Reply
#15
Ryan, thanks for the response on Github. I am repeating it for discussion here because it could get a wider audience and much as I love long discussions, some people don't like too much on Github. Also I would probably make thumb loader changes on a separate PR to JSON changes, just because it makes code review easier.
 
Quote:Thanks Dave! After some testing this looks good, but uncovers some troubles with the music thumb loader (which also affects skins), and I think I've narrowed it down to CMusicThumbLoader::FillLibraryArt. One album art is not grabbed for songs if the song has any of its own artwork. Two, only 'fanart' is grabbed from artists and album artists for songs and albums. Both should be simple to fix, but artist artwork needs cached like album art, which needs something like getArtistId and getAlbumArtistId on the infotag, and I'm just not sure how to get that info.
I am going to need to you to expand on what you are trying to do and want to happen.

I have questions about what Kodi does with music artwork by default, over what addons can make it do subsequently. It sounds like for songs you want the thumbloader to fetch song art, album art and artist art - lots of thumbs per song (if they exist). And fanart for producers, composers and musicians? Last sentence I don't understand at all.

Spoon-feed me with examples Smile
You did that with API and look it got implemented.
Reply
  • 1(current)
  • 2
  • 3
  • 4
  • 5
  • 11
  •   
 
Thread Rating:
  • 0 Vote(s) - 0 Average



Logout Mark Read Team Forum Stats Members Help
Implemented feature request for Music library extended artwork support00