[ZERO <ibis>]

It does not work, in order to support reading from extrafanart folders you must point to the directory directly. This is from the first implementation of extrafanart folders from years back. Later on some scrappers support pulling images directly into the database but such a feature is not supported for anime. The only way to have extrafanart for that is to add it yourself.

There is also a problem with the Image_Background when used at the episode level. Because the method uses ListItem.Art(fanart) it returns "Returns the fanart image of the currently selected item", as a result if you select the back button in the episode view it will not load the correct image (I assume it will load the fall back image in this case if configured). To correct this the variable Fanart.Image must be used in it's place as that will load " Fanart image for the parent TV Show ". When using Fanart.Image instead of Image_Background the content loads as expected. I can modify Image_Background (adding at line 170) to have the following line added for compatibility if you want:
<value condition="Control.IsVisible(513)">$INFO[Fanart.Image]</value>

I just wanted to avoid modifying any stock includes unless explicitly told to do so.

Unfortunately, it is impossible for me to test any other way of loading extrafanart images. From what I see many of those fanart download mods that auto download content are able to place it or do place the files in an extrafanart folder at the local directory of the media if configured to do so. This is the only implementation of extra fan art I can support. If users do not have this folder it will not effect the skin, they will just get one image in this display mode instead of multiple ones.

If someone wants to add a control to support another way of loading extrafan art they can once I post the final code up; unfortunately it is irresponsible for me to try to add code for something that I can not test and verify works.

[Alanon]

It does not work, in order to support reading from extrafanart folders you must point to the directory directly. This is from the first implementation of extrafanart folders from years back. Later on some scrappers support pulling images directly into the database but such a feature is not supported for anime. The only way to have extrafanart for that is to add it yourself.

There is also a problem with the Image_Background when used at the episode level. Because the method uses ListItem.Art(fanart) it returns "Returns the fanart image of the currently selected item", as a result if you select the back button in the episode view it will not load the correct image (I assume it will load the fall back image in this case if configured). To correct this the variable Fanart.Image must be used in it's place as that will load " Fanart image for the parent TV Show ". When using Fanart.Image instead of Image_Background the content loads as expected. I can modify Image_Background (adding at line 170) to have the following line added for compatibility if you want:
<value condition="Control.IsVisible(513)">$INFO[Fanart.Image]</value>

I just wanted to avoid modifying any stock includes unless explicitly told to do so.

Unfortunately, it is impossible for me to test any other way of loading extrafanart images. From what I see many of those fanart download mods that auto download content are able to place it or do place the files in an extrafanart folder at the local directory of the media if configured to do so. This is the only implementation of extra fan art I can support. If users do not have this folder it will not effect the skin, they will just get one image in this display mode instead of multiple ones.

If someone wants to add a control to support another way of loading extrafan art they can once I post the final code up; unfortunately it is irresponsible for me to try to add code for something that I can not test and verify works.

Something is definitely not as it should be. The most popular skins for Kodi all implement Skin Helper for extrafanart retrieval almost exclusively, as it works regardless of the specific option used, be it direct, in-cache artwork management, or the extrafanart folder implementation. In fact, Marcel has made it like that specifically so that it would be viable as a universal solution. The add-on checks for extrafanart folders and their content within the library structure and acts accordingly. Everything is automatic, and seamless. This goes for Artwork Beef as well and as a nitpicker, I can confirm that both have proper extrafanart rotation across all levels - show, season and episode. I'm not sure why anime wouldn't work within that framework, as I have no experience there, but I'm fairly certain that there are anime users that would've complained if that were so?

There's a chance that for whatever reason the proper conditions in the includes aren't being triggered, which causes the proper method to be skipped. Before anything else, could you try setting $INFO[Window(Home).Property(SkinHelper.ListItem.Art.ExtraFanArt)] and see if that displays the proper artwork? If it does, we'll know that the mechanism works and then all that would remain would be to find out what's wrong with the conditions. The problem with a direct filepath implementation is that it will probably conflict with all other methods, so many skin users will end up with conflicting requirements for the same thing. Some users will get to the point of having to radically change their artwork organisation or usage just to be able to use two view-types within one skin. That is certain to cause massive confusion and a host of complaints about it not working for some and working for others, and I'd like to avoid that if possible.

