Retreive more artwork from kodi

[nico1080]

Currently the thumb field in setup.toml only retreive the cover via MusicPlayer.Cover or VideoPlayer.Cover infolabels.

More artwork is also accessible:
https://kodi.wiki/view/Artwork/Accessing_with_skins_and_JSON-RPC#Access_.22parent.22_artwork

eg tvshow it is possible to get poster for the season or tvshow instead of the episode thumb: Player.Art(tvshow.clearlogo)", "Player.Art(season.poster)"
Same thing for music, artist fanart instead of album cover"Player.Art(album.thumb)", "Player.Art(artist.fanart)", "Player.Art(albumartist.clearlogo)"

Would it be possible to specify the infolabel to be retreived in the thumb section? (eg; Player.Art(artist.fanart) instead of MusicPlayer.Cover)

Ideally one could also display several artworks via several thumb section in the same layout of setup.toml (eg artist + album fanart)

And also have fail back in case of artwork not available. (eg: if no artist fanart display album cover)

the folowing setup.toml would display: big artist fanart + small default cover or only big default cover if not artist fanart is available

[A_LAYOUT.A_DEFAULT.thumb]   #display artist fanart  if Player.Art(artist.fanart) not empty
posx = 3
posy = 4
size = 300
center_sm = 1
infolabel  = "Player.Art(artist.fanart)"
display_ifnot = [ "Player.Art(artist.fanart)", "" ]

[A_LAYOUT.A_DEFAULT.thumb]   #display MusicPlayer.Cover if Player.Art(artist.fanart) empty
posx = 3
posy = 4
size = 300
center_sm = 1
infolabel  = "MusicPlayer.Cover"
display_if = [ "Player.Art(artist.fanart)", "" ]

[A_LAYOUT.A_DEFAULT.thumb]   #display MusicPlayer.Cover in other position  if Player.Art(artist.fanart) not empty
posx = 350
posy = 4
size = 100
center_sm = 1
infolabel  = "MusicPlayer.Cover"
display_ifnot = [ "Player.Art(artist.fanart)", "" ]

[mattblovell]

The additional InfoLabels could be added for retrieval via the TOML lists that are now available.

An element_* callback function could then make use of the new additions. Such callback functions are free to contain any code, including additional JSON-RPC calls (if necessary) or HTTP retrievals. The only functionality not inherently available is the caching that get_artwork() implements, but even that is now somewhat moot given the split between "static" and "dynamic" elements for audio and video screens.

(The caching was all implemented back when all elements got drawn on every update of the display. That doesn't matter too much now, when the static elements just get drawn once for a given track. Every track change causes all static elements to get updated, so there would be a bit of efficiency lost for any art that was identical.)

[mattblovell]

When I get the time, I'll look at simplifying get_artwork(), hopefully taking advantage of the @lru_cached decoration. That could potentially make it more useful for generic element_* callbacks.

[mattblovell]

The version of get_artwork() on the dev/refactor_artwork branch has been modified such that it just takes

• artwork path (from an InfoLabel) and
• desired width and height

as arguments. All of the AirPlay special-case code was separated into a new function.

The function is decorated with @lru_cache(16), so it "remembers" the last 16 retrieved paths and the requested thumbnail sizes. If a new call occurs that matches one of those previous now-cached results, the result is just returned from that cache. (The number of entries can be increased if needed. I started small.)

With those changes get_artwork() should be useful to any element-drawing function. After some more testing, that branch can be merged back to master.

[mattblovell]

The next step will be for the functions that invoke get_artwork(), current audio_screen_static() and video_screen_static() to have the ability to use an InfoLabel other than their current defaults.

The syntax proposed above won't quite work for TOML, unfortunately, as each attempts defines the exact same dictionary. (This is the reason for using the fields array and making use of double-brackets. Each such entry just keeps appending to that array within the layout.) For that reason, I think making a new "element" callback is warranted.

[mattblovell]

With the current top of the dev/refactor_artwork branch

commit 975f8d5

one can make use of a layout fields entry such as the following:

[[A_LAYOUT.FULL_ALTERNATE.fields]]
name = "audio_cover"
posx = 0
posy = 0
size = 480
center_sm = 1

as an alternative to a top-level "thumb" entry ([A_LAYOUT.FULL_ALTERNATE.thumb] in this example).

There is also an element_* callback with the name generic_artwork available.

Both should be able to take the InfoLabel to use as the image path via a use_path key, although that's not shown above. The audio_cover function fallback to using MusicPlayer.Cover while generic_artwork falls back to VideoPlayer.Cover.

The top-level "thumb" entry is still perfectly useful, so as not to break existing setup.toml files.

[mattblovell]

With the current top of the dev/refactor_artwork branch
commit 975f8d5

Ok, the commit after that one. I had one bug in element_generic_artwork().

[mattblovell]

The /dev/refactor_artwork branch has been merged back to master.

If desired, one can now modify layouts, dropping any existing top-level thumb entries and instead augmenting the fields array with entries that trigger callbacks to either audio_artwork or generic_artwork. The use_path key specifies the InfoLabel to use as the path that is then forwarded to get_artwork(), which then performs any necessary Files.PrepareDownload call.

[nico1080]

Use it in my setup for display tvshow and season poster in my tvshow layout: 6f633d8

I also tried to used it on my statis layout du display the weather icon with Weather.ConditionsIcon infolabel

But instead off displaying the image is display the default audio cover. I think it is because kodi panel cannot retreive the picture
Result of the infolabel is
{"id":4,"jsonrpc":"2.0","result":{"Weather.ConditionsIcon":"resource://resource.images.weathericons.default/33.png"}}
But I could find it on my storage file system, it is probably linked to the weather addon I use. I will look into it later

[mattblovell]

Note that one can now set

DEBUG_ART = true

in the setup.toml file to turn-on the debug print() statements that exist in get_artwork().

I don't know much about the initial resource:// path. The first step would be to see what the result from the Files.PrepareDownload JSON-RPC call is. It's possible such files are only accessible locally.