Kodi Community Forum

Full Version: EMINENCE 2 MOD (REVIVED)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I'm cool with whatever Alanon you choose to do with new view designs :-p I'm using this message as an opportunity to re-subscribe to this thread (since I just accidentally deleted all my subs) Undecided and say thanks for a great skin mod while I'm at it. Hey-life is short! - grab a beer at the bar, and one for your mate!
(2017-10-26, 12:35)ZERO Wrote: [ -> ]Oh, no problem we all got things going on. For example I would have finished faster to begin with if I had not lost use my left hand for a few days lol.

You're quite right about the difficulties of maintaining a setup independent of any fanart servers, but your example just me think of something - have you ever tried using an add-on called Toolbox Script? I rarely use it now, but a while back it was indispensable to me. Basically, it's a collection of useful things for skinners, and also includes some front-end Python commands. One of the functions is to manually cache local art and map it as extrafanart to the Kodi database. I used to do this myself whenever I used to download custom fanart, as I noticed that they did not register among the automatically retrieved images. It completely slipped my mind.

Would you mind testing it out? It will automatically go through your entire library, take your locally stored art and give each one its own extrafanartXY reference. If this process is successful, then I believe that it will not be necessary to place any extra code in the skin whatsoever, because either Skin Helper's code or the backup code will automatically begin to work! When I said that for whatever reason those skin helper values weren't being filled, I completely forgot that that's what the script actually forces, it translates the local images into those fields that Skin Helper looks for. I think that this is the best method by far (provided that it works), as it should also make the majority of other skins with similar implementations work properly for you. 

