Req extrafanart in artist info folder
#1
I still support use of an /extrafanart/ folder.  This can be located either in the library location or the artist info folder.  The problem is to access with a multiimage control, I need to construct the path to the artist info folder/extrafanart.    That isn't a problem except when the specific artist name has been normalized for use in artist info folder.  It would be nice I could get something like musicplayer.property(artist(n)_cleanname) and listitem.property

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
#2
I already realise that the name of the artist folder should be returnable via JSON, but had not considered as an info label too. It is not stored data (although I could switch to that approach if there was a good use), so would slow down list item population from db if generally returned like other item values. It could be fetched by a background loader of course.

But shouldn't extrafanart just be provided by the core art loader without the skin needing to know where it comes from? Am I missing some other issue here?
Reply
#3
(2019-04-11, 16:18)DaveBlake Wrote: I already realise that the name of the artist folder should be returnable via JSON, but had not considered as an info label too. It is not stored data (although I could switch to that approach if there was a good use), so would slow down list item population from db if generally returned like other item values. It could be fetched by a background loader of course.

But shouldn't extrafanart just be provided by the core art loader without the skin needing to know where it comes from? Am I missing some other issue here?

Well, in the past extrafanart was always managed by the skin (or addon in the case of Artist Slideshow).  To use a multiimage control (which AFAIK was created with the idea of displaying fanart) skinner has to supply a path.  For movies that is just the movie folder path if the user is using the preferred source folder arrangement.  I don't think internet streamed items were ever considered candidates for displaying extrafanart.  Alternatively Skin Helper Service can load a path into a window property, but that I guess it still needs a way to create a valid path (my requirement is to minimize use of services in the skin for performance so I haven't tried SHS).

