2019-07-17, 12:31
"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.
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.