[ZERO &lt;ibis&gt;]

I tried using it in the default view types without it working. I will do some more testing to see if I can figure anything out. For reference the way I always have used extra fan art is as follows:

Structure: Drive Letter:/shows/snowname/extrafanart
Content: image files with literally any image filetype and name (usually .png images)

I have tested replacing all images with jpg and naming them things like fanart0 fanart1 ect.

Also note that some of my fanart folders can contain hundreds of images.

Worst case I can make it so that both are supported. As I currently have it displays the results of Image_Background for the image and uses the contents of the /extrafanart folder if available. I can just as easily make the Image_Background support use the same multi image item the rest of the skin uses and fall back to my method for /extrafanart when it has content. This way the content still gets displayed if present.

[PantsOnFire]

@PantsOnFire: Basically, you need to keep in mind that there are two ways of maintaining the artwork - either locally, or directly inside the Kodi cache. In the first case, Artwork Downloader will download the artwork locally, and Kodi will cache the images from there, and everything should be faster. In the second, the tool will only update the database with the links, leaving Kodi to fill in the blanks and download the artwork as accessed. Depending on the size of the library, server status, etc, it can take a very long time before everything is displayed properly. In theory, Kodi should start the download process for an item when you first view it and begin retrieving the logo, clearart, backgrounds, etc. Scrolling through the library can often confuse the process and clog up everything, preventing the fetching process. Generally speaking, there is no rule as to what gets downloaded when or how fast the cache gets updated. 

For example, there should be a logo displayed on the top of the screen next to the clock, even in Media Info 3. If you can see the logo there but not on the other two views, then we're probably dealing with a bug. If you can't see logos at all, then its probably still an issue with the retrieval itself. In either case, there should be errors in the log detailing what happens when Kodi tries to access those images, either by downloading them or by trying to display them. A definitive solution to this issue would be to use something like the Texture Cache Python utility and force artwork caching into the Kodi database, which should resolve most of the issues. Otherwise, you're at the mercy of Kodi's caching mechanisms. From the behaviour you've described, it seems to me that Kodi is still trying to download and cache the artwork. I've had these protracted loads whenever I had reset my library, which is how I discovered the Python utility in the first place.

Thanks about the Texture Cache Python utility tip. I'll try it out.

[Alanon]

I tried using it in the default view types without it working. I will do some more testing to see if I can figure anything out. For reference the way I always have used extra fan art is as follows:

Structure: Drive Letter:/shows/snowname/extrafanart
Content: image files with literally any image filetype and name (usually .png images)

I have tested replacing all images with jpg and naming them things like fanart0 fanart1 ect.

Also note that some of my fanart folders can contain hundreds of images.

Worst case I can make it so that both are supported. As I currently have it displays the results of Image_Background for the image and uses the contents of the /extrafanart folder if available. I can just as easily make the Image_Background support use the same multi image item the rest of the skin uses and fall back to my method for /extrafanart when it has content. This way the content still gets displayed if present.

Skin Helper should definitely work with that setup. The filenames should not have any impact on detection, but I confess I know nothing on the impact of the number of files. The thing is, Skin Helper already checks if there are files in the show folders, and extrafanart explicitly, which is what puzzles me.

I think the best workaround might be made on a skin level by way of variable in the Image_Background, by adding the direct filepath infobool universally, in third place after the Skin Helper reference.  This would allow consistency across the skin - for everyone that uses Skin Helper or Artwork Beef and it works, it will default to either. For everyone that it doesn't work for, the skin would go to the next item, the direct filepath method.

As far as I'm concerned, I'll gladly test things on my end to see if everything works, and I think that together we can test and figure out a way of supporting both.

[ZERO &lt;ibis&gt;]

