Kodi Community Forum

I really like what you’ve done Dave implementing the artist information folder changes.

There’s one thing that’s bothered me though (and reason I haven’t switched to it): Using fixed names for extra fan art (fanart1, fanart2 etc)

I use Artist SlideSow add-on which downloads extra fanart automatically using a hash file name. I’m pretty sure the hash name is same for each specific fanart file so it doesn’t download the same file again as it already exists. When it’s renamed to fanart, it will download another hash version.

Anyway, the simple solution would be for the new artist information folder to allow for an ‘extrafanart’ Sub-folder for each artist and for Kodi to blindly presume (and consume) all the .jpg files in that folder as ‘fanart’.

It’s basically what Kodi 17 did and how Kodi 18 does without the artist information folder switched on.

Comments or solutions most welcome.

@HomerJau I have split this out because it is more an AIF and artist at question than about using human friendly folder layouts (although I get that this is stopping you doing the other).

My working on art for music was a bit crazy really since my personal use of art is minimal - I listen with TV off and only see the thumbs that the remote app shows. Nothing fancy at all. The AIF was all about solving the artist art glitches and limitations people had experienced.  The extended art type stuff started with a simple JSON API addition and grew because removing hard coded art types from core seemed a good long term design step, and it fitted with the AIF. However I completely overlooked the needs of both slide-show type addons and the multi-image control used by skins.

Hence there are more artist art improvements  to do, but I need input from the expert users, skinners and addon authors to ensure I don't miss any more requirements!

(2019-07-17, 09:48)DaveBlake Wrote: [ -> ]@HomerJau I have split this out because it is more an AIF and artist at question than about using human friendly folder layouts (although I get that this is stopping you doing the other).

My working on art for music was a bit crazy really since my personal use of art is minimal - I listen with TV off and only see the thumbs that the remote app shows. Nothing fancy at all. The AIF was all about solving the artist art glitches and limitations people had experienced.  The extended art type stuff started with a simple JSON API addition and grew because removing hard coded art types from core seemed a good long term design step, and it fitted with the AIF. However I completely overlooked the needs of both slide-show type addons and the multi-image control used by skins.

Hence there are more artist art improvements  to do, but I need input from the expert users, skinners and addon authors to ensure I don't miss any more requirements!

Thanks for the quick reply. Looks like you know of this already. Hopefully you’ll get further feedback for future updates. Thanks again for your work to get artist info moved for all the right reasons. Just a few small tweaks to come.

"Just a few small tweeks"... I hope so, but we will see.
I will share my current understanding, see if anyone wants to add anything or comment.

In the past we had an inconsistent map between image file name and art type (as used by the skin and to store the art), all hard coded hence only certain types supported. Now v18 during scanning will pick up any type of local art providing you tell it the types you want (via advancedsettings.xml) , use that type in the filename and put the art in the right place. For backwards compatibility thumbs are the only exception to that.

Addons can also load any type of art via JSON, and that art also gets added to the music db, and the texture cache etc. While scanning to library picks up local art, it is addons (including but not only the scrapers) that do the bulk of the art capture.

Then came the question of having multiple artist fanart. When initially asked about how to have more than one artist fanart image I suggested using extra types fanart1, fanart2 etc. and similarly named files. It seemed obvious and simple - what art was up to the skinners and the addons.  I think we need to avoid making fanart or any other type of art special, having hard coded features for just fanart would be a step backward.

Multiple artist fanart was not something that had never been supported in Kodi core before, but always handled by addons that fetched the art from online sources and put it somewhere local. Skins then displayed the art using the multi-image control that picks up the images from given folder. Using a folder called "extrafanart" became common practice, however this art didn't get added to  the databases, or cached (?).

I know now that cycling through an unkown number of types e.g.  fanart1, fanart2 etc. is not easy for skinners, although some have done what they can with it. My thought was to create a new multi-image control that could take partial  art type parameter e.g. "fan" and would pick up all art of a type that started with that string. This would be based on the art loaded into the music and texture databases and cached, so that addons that fetch the art would need to load it not just put it in a folder.

Then there is the Artist SlideShow add-on.... I do not know anything about how it works. Perhaps @pkscout could come in here and have a discussion about the best way forwards. It may be that the solution lies in the addon not core Kodi additions at all.  Why doesn't the Artist SlideShow use the AIF? I get the user requirement - pretty artists images cycling during playback - but how we best achieve that is open for ideas. Does the art want to be a fully loaded into Kodi so other addons etc. can use it? Does it get cached with other textures (or will that cause bloat if it is updated regularly).

