[Alanon]

@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.

I understand completely. I obsess over finding and embedding all my music with high res artwork so that it would always bypass any caching or crap. In fact, that's one of the reasons why I don't really use Kodi for music. As far as the views go, I've always tried to keep true to the skins general design, which limits available space with all its headers footers and stuff. 

I have also been thinking of a way to introduce more/better artwork, but it just can't be done without removing the upper header. Though I might make a minimalist view, as it would be fairly easy, something similar to the Lovefilm, only fullscreen. No clock, no flags, just some info and huge artwork. Though, I don't know how appealing something like that would be to folks?

Basically, if a trick to do what you suggest exists, I don't know of it. The problem is that nowhere is the actual size of the images specified, only the dimensions of the frame itself. Kodi's own scaling algorithms apply for handling the matching of the images to the frame, and I believe that's where the degradation happens. I think that anything except for 100% AR compatibility will trigger some form of the scaling algorithm. 

I'd suggest doing a test and introducing manually cropped artwork to some of your files, just to see - if I'm right, the scaling algorithm will not activate if the image is already 16:9, and you'll end up with slightly improved image quality. Incidentally, that's the reason why you have the larger text list and square artwork space if you're browsing music content and using the ordinary list view. That's as far as I could take things with combatting the scaling issues while remaining true to the skins' design.

Of course, all this could be avoided by having the AR preserved or even set to stretch, as to my eye even the stretch is less degrading to the overall image quality than the scaling algorithm. But then, many people have different preferences. If I have the time and strength, I might introduce a global switch for these image treatments, but that's a very arduous task...

[PantsOnFire]

From the Wiki:[/i]
"2.4 Library artwork
2.4.1 imageres
This tag is new for v12 (Frodo), replacing <thumbsize>.
Specify the maximal resolution that art should be resized to in pixels. The width is automatically calculated as being 16/9*height. The image will be resized to fit within this size. e.g. an image that is 2000x500 will be cached at size 1280x320. An image that is 500x800 will be cached at size 450x720 using the default value of 720."

Wiki page here:
AdvancedSettings.XML wiki page

Also, if you look just under 2.4.1, the next setting is to do with fanartres (2.4.2)