Ok, I figured it out. You are correct it does work by default just inconsistently which is what made me think it did not work. Currently it will only load from that in the ep level view on the default view types. So when I was testing on the tvshow level I thought it was not working. I tested with the view mode "RightList". It works in Ep level view but not tvshow level.

I will read over the related code now and start to reverse engineer.

*Or not there was a bug in my code that was causing it to run in this view mode.

Ok so reading the code for Image_Background more clearly I see the reference to script.artwork.beef but this script was not listed in the addons list within the skin in its settings view. However, when I went to the first page of the thread and double checked the addons I found it listed. I did not expect there to be addons listed in the forums that were not within the skins listing itself. I will install that and it will likely fix the problem.

Ok I have also read about how that addon is intended to work and looked at the code from <control type="fadelabel" id="4420"> to verify. This method apparently allows this addon to "grab artwork from the wonderful web services fanart.tv, TheTVDB.com, and The Movie Database." As a result there is no support for the /extrafanart folder. Still though this is a nice service and I will test to see if it works at all. I think you are correct though that the best thing to do would be to build support for the /extrafanart folder directly into the mod. It would require an additional setting because users should be able to select if they want to use the folder option to override if available. Otherwise you would always get 2 options:

A) if there is content in /extrafanart you will always see this content over the content from Control.Getlabel(4420)
B) if Control.Getlabel(4420) can run it always will even if there is content in /extrafanart it will be ignored.

I will set it up to work like option A by default. This way you can add a setting to allow it to also work like option B if you would like. This may not matter because if a user does not want /extrafanrt to load they could just rename the folder or remove its contents.

[Alanon]

Artwork Beef is not a requirement, and the author of the add-on explicitly stated that it not be included in any skin's dependency lists, so I complied. It's an alternative to Artwork Downloader, and if you switch to it, you'll have to change the way in which you handle artworks. The code that I've made for Artwork Beef is separate from Skin Helper, due to the fact that Artwork Beef does not download any artwork in a physical form. That's also why I've made it so that it will only activate if the add-on is present.

I personally prefer Artwork Beef because it has automatic management of movie set artwork, but it is different in both implementation and behaviour, so I'd advise being careful when reading the documentation, so as not to cause massive problems with your own artwork setup. There is Artwork Downloader compatibility mode within Artwork Beef, but there's still a chance of things going wrong with the database.

You might say that the add-on is supported, insofar as it will work once used, but it's in no way required, as Skin Helper + Artwork Downloader is the way 90% of Kodi users prefer to manage their artwork. Skin Helper's behaviour does not change based on whether Artwork Beef is there or not. In fact, Skin Helper's fanart functionality is switched off when it is present, but on the surface, there should be little to no difference with regards to actual performance (image rotation on all levels, etc).

While I suspect that Artwork Beef would generally be more suitable to your requirements, as I've found it to be more flexible, you'll lose features like automatic extrafanart folders, as Artwork Beef simply decided not to download artwork into the library as a design point. That feature exists only in Artwork Downloader. Of course, Artwork Beef can piggyback on existing local extrafanart if it is present, it will not place it in those folders in future artwork updates. You can find most such details in the dedicated thread.

[ZERO &lt;ibis&gt;]

Ah that makes sense.

Just want to verify the conditions here:
!System.HasAddon(script.artwork.beef) + Skin.HasSetting(SkinHelperExtrafanart) + !String.IsEmpty(Window(Home).Property(SkinHelper.ListItem.Art.ExtraFanArt)) + !Skin.HasSetting(global.fanart)

So for me to see it show up correctly I need to remove the script.artwork.beef (which is now called script.artwork.helper).

Turn on Extra Fan Art in settings (have had this on already)
Turn off Fan Art (have tried this setting, just get a black screen when this is off)

So my conclusion is there is something strange going on in SkinHelper.

Also for some reason my version if SkinHelper is requiring that I install script.module.cherrypy is this normal? BTW I am on windows 10... also when script.module.cherrypy Kodi hangs on exit.

[ZERO &lt;ibis&gt;]

