+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: OS independent / Other (https://forum.kodi.tv/forumdisplay.php?fid=228)
+---- Thread: fanart with v19 (/showthread.php?tid=363472)
fanart with v19 - lharms - 2021-07-08
I have been holding off upgrading to v19 from v18. Mostly due to one feature that seems to act oddly for me now. Specifically 'fanart' and what used to be called extra-fanart. It only acts oddly because apparently I was using the 'file' method by way of artwork beef. As that has gone away. Which is fine. But it leaves me with any new videos I add only getting 1 fanart on initial scrap of a video unless I add extra files in, instead of the dozen or so with rotation in the skin I am using.
From what I can see it looks like internally, if the skin supports it, the skins expect to see fanartXX in the art table in the database. The user is expected to setup any extra items to be scrapped in by use setting the artwork level to custom and adding extra 'fanart1' 2 3 and so on. That seems fair enough, and easier than the old way of putting it in the xml properties file.
Externally it looks like there are currently no scrapers that pull data into this internal format? Currently it looks like out of the box you can only get the fanartXX bits if you create files side-by-side with the media files. As per https://kodi.wiki/view/Artwork_types#fanart.23 and https://kodi.wiki/view/Movie_artwork
From my looking at the code I can not tell if the scraper is supposed to create the fanartXX bits to be passed in through setAvailableFanart (or other)? Or if the internal code in CVideoInfoScanner::GetArtwork is supposed to rip apart m_fanart and create the numbered fanart bits.
My question is what is expected? From my experimentation with the current code and the current TMDB python scraper it looks like the whole fanart list is passed in as a single python list object. However, only the very first item will be considered as fanart on an initial scrape of a video, from what I see in the internal xbmc code. As CVideoInfoScanner::GetArtwork will only look at the '0' item in that list. Creating a singular item fanart and not the fanartXX bits.
For my experiment I added a bit of C++ code to bash in the fanartXX bits from the m_fanart list in the code. But that does not feel right to me.
RE: fanart with v19 - Karellen - 2021-07-08
(2021-07-08, 06:50)lharms Wrote: My question is what is expected?Normal behaviour when using any of the Kodi scrapers is a single image of each type - 1 fanart, 1 poster, 1 banner etc...
If you want multiple fanart there are three choices...
1. Manually download and save the extra fanart next to your movie
2. Install Artwork Dump, which is the ARtwor beef replacement. In the settings you can nominate how many additional fanart images to download.
3. 3rd party media managers can download and locally save additional fanart.
I'll add that to the wiki page.
RE: fanart with v19 - lharms - 2021-07-08
(2021-07-08, 07:19)Karellen Wrote:Ah#2 is much closer to what I had with artwork beef. I must have had an older version when I tested it last. Just need to figure out how to make it download English fanart as well as 'none'. I am probably doing something silly. My current example it is getting 4 of the 6.(2021-07-08, 06:50)lharms Wrote: My question is what is expected?Normal behaviour when using any of the Kodi scrapers is a single image of each type - 1 fanart, 1 poster, 1 banner etc...
If you want multiple fanart there are three choices...
1. Manually download and save the extra fanart next to your movie
2. Install Artwork Dump, which is the ARtwor beef replacement. In the settings you can nominate how many additional fanart images to download.
3. 3rd party media managers can download and locally save additional fanart.
I'll add that to the wiki page.
It is Just different than how I expected it to work.
I expected the scrapper to grab all the info and fill out the db. Then you could use artwork dump to after the fact export and fixup the db to keep things local if needed. Then some other util in the future to go back and do the 'refresh updates' as needed.
My other question is in the future is it expected that the scrapers do the fanart splitting or will the internal code do it? From what I have been reading on the forums and threads it seems like the scraper is supposed to do it? But none of the info providers support it yet. From looking at the code though it could be either way?
RE: fanart with v19 - Karellen - 2021-07-08
(2021-07-08, 08:32)lharms Wrote: Just need to figure out how to make it download English fanart as well as 'none'.You can't. There is no such thing as English fanart.
Fanart are images without text.
Landscape are images with text. The add-on won't download additional Landscape images.
(2021-07-08, 08:32)lharms Wrote: It is Just different than how I expected it to work.Yes, it is a rewrite and different to Artwork Beef.
(2021-07-08, 08:32)lharms Wrote: is it expected that the scrapers do the fanart splitting or will the internal code do it?I don't know what you mean here. What is fanart splitting?
RE: fanart with v19 - lharms - 2021-07-08
(2021-07-08, 08:44)Karellen Wrote:(2021-07-08, 08:32)lharms Wrote: Just need to figure out how to make it download English fanart as well as 'none'.You can't. There is no such thing as English fanart.
Fanart are images without text.
Landscape are images with text. The add-on won't download additional Landscape images.
(2021-07-08, 08:32)lharms Wrote: It is Just different than how I expected it to work.Yes, it is a rewrite and different to Artwork Beef.
(2021-07-08, 08:32)lharms Wrote: is it expected that the scrapers do the fanart splitting or will the internal code do it?I don't know what you mean here. What is fanart splitting?
Ah I did not know that about landscape. Then I am not doing something silly
That might be a bug in the python TMDB scrapper then. As it hands over a list of all the backdrops which have text and not text in them. The internal code just picks the first item in the list. So depending on what order that is handed over in would depend on if it worked or not. I bet if you had a movie with only landscapes and no fanart it would pick a landscape as a fanart. That may be the expectation. Oh i got the re-write part. I just expected it to be the info scraper does most of the work and then you use something like AD to freeze it in place. So you could have a local copy if you wanted for other programs, or other reasons (nfo managment, etc). Basically a better version of the artwork backup util. It is OK I may have just misunderstood what the end goal was here.
Basically these websites present several dozen fanarts. The scrapers see it in their JSON requests. I was trying to figure out if the information scrappers in the future would be expected to have enough sense to make all of the fanartXX bits for each one, or internal KODI C++ code was expected to do it, or if it was to only be this method of using external files (using tools like artowrk beef, artwork downloader, or other). As it is written right now the 'file' way seems to be what is expected, but the GUI and DB presents a different possibility. If someone did not want to use all of those extra files and just use the built in thumbnail cache to hold everything there is not a real clean way to do it if you have a large library. However, it looks like there is enough structure in the database and in the rest of the system to allow it to be 'fileless' (for a lack of a better term). My little cheesy hack shows that. My real question should the info scraper control it, the internal KODI code do it, or other?
I could see if this is done right and the skins were tweaked a bit you could do something like rotating posterart, discart, clearart (which could be fun). Also if done right the skins could just use a different method for looking things up and the internal code could just present art rotation as a service. That way each skin does not have to go its own way.
RE: fanart with v19 - Karellen - 2021-07-08
(2021-07-08, 16:33)lharms Wrote: That might be a bug in the python TMDB scrapper then. As it hands over a list of all the backdrops which have text and not text in them. The internal code just picks the first item in the list.Have a look at general settings. Third setting... https://kodi.wiki/view/Add-on:The_Movie_Database_Python#General
(2021-07-08, 16:33)lharms Wrote: I was trying to figure out if the information scrappers in the future would be expected to have enough sense to make all of the fanartXX bits for each one, or internal KODI C++ code was expected to do it, or if it was to only be this method of using external files (using tools like artowrk beef, artwork downloader, or other).The scraper only provides the data and links. It is then Kodi core that grabs all that and inserts it into the library. So it would need to be Kodi core that is modified to use multiple fanart from scraped results as the scraper already provides them.
(2021-07-08, 16:33)lharms Wrote: I could see if this is done right and the skins were tweaked a bit you could do something like rotating posterart, discart, clearart (which could be fun).Yes it could be.
RE: fanart with v19 - lharms - 2021-07-09
(2021-07-08, 20:48)Karellen Wrote:(2021-07-08, 16:33)lharms Wrote: That might be a bug in the python TMDB scrapper then. As it hands over a list of all the backdrops which have text and not text in them. The internal code just picks the first item in the list.Have a look at general settings. Third setting... https://kodi.wiki/view/Add-on:The_Movie_Database_Python#General
(2021-07-08, 16:33)lharms Wrote: I was trying to figure out if the information scrappers in the future would be expected to have enough sense to make all of the fanartXX bits for each one, or internal KODI C++ code was expected to do it, or if it was to only be this method of using external files (using tools like artowrk beef, artwork downloader, or other).The scraper only provides the data and links. It is then Kodi core that grabs all that and inserts it into the library. So it would need to be Kodi core that is modified to use multiple fanart from scraped results as the scraper already provides them.
(2021-07-08, 16:33)lharms Wrote: I could see if this is done right and the skins were tweaked a bit you could do something like rotating posterart, discart, clearart (which could be fun).Yes it could be.
Ah not supposed to be a bug then. I do have the separate items setting checked and the whole list looks like it is being passed in. I will look a bit closer maybe I am reading it wrong and I am snagging looking at the data too soon in the C++ stream of data. It would be a tough thing to tell as I think the scrapper grabs non texted items first then texted items. But then internally only snags the first one. So you may never see it broken unless all of the fanart had text and no empty ones.
As for where it should split out then I think I am in the right area of code. In xbmc\video\VideoInfoScanner.cpp in the method CVideoInfoScanner::GetArtwork seems like the right spot to split it.
For the rotation idea. I have not looked but I do suspect however that the other artwork types are only being passed in as a single item and not a list. So it would probably require a bit of change in the scrapers to be effective and in the internal code to catch those lists. Which would probably be a fairly invasive interface change. I could be wrong though I will look closer.
RE: fanart with v19 - DaveBlake - 2021-07-10
Scraper fetches a list of available remote art, and the URLs get stored. This is held as an xml blob, and there are size limits hence the scraper trucates long lists of available art. This could be dropping artwork results that you want, I don't know how intelligently (if any) filtering is applied.
Kodi picks up local art, and then falls back to picking the first remote image of each type of art in the list of many available remotely to fill gaps.
There is another approach to consider other than scraper changes, or core Kodi changes if this processing does result in Kodi using the art you want - use the JSON API to set artwork, write an addon. Using JSON you can both read the stored list of URLs, and set art (including adding art types). Addons don't have to be written as scrapers to fetch art from remote sites and set it inside Kodi. This can be done without any interface changes to the way scrapers are integrated into Kodi core.
RE: fanart with v19 - lharms - 2021-07-24
(2021-07-10, 14:28)DaveBlake Wrote: Scraper fetches a list of available remote art, and the URLs get stored. This is held as an xml blob, and there are size limits hence the scraper trucates long lists of available art. This could be dropping artwork results that you want, I don't know how intelligently (if any) filtering is applied.fair enough
Kodi picks up local art, and then falls back to picking the first remote image of each type of art in the list of many available remotely to fill gaps.
There is another approach to consider other than scraper changes, or core Kodi changes if this processing does result in Kodi using the art you want - use the JSON API to set artwork, write an addon. Using JSON you can both read the stored list of URLs, and set art (including adding art types). Addons don't have to be written as scrapers to fetch art from remote sites and set it inside Kodi. This can be done without any interface changes to the way scrapers are integrated into Kodi core.
I was just looking at CVideoInfoScanner::GetArtwork
I see in that method that it decodes the fanart list (around line. But it only looks at the first one. There is no loop to get the rest of the items.
There are other bits in the cpp code that seem to indicate that it should loop across the items as it decodes it correctly? So I was a bit confused that the part that puts it into the system only looks at the first item.
RE: fanart with v19 - DaveBlake - 2021-07-25
The code is as designed @lharms. The scraper addon could fetch urls for 100s of images (and a lot will be the same picture depending on what the various remote art sites return and the community have added). Kodi picks up the first of each type and uses that to fill any gaps in that type of art, local artwork usually takes priority.
The urls get stored and that list is used to show possible art when user is manually selecting new artwork for something. But no Kodi does not make entries in the art table for every sepeate url, or bring up all the possible remote art when browsing or playing the item. That would mean requesting all those images from the remote sites and caching them locally, a whole lot of wasted server load and local storage for a lot of often duplicate images.
In the past there were addons that fetched multiple fanart, put it in a subfolder and then skins that made use of that folder of images. It was all external to Kodi itself. Some of those addons are no longer suppported by the authors.
Kodi is now capable of picking up various local art by default, but not from subfolders and has filename requirements. It will also handle any arttype provided externally (previously only fanart and thumb only was hard coded). This is a move forwards, it means that extending art handling no longer needs core code changes, and art added via JSON or Python interface can be managed by Kodi (cached, refreshed etc.). It gave those users with local art (and some skinning skill) the possibility of showing any kind of invented arttype anywhere - no addons needed, no core changes. But it did not make an obvious easy step for skinners to change from showing randomly named art files from an "extrafanart" subfolder.
I don't think that picking up randomly named art files from an "extrafanart" subfolder and adding it as "fanartX" will ever be a core Kodi function, it is too specific and limited. What about other subfolders and arttypes? An addon could do that, and be much easier for users to write their own or change between Kodi releases.
If you are unclear what I mean by arttype then "thumb", "poster", "fanart", "banner", "discart", "back", "spine", "logo" are all examples currently in common use but no reason they can't be anything in the future. I know one user has used the functionality to show the pages of the booklet that came with the CD.