EDIT:
There's also section 2.4.5 imagescalingalgorithm where you can choose from about 10 different methods. But there isn't much info there about each method. Some will obviously take longer than others. I wonder which it uses by default? (bicubic is given in the example, I wonder if that's it?)

I'd suggest doing a test and introducing manually cropped artwork to some of your files, just to see - if I'm right, the scaling algorithm will not activate if the image is already 16:9, and you'll end up with slightly improved image quality.

I tried it, you're 100%, the resulting artwork looks very clean.

Incidentally, that's the reason why you have the larger text list and square artwork space if you're browsing music content and using the ordinary list view. That's as far as I could take things with combatting the scaling issues while remaining true to the skins' design.

Yeah the List view is great for that clear artwork I know what you're saying.. the only reason I preferred to use Fanarts/Thumbs List is because I personally don't want/need the 'date added' information which is given on that view. It would be more useful to me to have say.. the album release date on that page (but that's a different matter, and not something that I believe can be read from an ID3 tag anyway :-p)   can't have it all!

When it comes to the topic of stripping out information, I even think users could get by without the 'sort by:'   and 'information'  texts on the UI. Ok maybe not the 'information' part so much, as that's a fair title for what would potentially be the synopsis of a film beneath it. But really, once you've gone to the top bar (hidden menu) and chosen to arrange in whatever order, you've already made your choice, so why would you need it written again on the UI? minor thing really. just my opinion. --and it's nothing against this skin at all, it's been that way since forever in Kodi iirc. I also go ahead and remove the scrollbars as they're all extra (mostly useless things to have on screen) -again IMO. Great to have that option BTW - is this something you added yourself for this skin? because I don't remember it anywhere before..

Of course, all this could be avoided by having the AR preserved or even set to stretch, as to my eye even the stretch is less degrading to the overall image quality than the scaling algorithm.

I might be misunderstanding you here, are you saying you wouldn't mind for example a square 1000x1000 image stretched to 16:9 (distorting it's AR)? I think that would look worse than a reduced thumb quality (but that's just my opinion), --and I may have misunderstood you anyway.

[Alanon]

Interesting.. what do you use for your music then? For me, I've used Kodi more than almost anything over the last few years (since my old PC died, I migrated all my music to a low-power hdd and said goodbye to a lot of my old externals (cos I'm running off a rPi now). It sucked that the PC died, but tbh, I enjoy the peace and quiet!

Basically, foobar2k with autoplaylists and a rigorous folder structure. The thing is, once I'd set it up properly, Kodi and it's caching cr*p could just never compete. xD 

I think it's a very cool idea personally. The only thing I would think essential to keep would be the clock. This skin is lovely though, I have always liked the tilted section header icons  (top-left) (Music, Movies etc..)  -think you'd keep those? It must be a tricky thing, to try and go minimal but not to the point where people are left at sea.

That's just the thing - if I keep them, then they'd have to take up that space on the top. In theory, I could simply keep the upper section and expand the content at the expense of the bottom stuff, but I'm not sure just how great an improvement that would be. Another way would be to move stuff around - for example, make the header a permanent fixture in the corner of the artwork, sort of like a bent corner, try and have it blend in somehow, and then combine the content list and the clock somehow, so that you could expand upwards as well. 

Yes I'm not answering this bit directly but yeah the advancedsettings.xml file (used to sit in the userdata folder iirc), lets you change a tonne of extra stuff which hadn't really become togglable options yet in Kodi Settings. I used to use a cool cache setting in this xml file which let you increase the buffer, so that if you have buffering issues over your network etc. you could let it fill more cache before starting to play a video. It was very effective. These settings I used to tweak as far back as Kodi (xbmc) 11.

EDIT:

There's also section 2.4.5 imagescalingalgorithm where you can choose from about 10 different methods. But there isn't much info there about each method. Some will obviously take longer than others. I wonder which it uses by default? (bicubic is given in the example, I wonder if that's it?)

I'm aware that there are loads of settings for the xml, but sadly I can't really force that, it's per-user only. If there's a choice of algorithms, then it's definitely worth looking up!

When it comes to the topic of stripping out information, I even think users could get by without the 'sort by:'   and 'information'  texts on the UI. Ok maybe not the 'information' part so much, as that's a fair title for what would potentially be the synopsis of a film beneath it. But really, once you've gone to the top bar (hidden menu) and chosen to arrange in whatever order, you've already made your choice, so why would you need it written again on the UI? minor thing really. just my opinion. --and it's nothing against this skin at all, it's been that way since forever in Kodi iirc. I also go ahead and remove the scrollbars as they're all extra (mostly useless things to have on screen) -again IMO. Great to have that option BTW - is this something you added yourself for this skin? because I don't remember it anywhere before..

It's really only there to have some text there to display, as a point of consistency, so that you'd see it, I guess. As for the scrollbars, yeah, I added the options at the same time I added the alphabet bar. If you don't need them, why not switch them off? Made sense to me. 

I might be misunderstanding you here, are you saying you wouldn't mind for example a square 1000x1000 image stretched to 16:9 (distorting it's AR)? I think that would look worse than a reduced thumb quality (but that's just my opinion), --and I may have misunderstood you anyway.

No no, I'm allergic to that. I hate stretching in every shape and form, to the point of manually cropping non-standard images so that it would not be present. I was only saying that even the stretching algorithm doesn't degrade the image quality like the scaling one does. But as far as I'm concerned, I hate it. xD

[ZERO &lt;ibis&gt;]

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.

Interesting, if each button is independent there must be something that is telling them what to select when pressing right and left so there must be a way to determine what the last and first button ids are and tell the last and first button how to find each other. But like you said there are some things that just have a strange way they are coded which might make it impossible to be able to loop.

Also yea foobar2k is the way to go for music generally. Especially for the ability of ASIO & kernel steaming.

[ZERO &lt;ibis&gt;]

Ok I have finished the views you can download it here: http://www.ibisgaming.com/media/skin.emi...rypton.zip

Please report any bugs or issues so I can correct them. You will likely need to compare the files for changes from the current branch to identify exactly what I have changed in the stock code.

[Alanon]

Ok I have finished the views you can download it here: http://www.ibisgaming.com/media/skin.emi...rypton.zip

Please report any bugs or issues so I can correct them. You will likely need to compare the files for changes from the current branch to identify exactly what I have changed in the stock code.

I took a quick look and tested some things out. First, great job on integrating everything smoothly. I like the way everything turned out!

The most important thing that we have to root out is the fanart, which breaks for me with your code. On my end, everything works smoothly without the image fanart code, but with it included, I get no rotating fanart on episode level and even black screens. I took a look at the code and it seems you included both the background variable and the extrafarant path code. The problem is two-fold: the skin has no way to differentiate between them and basically always goes for the later object. Literally, the image produced by the variable is always overlayed by the extrafanart path image. This might increase the load on low-spec devices, since the skin would still render both at all times. Basically, it's far from ideal, and I'd avoid it if at all possible.

I've taken the liberty of tweaking some things, I hope you don't mind? I integrated the duration backend of the skin with the views, which means that the skin settings for the HH: MM should now be visible in the view. There were some issues with the content types for the views so I made some changes: I expanded the compatibility of the tv shows view-type to envelop movies, movie sets and seasons. I transferred the seasons view from the episodes layout simply because most people use season posters, which can be viewed nicely in the tv shows layout. I also expanded the episodes layout to envelop music videos and video content. So far, everything seems to be working. I also added support for the skin Quicknav feature. These were only minor things that were easy enough to add and do not impact the view-type designs, so I added them in order to save you some time and trouble. 

Finally, I temporarily removed your image code and relied solely on the image background variable. I reactivated an older background backend that I'm hoping might resolve all the issues and achieve universal compatibility. The only theoretical prerequisites that need to be satisfied to activate the mechanism is that you have the Artwork Downloader plugin installed, and that the default fields which Skin Helper usually fills are empty. Based on everything you've told me over our extended communication, that should be the case. The regular variables should simply be skipped until we reach this backend, which should then trigger a special fadelabel control. Still, since I've never encountered issues such as you seem to have, I'd appreciate your feedback on whether it works as it should. Even if they do not, I believe that the mechanism (control label 4430, if you're curious) is sound, and that we'd only need to find the proper way of triggering it.

You can find a link here. I've only changed one or two files, but threw in the whole folder, just to be sure. As far as the backgrounds go, I actually found it much easier to tweak the code directly than for us to go back and forth on theoretical bases. This way you can see what I've done, and perhaps get an idea on how to do it better than we both did. 

That's pretty much it for my comments and changes. If we manage to resolve this background snag, I can proceed to integrate and test everything further, and ship it with the next skin update.

[ZERO &lt;ibis&gt;]

Wow you really did a lot in such a short time! I will be testing out the changes and see what the deal is on getting the extrafanart images to load. That is very strange the result you got on your end with the blank screens. I will make sure to install Artwork Downloader. But how do I ensure that " the default fields which Skin Helper usually fills are empty."

[ZERO &lt;ibis&gt;]

It told me it requires library data provider, so I have also installed that now.

Ok, I now have the contents of the extra fan art folder load but all other content is a black screen. This might be because artwork download ran when it installed and wiped out the database as that plugin is never going to find artwork for anime.

Nope, I checked and the fanart is still there for the items but now nothing loads unless it is in the /extrafanart folder.

When I disable Artwork Downloader, I am able to see all my fanart except that the contents of /extrafanart do not load lol.

Also something to consider is allowing the user of the $INFO[Fanart.Image] for pulling fan art in the EP level view. Using the ListItem.Art(fanart) as currently does show fan art when looking at the eps but then you do not see the fan art when you select the back button which does not look as nice.

line 38 on FanArtIcons.xml should be removed:
<visible>Skin.HasSetting(SkinHelperExtrafanart)</visible>

It prevents any fan art from loading if a user has not selected the extrafanart option.

[ZERO &lt;ibis&gt;]

I have in testing replaced the instances of black with white in the Image_Background to try to debug. It never loaded the white so when artwork downloaded is loaded and extra fan art is selected it is clearly running something that is not returning any content for things that do not actually have extra fan art.

ok yea it returns $INFO[Control.Getlabel(4430)] when extrafanart is selected but the content of that does not return single image fanart. I am now investigating the function this returns to see if I can spot the issue.

[ZERO &lt;ibis&gt;]

Ok I have got something that works. The problem is that because kodi lacks the ability to determine if there is content in /extrafanart if there is nothing there it will display nothing however you can not string empty test it because the path is part of it. I suppose you could do a string contains and look for every possible extension an image file could be but the best solution appears to be to make a second image loader as a fall back.

Also I increased the references to the /extrafnart folder because in testing that resulted in more random images and less of the same one getting pulled again and again.

Please download attached for testing: http://www.ibisgaming.com/media/16x9.zip

Note that I only have modified the views I made for compatibility so if this works the other things that use Image_Background will need the Image_Background2 fall back as well.

[Alanon]

I have in testing replaced the instances of black with white in the Image_Background to try to debug. It never loaded the white so when artwork downloaded is loaded and extra fan art is selected it is clearly running something that is not returning any content for things that do not actually have extra fan art.

ok yea it returns $INFO[Control.Getlabel(4430)] when extrafanart is selected but the content of that does not return single image fanart. I am now investigating the function this returns to see if I can spot the issue.

Yeah, it's because my proposed conditions are crap. xD Skin Helper and Artwork Beef fill those values automatically, and since they don't seem to work for you, I figured that they would be empty. However, I failed to introduce a condition that separates the label entry from the one below it, which provides ordinary fanart. So no matter what, you now get stuck on the extrafanart backend.

I remember there used to be an option to add conditionals like "+ !String.IsEmpty(Control.Getlabel(4430))" for fadelabels, but I'm not sure if they still work. You could try adding it to the list of conditions in line 218 in Includes_Image.xml. If that works, then it will be skipped if there are no files available and move over to the single image fanart. That would practically fix everything. 

If that fails, you could try and go to MyVideoNav.xml, and add an ordinary <label>$INFO[ListItem.Fanart]</label> below line 236, as the very last element in the label control. It's a quick and dirty fix, and I'm worried it might try and rotate and thus introduce slight flicker, due to the label feature, so the former is definitely preferred.

[ZERO &lt;ibis&gt;]

The problem is anything returning the content of $INFO[ListItem.Path]/extrafanart will never be empty even if that folder does not exist and even if there is no content in the folder if it does.

Also I started out by editing the MyVideoNav.xml but because $INFO[ListItem.Path]/extrafanart returns a value even if there is nothing to return adding $INFO[ListItem.Art(fanart)] ~($INFO[ListItem.Fanart] was not working for some reason)~ resulted in randomly seeing fan art and a black screen. If you increased the amount of $INFO[ListItem.Path]/extrafanar it would increase the odds of the black screen showing up and as a result you saw the fan art even less.

Sucks that after all these years Kodi does not have a function that checks if a directory is empty or exists or skinning as that would solve the problem really fast.


It is because of this problem that when you load $INFO[ListItem.Path]/extrafanart you got to do it in a second multiimage call. The simplest was basically how I had it in my original code. What is strange is that you say that this gave you a blank screen for you fan art. I have tried creating empty extra fan art folders I even created a txt file and renamed it to an image file to see if I could get it to mess up but it still loads correctly when using two multiimage methods.

[ZERO &lt;ibis&gt;]

It might be easier for you to see how fan art tends to load on my setup with a simple test. If you install this scraper: https://forum.kodi.tv/showthread.php?tid=142835

Then just make a test folder for an anime and call it Just Because! and create a txt file in it with the content "aid=13199" without quotes. Rename the file to tvshow.nfo

Scan this item into your library and you should get a db entry without any eps to test with. You could always rename a video file Just Because! s01e01 for testing as well. You will find that none of your other addons will get extrafanart for this content so you do not need to worry about them messing with your testing. You will get one fan art image grabbed by the scraper via theTVDB.com if you want extra fanart the only way to have it is to create an /extrafanart folder in your Just Because! folder and add images to it, you could add anything you want to test.

If you are still getting different results than me in testing I recommend trying this.

Hopefully, we will be able to figure out a good solution!

[Alanon]

@ZERO &lt;ibis&gt; 

Sorry for the tardy response, not close to my PC at the moment, it'll take me a few days to get back. I'll take a look at everything as soon as I can. We'll get the ball rolling!

[ZERO &lt;ibis&gt;]

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.