Yea had a look though the code and could not find it.

You could try to test if you are able to toss any random image into a /extrafnart folder and have it show up but for me it does not work. Below is an example of the code I am using to generate the background images for my view mode:

Code:

            <control type="image">
               <top>0</top>
               <left>0</left>
               <width>1920</width>
               <height>1080</height>
               <aspectratio>scale</aspectratio>
               <fadetime>200</fadetime>
                <texture background="true">$VAR[Image_Background]</texture>
           </control>
            <control type="multiimage">
                <top>0</top>
               <left>0</left>
               <width>1920</width>
               <height>1080</height>
                <randomize>true</randomize>
                <loop>yes</loop>
                <imagepath background="true">$INFO[ListItem.Path]/extrafanart</imagepath>
                <aspectratio>scale</aspectratio>
                <fadetime>300</fadetime>
                <timeperimage>5000</timeperimage>
            </control>

This code results in everything loading as it would in the rest of the skin except if there is content in the /extraimage folder this will be displayed over it. If there is no content in that folder nothing occurs. I am not aware of any check that could be made to adjust viability in a conditional manor that would actually work but if you know a way it could be built into Image_Background output but otherwise this is the only way it can be implemented.

[Alanon]

Artwork Beef is the main addon, script.artwork.helper is a support add-on for it adding some minor features. As far as I've tested it, it is not really needed, as my label control mimics the "smartseries" functionality that the support addon provides. Also, keep in mind that merely installing Artwork Beef will not do anything - you still need to rescan the library for artwork from the addon for its properties to be properly registered. A black screen is usually an indication that either the artwork is not yet cached by Kodi, or that every other bit of variable has been bypassed/not working and the black screen is all you have left for background choices. No matter what you do with your artwork, Kodi has to take a snapshot of the image and place it in its cache for future reference. If you have lots of artwork, that may be a part of the problem.

As far as the conditions - the first is there to ensure that Beef is not installed, as that's one of the points of difference which separates the two implementations. The second confirms that the extrafanart setting is on, the third backs it up to make sure that it is not empty in order to activate the Skin Helper mechanism. That, in turn, makes sure that if you have it set up in any way - if SH detected either an extrafanart folder or cached images in the Kodi cache, it would be triggered, as the property would be filled. That's why I was so puzzled with your issues. 

I have no control over Skin Helper's dependencies, whatever the addon demands it needs to get. You certainly need the module for the addon to function properly, as a host of operations is provided and performed by the Skin Helper family of add-ons. It's the single most important thing you must have working for Kodi to work with modern skins. In fact, if Skin Helper backgrounds were inconsistent, it might have been because of a dependency glitch. I'd track down that dependency manually, and either unzip it into the addons folder directly or install it as zip. Many folks have had issues with dependency installations, but that's due to Kodi's internal mechanics, add-on servers, and general OS differences and quirks. If you couldn't get Skin Helper to work in any view-type properly, then that's a signal that it's something a bit more problematic than both our view-type coding.

From the code you've posted, the only thing that I can see that's potentially problematic is that the image background variable also needs to be multiimage control. Also, there are skin settings for the rotation times embedded in the controls (the rotation limit includes), so it would be nice to copy that over as well, to keep things consistent. Also, there are settings that allow for playing video to replace the background, so the visibility conditions should be transferred as well. I still believe that if you get Skin Helper to work properly, you won't need to go through all the trouble of creating a backend, as it should all work out of the box, as it does for the vast majority. Everything keeps coming back to Skin Helper it seems.

[ZERO &lt;ibis&gt;]

I have the required modules loaded so Skin Helper runs properly. I will do some more testing and also make some posts on the related thread to see what the problem is.

[ZERO &lt;ibis&gt;]

Ok, so I have not heard anything for the extrafanart support on skin helper so I have set it in my view mode that it will only enable detection of that folder if the extrafanart option is selected in the menu. I guess you could think of it as a fail over for when the skin helper does not find the extrafanart folder this part of the code will attempt to display the extrafanart folder contents if there is any.