Where we need to think carefully is the different requirements for static art (the user's precious choice of art that they want permanently) and dynamic art (where the user wants the art to be refreshed and updated regularly by new stuff from the web). The automatic pick up of extended art types works for static art that is stored locally and not wanted to change. The Artist SlideShow addon sounds much more dynamic in what it provides.

I wondered about having some extra scanning functionality in core Kodi to load art from a folder e.g. contents of folder <foldername> get loaded as art type "foldername1", "foldername2", "foldername3" etc.,  but then again how many times does the user set that up manually and want it permanently? The user could just name the image files foldername1.jpg etc.  If it is mostly addons that fetch multiple images and update them regularly then it is the addon that needs to add/edit the art db entries using JSON.

I would like all addons that use a folder for artist data (most probably art) to be able to use the AIF. I'm not clear what the problems currently are , if any, that would prevent that but I'm up for hearing about it.

Some of the answer about why AS works the way it does is because it's always worked that way.    I took AS over from @ronie almost ten years ago, and while I've added a bunch of stuff around the edges and refactored code, the basic function is still the same.  AS grabs artwork for a given artist from a set of sources and then stores that in either the userdata directory or a place of the user's choice.  It creates some skin infolabels that skins can use to display the artwork, the primary one being a path to a folder that can be used in a multi-image.

I've been looking at at least adding an option to support the AIF, but I think I'm probably going wait until Kodi 19 so I can wrap that major change in with the Python 3 compatibility.  I was also waiting to see if the spec for the AIF stabilized.  The big challenge on my end is naming files.  Right now AS saves the file using whatever filename the source site uses (so it's not actually a hash).  Moving to AIF I'm going to have to have a one time routine to rename all the files to the fanart1, fanart2, etc. format, move them out of the extrafanart folder, and then add some logic to figure out what the next file name should be.  It's not conceptually hard but it's hard to get the code right (at least for me).  I really kind of wish Kodi could just look at a folder and use them all as fanart, as that would minimize the changes I have to make (which is selfish of me of course).  When I looked at the wiki awhile back, it seemed like the amount of manual work a user had to do to enable the AIF and then tell Kodi what fanarts are there would mean very few folks would use it.  But maybe that changed in the interim.

Anyway, I guess that's a really long way of saying AIF support is on the roadmap for AS.

Thanks for the info.

From a users perspective:

I don’t have any issue waiting for v19 to get the best resolution.

Seems to me the main issue for AS and users is the forced/fixed fanart file naming.

It has been pretty easy for me to add my own fanart for AS prior to AIF since it’s just placing a jpg in the artist’s extrafanart folder. No need to worry about it’s file name. Ideally supporting an extrafanart folder without requiring specific file naming would be best. It’s also important that any change to AS would still allow any user file in a similar way, even if the file needed to be renamed.

Moving to AIF (as it’s currently implemented) there’s a once off renaming of all existing extrafanart to sequential ‘fanart1’, ‘fanart2’ etc naming. Fairly painful for many users.

I’d like to take advantage of AIF, organising media files across sources and keeping the artist information together and accessible by Kodi and add-ons via the cache.

Is there any data/evidence to show extrafanart needs to be cached? Is there a performance hit particularly on ‘play next file’ using another artist. (Thinking of minimising code ‘tweaks’ if not required). I’m happy to test on my system if full logging will provide data?

Dave, you mention allowing definition of artwork types by folder name. Is this required? Is there any other multiple artwork required apart from artist fanart? Maybe just add a default folder for ‘extrafanart’ for Kodi to include, don’t add user defined ‘folder=art type’ mappings? (minimising tweaks).

We still have the basic Kodi issue, or concept, of a multi-image control that relies on a path to a folder with image files.  Or simple images that are either pulled from Kodi via an art infolabel or a specific path/filename.  The one tweak on that is the "resource addon" but that's more of a packaging method than a way to actually display images in a skin.  Of course skinners, always pushing the envelope, figured out they could use the fadelabel control, intended to display a sequence of text strings, to display a sequence of images.

If the requirement is to be able to display a sequence (ordered or random?) of images, then there needs to be a grouping mechanism to create the sequence.  For music the grouping is typically based on artist and arttype.  For music video it is mv title and arttype (though mv has the ability to pull some things from music artists but not music albums though it appears the design intended to provide that as well).

scott s.
.