For music fanart has been associated with artists rather than songs or albums, so that makes locating an extrafanart folder path more of a challenge.  I think it is probably common that skins provided for the possibility of looking in a folder location (parent folder of the folder containing a song) or a user-defined path that could be used to construct userpath/artist/extrafanart.  Of course there was the problem of illegal path chars as well as multiple song or album artists which result in a failure to display the desired extrafanart.  (As an aside, what prompted my post was I finally got around to fixing this in my skin mod -- what i found was that if a path doesn't exist, the multiimage control <imagepath> element returns the last valid path -- the skin was testing for an empty path and that only worked if a valid path had never been identified previously.  I think this is probably a bug, but I was able to work around it by creating a dynamic list of file items for the path and testing container.numitems on it.  In the case of no extrafanart path I display the default fanart which now works.

With the addition of the artist info folder, that made a logical location for artist extrafanart folders without the user having to nominate his/her own dedicated path in the skin for them.

Now thanks to artwork beef and the extra art feature of Kodi 18 it is possible to load all art into the library, though the multiimage control no longer works and so we need a kludge of using a fadelabel control to iterate through library fanarts (among other things it hard-codes the max possible fanarts).  But in my case I have over 11,000 artist extrafanarts in my production music source artist info and I'm not sure about adding 11 000 arts to the library.  So I am still going to support the extrafanart folder path for now.

Mostly extrafanart for music is relevant for the now-playing song.  In some cases it is useful for the focused item in lists or in the music or song info dialogs.  I don't have a need for displaying extrafanart within containers and don't really see a utility for that.  So the need is just for musicplayer or the focused container/listitem.

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
#4
(2019-04-11, 16:18)DaveBlake Wrote: But shouldn't extrafanart just be provided by the core art loader without the skin needing to know where it comes from? Am I missing some other issue here?

That's definitely the way I see it.
(2019-04-12, 04:27)scott967 Wrote: Mostly extrafanart for music is relevant for the now-playing song.  In some cases it is useful for the focused item in lists or in the music or song info dialogs.  I don't have a need for displaying extrafanart within containers and don't really see a utility for that.  So the need is just for musicplayer or the focused container/listitem.

Kodi's internal artwork support is meant to be in the library, an add-on can implement other behavior. The better way to go here is to expose the artist folder for JSON-RPC to facilitate that than skins cobbling together paths, as Dave mentioned. FWIW my video library art tables has 116k artwork.
Reply
#5
There is still so much I don't know about Kodi!

So skins can use a multi image control to show a "slide show" of images located in a given folder, these may be previously cached or picked up directly from the folder. Makes sense as a way to support extra art when only a single thumb and fanart was supported by the core processing or held in the database. If items have a path property then I can see how easy that would be to use.

I think having the individual location of all artist or album related images held in the db is a good thing. It means that the art can be anywhere, called anything (although using simple folder layouts and standard file naming to provide an automated pickup of local art), navigated/selected in diverse ways and shared by all addons and skins. I don't see that having art table entries for 11,000 artist extrafanarts would be an issue @scott967, how about you test it out?

But to go with loading all types of art we need to provide core support for a multi image control that can be based on art type rather than a path. For example given "shot" it cycles through the art for that item with types shot1, shot2......shotN, or maybe shot*, even cover artist1.shot1, artist2.shot1 for a collaboration album. Does that sound correct as a requirement? Rather than a infolabel have a better control.

Meanwhile there is how best to support skins that use the current multi image control.
(2019-04-12, 04:27)scott967 Wrote: I think it is probably common that skins provided for the possibility of looking in a folder location (parent folder of the folder containing a song) or a user-defined path that could be used to construct userpath/artist/extrafanart.  Of course there was the problem of illegal path chars as well as multiple song or album artists which result in a failure to display the desired extrafanart.

With the addition of the artist info folder, that made a logical location for artist extrafanart folders without the user having to nominate his/her own dedicated path in the skin for them.

Now thanks to artwork beef and the extra art feature of Kodi 18 it is possible to load all art into the library, though the multiimage control no longer works and so we need a kludge of using a fadelabel control to iterate through library fanarts (among other things it hard-codes the max possible fanarts).  But in my case I have over 11,000 artist extrafanarts in my production music source artist info and I'm not sure about adding 11 000 arts to the library.  So I am still going to support the extrafanart folder path for now.
Marcel agrees with me that more of the SHS functionality needs moving into core where it can be done more effiiciently, but has never found the time to discuss which functions and I don't have the time to dig about in the addon code and work out what it is used for. So I have no wish to send you off to use SHS, much rather ensure core Kodi better supports the skinner's needs.

My stupid question of the day - can skins make JSON calls? Sorry but I just don't know  how that works at all.

I also don't know how kludgy it is using fade label with a series of types e.g. "fanart", "fanart2", "fanart3" etc. but I accept it is not ideal.

Likewise if you take the artist name as the artist folder name you will be right most of the time. I decided not to do much name normalisation, I guess I will have to wait for user feedback to discover if this was a mistake. The only special thing it does is when name is not unique it adds part of the mbid to the end. For 18.2 there are info labels for mbids too, so you could possibly include that in your path building approach.

While I don't think the skins should be doing clever things with path for artist I can see that the user themselves might want to see where the artist nfo and local art are being picked up from (for example on the artist info dialog), and that would suggest an info label for that use but not for the player UI.

Since my team colleagues are reluctant to have improvements in point releases (only bug fixes) there is little I can do for v18,  and I think for v19 a better multi-image control (plus JSON exposure of artist folder) is the way to go. But still happy to discuss the practicalities further.
Reply
#6
(2019-04-13, 10:14)DaveBlake Wrote: There is still so much I don't know about Kodi!

That's the problem with being in your own little corner Wink

Not sure if there's any relevance to the existing discussion, but other addons could maybe make use of being told where the artist info folder is by Kodi core, for example https://kodi.wiki/view/Add-on:Artist_Slideshow
Reply
#7
(2019-04-13, 17:30)jjd-uk Wrote: Not sure if there's any relevance to the existing discussion, but other addons could maybe make use of being told where the artist info folder is by Kodi core, for example https://kodi.wiki/view/Add-on:Artist_Slideshow 
Yes @jjd-uk it was an oversight on my part not to have already exposed both the location of the Artist Information Folder, and the folder name for each artist via JSON. Shame no one asked a little earlier in the dev cycle. I would happily include that in v18, but does providing accidentally ommited information count as a "fix" or an "improvement"?

For me accident is the opposite of design and thus it is a fix, for others I'm sure any addition of anything is unacceptable in point releases. Despite now having branched as long as no breaking changes to the API have been made in M* I could still backport such a fixing addition and it is low risk, but it is up to the team to either support and empower me to do that, or choose to restrict and block.
Reply

Logout Mark Read Team Forum Stats Members Help
extrafanart in artist info folder0