I see the issue you brought up about playback. I got it to display the video box but I also need to get it to display the now playing info as well. If you happen to know the names of these things for me to look up the code for in the skin it would save me some time.

Hopefully, once I get the video and playing info added into the views it will be ready for prime time.

Also there is one thing I have runinto in the skin itself that I am not sure if there is a toggle for or perhaps something that could be updated. The contex menu does not "wrap" and as a result navigation is slower and clunkier than needed. If I could press the left key once to simply loop to the last item rather than needing to spam the right key it would be more functional.

[chrisjcks]

When I enable an intro video in Skin Settins>Extras...

There is a blank screen pause for a few seconds before it starts on boot, how do I stop this pause?

[Alanon]

Ok, so I have not heard anything for the extrafanart support on skin helper so I have set it in my view mode that it will only enable detection of that folder if the extrafanart option is selected in the menu. I guess you could think of it as a fail over for when the skin helper does not find the extrafanart folder this part of the code will attempt to display the extrafanart folder contents if there is any.

I see the issue you brought up about playback. I got it to display the video box but I also need to get it to display the now playing info as well. If you happen to know the names of these things for me to look up the code for in the skin it would save me some time.

Hopefully, once I get the video and playing info added into the views it will be ready for prime time.

Also there is one thing I have runinto in the skin itself that I am not sure if there is a toggle for or perhaps something that could be updated. The contex menu does not "wrap" and as a result navigation is slower and clunkier than needed. If I could press the left key once to simply loop to the last item rather than needing to spam the right key it would be more functional.

Yup, that sounds as the safest option. Looking forward to testing it out!

For the video playback, you need a videowindow control (look for line 693 in Includes_Furniture.xml). As for the nowplaying data, you can find the code itself in the Label_RSS starting from line 275 in Includes_Label.xml. As for the actual thing, it is already integrated into the myvideonav.xml through the Furniture_RSS global include. You can find the include itself in the includes_Furniture.xml starting with line 324. It's a whopper, as it's used for many, many things.

Regarding the context menu, as far as I know, it's not possible, as the menu that's populated is not a list at all, but a series of independent buttons within one large include. I'm not sure why it was done like that, but I'd guess that it's because many of those context buttons have set values and need to be referenced via a specific ids. That include is a part of a group list, which pretty much makes it impossible to introduce any sort of wrap without finding a way of completely redefining everything, which I'm not even sure is possible.

When I enable an intro video in Skin Settins>Extras...

There is a blank screen pause for a few seconds before it starts on boot, how do I stop this pause?

There's no way to eliminate it, as Kodi and the skin both need some time to initialize, which will depend on the system specs and other differences. The skin is set up to play video at its earliest, but when that point will be is not up to Kodi or the skin. For some systems, it takes whole minutes before Kodi is even usable, so it can vary greatly.

[PantsOnFire]

@Alanon

In my Music Library 'Latest Added' section, I'm using the Fanart/Thumbs List view.  It's my preference because I enjoy the album artwork rendered at this big size.

My question is: is there any way (via XML etc) to make the skin sample the folder.jpg at a higher quality for this view? I would assume that the skin is displaying the folder.jpg in the same way as it would for other viewtypes (eg Medium Icon), but at this larger size, the quality is a bit compromised.

Ppl might say to me 'hey, trying to whack a 600x600px folder.jpg into a rectangular space ... You're gonna be cropping the image anyway, why so picky?'

..but personally, I just like to be wowed by big and bold images. The other views on offer, impressive as they are.. the feature the album artwork smaller on the screen.  (This is just my opinion) and so I prefer the landscape'y view of artwork like this.

So.. is there any way to make the skin sample/render these artworks at a higher sample rate?/thumb quality?
(I used to pull a similar trick back in the xbmc days to get the highest quality possible), xTV skin I believe....

For example in the attachment, the image I have set as folder.jpg is 1400x1400, which can potentially look a lot better than it does in this view.

Many thanks. Great skin.

Screenshot