You'd need to install the add-on (from the Kodi repo, I believe) and use any regular viewtype and the last official skin setup before any alterations had been made, just to be safe. Then, simply run the add-on, specifically, the command "Add extrafanart to movie library" or "Add extrafanart to TV Show library". The default setting for the script is to map the first 5 images per movie/tv show, but that doesn't matter for the time being, as it can be altered fairly easily later on. The point is that you should see fanart rotation begin as soon as Kodi restarts or even as soon as the process is complete for either. (Of course, back everything up, just in case of gremlins. That's what I do whenever I use any tool to mess with the database.) 

In the meantime, I'll continue poking the code to see if there's anything to be done in case this fails.
Yea, will test as soon as I can if that works it is just a matter of increasing the support from 5 images to like 60 lol.
I only mentioned the limit because increasing it now world lengthen the time it took to scan the library.

If you like, you could open default.py in the add-on folder with a text editor and manually edit the limit number. It's one of the first values in the file.

As far as I know, there is no upper limit. If this works, Skin Helper should simply register all the images listed by default, with no further intervention needed.

Sent from my LG Spirit 4G LTE
Ok I did some basic testing and it works. I just used the output of $INFO[Control.Getlabel(4430)] to test if the images load.

So once the conditions are fixed for the furniture it should work natively. This is obviously a better solution with the images being cached locally. Now we just got to play with the conditions for Image_Background to ensure it loads when it should.

Then currently the skin will only support up to 20 extrafanart images loaded that way. Hopefully we can expand support to at least 60.

I can test loading lots of images (more than default) later this week.
(2017-10-31, 15:10)ZERO Wrote: [ -> ]Ok I did some basic testing and it works. I just used the output of $INFO[Control.Getlabel(4430)] to test if the images load.

So once the conditions are fixed for the furniture it should work natively. This is obviously a better solution with the images being cached locally. Now we just got to play with the conditions for Image_Background to ensure it loads when it should.

Then currently the skin will only support up to 20 extrafanart images loaded that way. Hopefully we can expand support to at least 60.

I can test loading lots of images (more than default) later this week.

Yep, as far as that goes, it shouldn't be a problem. Here's my new crack at a fully working version. I've modified the code for the fadelabel to go up to 100. As far as I know, there is no upper limit, and it should work. If you edit the addon limit from the default.py that I've described earlier and place it at 100 when you run it, it should automatically cache up to that number of local art images.

Other than that, I've also made a stab at making new conditions to activate the fadelabel. I tried to keep them minimal, to differentiate from both the extrafanart and beef mechanisms. I'm pretty confident that it will work. When you begin the in-depth testing, you can try them out and see if anything is out of the ordinary. Otherwise, this iteration is the same as the one I've posted previously.
Now I always see a black screen regardless of if extra fan art it on or off.

I am checking the conditions now to see if I can find the problem.

Edit line 218 to have condition String.IsEmpty(ListItem.Art(extrafanart1)) instead of !String.IsEmpty(ListItem.Art(extrafanart1)) allows ones with extrafanart to load when the extra fan art option is enabled. However, I still do not see normal fan art load. and you would expect that condition to have results if there was extra fan art...

Also I found another problem with the ep level fiew and extra fan art. Because it is looking for "listitem" it will never find the extra fan art for the ep level view because it is looking for fan art from each individual episode instead of the container the ep is in...
Also I found something interesting,

as long as ListItem.Art(extrafanartX) is listed in the control the individual refrence call to it will return nothing. Example:

<label>ExFA1: $INFO[ListItem.Art(extrafanart1)]</label> will always be blank but <label>C-4430: $INFO[Control.Getlabel(4430)]</label> will always have content.

If you remove all the ListItem.Art(extrafanartX) and I mean all of them from 4430 so that $INFO[Control.Getlabel(4430)] returns nothing then ListItem.Art(extrafanartX) will begin to have a return again as expected. This is very strange behavior.
Yea I think the real problem is going to be the use of ListItem.Art not being able to return the fan art of its container and thus breaking extrafanart from loading in ep level view.

Also the more I look it up trying to figure out how others are getting it to load the more often I am seeing things like $INFO[ListItem.Path]extrafanart/ and $INFO[ListItem.Path,,extrafanart/] being used in a secondary multiimage to load the extrafanart. Also unless there is a way to target the parent this appaers to be the only way to get extrafanart to load for ep level view.

ok I think I figured out the trick to getting them to load and being able to maintain the existing Image_Background var globally.

the trick is to make a toss away multi mage and then use Control.GetLabel(id) to determine if it was able to load anything and if it did then use that as the pointer.

I should have a test version ready today.
Control 4420 is what causes the individual images not to be able to load. I had to completely erase it in order to get anything to load for non extrafanart.
Ok, I have created an updated version where background images are loaded all from the single var it will correctly load fan art and extra fan art.

http://www.ibisgaming.com/media/16x9.zip

Please test and let me know how that works. This should permanently resolve the problem.
(2017-11-02, 15:28)ZERO Wrote: [ -> ]Ok, I have created an updated version where background images are loaded all from the single var it will correctly load fan art and extra fan art.

http://www.ibisgaming.com/media/16x9.zip

Please test and let me know how that works. This should permanently resolve the problem.

Well, just one problem. Artwork Beef won't work without the 4420 fadelabel (it uses different addresses fanart1, etc.), so the line of code that you deleted needs to stay in that place, right before the Skin Helper code. I did add a condition especially for this sort of case so that if you disable or delete the add-on, it should not trigger it's mechanism at all? Perhaps you still have it installed? The problem is that there isn't a straightforward way of distinguishing between what you do locally and what one of the downloaders does, to the point that most downloaders will confuse things if you try and use them next to the local artwork. But the add-on check is one thing that I know works reliably in Kodi - all of the things you mentioned shouldn't matter since it only takes one invalid condition to block off the fadelabel.

(Incidentally, and this is off-topic which is why it's bracketed, but Artwork Beef solves the episode level artwork issue by having all the images registered natively within the Kodi database as fanart1, fanart2, etc, which makes it work on all levels. I think it's achieved by having a universal list of fanart sequences applied to every item through some database mechanic. There is a compatibility option somewhere to retrieve local artwork if it exists and prefer it to all else. When it's checked, then Artwork Beef should perform the task that Script Toolbox did, scraping and translating those local images into its own format for display. The only reason I did not suggest it earlier on is that I believe the add-on currently supports only 20 images per library item, but I presume that the developer would be inclined to add more if I/we ask him, if that's something that appeals to you?)

As for the mess with the conditions, I'm really confused. I always presumed that Kodi had a way of reliably checking this stuff. Perhaps it's due to the fact that exrafanart is an added feature and not native in the database? Regardless, from what I see I think that your new code will work nicely. One thing I did notice though is that there is no longer a need for separate rotation includes inside the viewtype multiimage controls since we properly integrated the fadelabels into the main code. If everything goes correctly, they should simply take the fadelabel includes and apply them. I've deleted them and everything seems just fine. Anyway, I'm hoping that if you simply freeze Artwork Beef that the conntrollabel 4420 line could remain in place without any further consequences. If not, then it's back to the drawing board. xD
The problem at least from what I saw was that as long as the conntrollabel 4420 existed you could never view normal fan art in the skin at all. I will do some more testing but I would worry about creating a condition where as new users have some sort of complicated setup just to get normal fan art to load such as installing and disabling Artwork Beef.

Perhaps I am not seeing normal behavior, it also could just be that you can not have the ListItem.Art(fanart) directly in the 4420 control.

It could also be something stupid that I have a bug with kodi itself on my end. I will continue retests until I can get it to work without completely removing 4420

Also note that the inability to view ListItem.Art(fanart) does not occur on ep level view. It is as if the var is being locked out somehow.
(2017-11-03, 12:09)ZERO Wrote: [ -> ]The problem at least from what I saw was that as long as the  conntrollabel 4420 existed you could never view normal fan art in the skin at all. I will do some more testing but I would worry about creating a condition where as new users have some sort of complicated setup just to get normal fan art to load such as installing and disabling Artwork Beef.

Perhaps I am not seeing normal behavior, it also could just be that you can not have the ListItem.Art(fanart) directly in the 4420 control.

It could also be something stupid that I have a bug with kodi itself on my end. I will continue retests until I can get it to work without completely removing 4420

Well, most people don't use Artwork Beef, so they won't have it installed at all, ever. The majority of users are simply used to using Skin Helper + Artwork Downloader combo. That's the way most skins set up their artwork management, and that's what's in all the Kodi beginner tutorials. Artwork Beef was always intended as an addition to the regular option - that provides some more complicated options and benefits for the people who need them - as there aren't many skins that support it and it requires a procedure and understanding that most users aren't used to. Granted, the solution is far from ideal, but I really couldn't think of anything that would allow for maximum ease, compatibility and reliability, and this ought to work 99% of the time for 99% of users. 

Basically, I'm betting on the fact that you have to know about the add-on first to get the idea to try and use it at all. xD Any automatic artwork management solution requires some setting up, but Artwork Downloader's is simply the norm these days. Of course, if all else fails, I can add a skin setting that switches between Artwork Downloader and Artwork Beef, and we can then use the setting as a surefire condition for the fadelabel, but that is bound to cause confusion among ordinary, non-tinkering users, who will then want to know what this Artwork Beef is, and maybe try it out without properly understanding how it works, and be forced to repair their libraries because of it. Setting up Artwork Beef properly is a process, regardless if you come from Artwork Downloader or not. I'd like to avoid this potential pitfall, if possible.

The bug, however, confuses me. Aside from the add-on presence check, there are also conditions that check if either the fanart1 or tvshow.fanart1 that Beef sets up is empty, which should further ensure that if you don't use it, it won't trigger. Even more so, since the mere presence of a control in the variable list should not negate everything - unless it is triggered for some reason, which would only happen if all the conditions were true. The only explanation for that would be that 1) You still have Artwork beef installed, and 2) At some point you ran a partial setup with Beef which left some traces, and thus left some info filed? In that case, the variable would trigger, but since there was no proper setup, it would be broken for almost everything.

Regardless, I'm 90% certain that simply disabling or uninstalling the add-on should cut through all those potential issues and just make the whole line invalid...
Basically something in the program causes the returns of ListItem.Art(fanart) to be null but only if the 4420 control is used. It is some sort of data corruption problem.

Somehow the 4420 control is locking down access to that var when it is running and thus breaks. I am trying to reinstall kodi (17.5) from scratch but it takes a long time to get all the dependencies downloaded to install the skin. I download them all and the skin gives me errors trying to install as if some of the versions are wrong even though I downloaded them from kodi repo. Then the color picker is missing from the kodi repo somehow so I got to download it manually. So might be a few hours before I can get the skin installed to retest.

Hopefully, it is just a bug on my end and after I reinstall everything will work.