Is there a way to disable fanart disk caching/resizing?

[mkanet]

Since I am able to display phoenix fanart backgrounds as backgrounds (not in a tiny window) and all my fanart is already on SSD, is there a way to disable the process of copying/resizing fanart to the default sageTV cache folder? I would prefer to have fanart pulled directly from the central fanart source folder if possible. I'm not sure how much performance I'll gain by avoiding unnecessary copying/resizing images, but I'd at least like to try to see for myself.

Thanks,
Michael

[stuckless]

Originally Posted by mkanet

Since I am able to display phoenix fanart backgrounds as backgrounds (not in a tiny window) and all my fanart is already on SSD, is there a way to disable the process of copying/resizing fanart to the default sageTV cache folder? I would prefer to have fanart pulled directly from the central fanart source folder if possible. I'm not sure how much performance I'll gain by avoiding unnecessary copying/resizing images, but I'd at least like to try to see for myself.

Thanks,
Michael

You can disable bmt's resizing by setting the scalings to -1 in the web ui. That will prevent bmt from scaling (which will be removed at some point anyways).

But if you are referring to a plugins desire to resize and scale fanart... I don't think you'll want to remove that. Consider a poster size 800x1200... since most plugins will show that poster as the "thumbnail" for the media item, then now sagetv has to load that full size image into the device ram for as many items you have displayed on the screen. This is an exessive use of ram (especially on a hdX00 unit) when you only need a poster size of 200x300.

Also many backgrounds are quite large and the native resolution of an HDX00 is not that large... I forget off hand but the hd300 may only have 1280x720 and the hd200 is less than that. For video playback they support 1080p but the native ui resolution is different. So, loading a background of 2000x1000 is going to have a serios impact on ram... and you don't need an image larger than 1280x720 since that's native resolution of the extender.

Scaling is an important part of gaining performance on extenders. PC clients are not affected as much, but those little extenders will benefit from the smaller images sizes. You may take an up front hit while the plugin scales an image for the first time, but the overall experience (esp on an extender) is worth it, in my oppinion.

[Fuzzy]

In any case, the act of caching is done by the individual plugin, not by BMT/Phoenix, though most DO use the Phoenix API to handle the cache. It would be up to the plugin dev to offer the option to cache or not to cache.

[mkanet]

Hi Sean, thanks for explaining. I didnt realize that graphics resolution in general was limited to less than 1080p on extenders. I thought that only applied to when video is being played full screen and graphics is displayed over it at the same time (overlay graphics/OSD is limited to lower res). It would be interesting to know what resolution they are being displayed at on an extender verses a PC.

I actually already have resizing disabled to -1 in BMT. Most of my menus now actually display fanart backgrounds as backgrounds, not thumbnail images; including video imports menus. There are still a couple of places that dont yet, such as the program guide.

-Michael

Originally Posted by stuckless

You can disable bmt's resizing by setting the scalings to -1 in the web ui. That will prevent bmt from scaling (which will be removed at some point anyways).

But if you are referring to a plugins desire to resize and scale fanart... I don't think you'll want to remove that. Consider a poster size 800x1200... since most plugins will show that poster as the "thumbnail" for the media item, then now sagetv has to load that full size image into the device ram for as many items you have displayed on the screen. This is an exessive use of ram (especially on a hdX00 unit) when you only need a poster size of 200x300.

Also many backgrounds are quite large and the native resolution of an HDX00 is not that large... I forget off hand but the hd300 may only have 1280x720 and the hd200 is less than that. For video playback they support 1080p but the native ui resolution is different. So, loading a background of 2000x1000 is going to have a serios impact on ram... and you don't need an image larger than 1280x720 since that's native resolution of the extender.

Scaling is an important part of gaining performance on extenders. PC clients are not affected as much, but those little extenders will benefit from the smaller images sizes. You may take an up front hit while the plugin scales an image for the first time, but the overall experience (esp on an extender) is worth it, in my oppinion.

[PLUCKYHD]

The resolutions of extenders has been discussed many times.

Hd300 is 1280x720 max any more than that and you are killing and hurting performance in the extender as it has to scale the images down.

Hd100 and hd200 I believe is sill 940x640 or something close to that.

Pushing a full hd 1080p background to an extender is useless and can hurt performance drastically. And Sean was talking about posters beig used as thumbnails if you reread what he said.

[mkanet]

Thanks plucky. Do you know what resolution limitations I'd see on PC clients? I only have one extender, the rest are PC based clients and placeshifter.

Originally Posted by PLUCKYHD

The resolutions of extenders has been discussed many times.

Hd300 is 1280x720 max any more than that and you are killing and hurting performance in the extender as it has to scale the images down.

Hd100 and hd200 I believe is sill 940x640 or something close to that.

Pushing a full hd 1080p background to an extender is useless and can hurt performance drastically. And Sean was talking about posters beig used as thumbnails if you reread what he said.

[Fuzzy]

No real limitations on the PC clients. Other than perhaps texture memory limits depending on your video card. that said, it still doesn't make sense to store/access the images in a resolution higher than it will be used. And caching is still pretty important for PC clients, as the latency is still much faster pulling from a cheap local HDD, than pulling from an SSD over a network.

[PLUCKYHD]

Originally Posted by Fuzzy

No real limitations on the PC clients. Other than perhaps texture memory limits depending on your video card. that said, it still doesn't make sense to store/access the images in a resolution higher than it will be used. And caching is still pretty important for PC clients, as the latency is still much faster pulling from a cheap local HDD, than pulling from an SSD over a network.

Correct network fanart kills a client as can to many high res images on the screen even if a good video card it still has limits.

[mkanet]

I definitely agree that it doesnt make sense to have images larger in resolution than what can be displayed. Hopefully, my extender will cache/resize images to the maximum display size. Whatever it is, I dont notice any performance issues on my extender or any other client with BMT fanart scaling completely disabled.

It seems like the only client that can benefit from not caching (unscaled) fanart images is the local client on the server itself (which I spend most of my time when my wife isn't around on a 1080p TV). This client's fanart is local and on SSD, and the native display area is 1920x1080 on the client on my server.

Is there an option to disable fanart caching for the client on the server? It doesnt make sense to copy 1920x1080 fanart images to the local image cache folder at the same resolution. They are already available on the local fanart repository on SSD.

Originally Posted by Fuzzy

No real limitations on the PC clients. Other than perhaps texture memory limits depending on your video card. that said, it still doesn't make sense to store/access the images in a resolution higher than it will be used. And caching is still pretty important for PC clients, as the latency is still much faster pulling from a cheap local HDD, than pulling from an SSD over a network.

[Fuzzy]

no, I don't think there are any options to configure/enable/disable cacheing on any of the fanart plugins. (As mentioned, this is not a BMT thing, it's implemented by each plugin). I agree, it's wasteful to duplicate them on the server based client, but the added complication, PLUS checking the configuration property every time would cause more complication than it would be worth for this situation.

[PLUCKYHD]

Originally Posted by Fuzzy

no, I don't think there are any options to configure/enable/disable cacheing on any of the fanart plugins. (As mentioned, this is not a BMT thing, it's implemented by each plugin). I agree, it's wasteful to duplicate them on the server based client, but the added complication, PLUS checking the configuration property every time would cause more complication than it would be worth for this situation.

For my plugins it goes back to scaling more than caching. So mine cache on server and client due to scaling to size for performance.

So for a server it is necessary for extenders since they run in the server

[bialio]

Originally Posted by Fuzzy

no, I don't think there are any options to configure/enable/disable cacheing on any of the fanart plugins. (As mentioned, this is not a BMT thing, it's implemented by each plugin). I agree, it's wasteful to duplicate them on the server based client, but the added complication, PLUS checking the configuration property every time would cause more complication than it would be worth for this situation.

You can get into some unfortunate situations if you actually use your server as a client for viewing AND have extenders - there is just one Phoenix/BMT image cache, and images cached for the Server resolution (1080p) will not get cached a second time for the extender res, and vice versa. There isn't an elegant way around this. I run my server headless so don't have to deal with this - all of it's cache is at extender resolution.

btl.

[mkanet]

Hi BTL (or anyone), sorry if I'm being dense, but does that mean if I have resizing set to -1 in BMT for fanart, my HD200 will scale to it's maximum res on-the-fly and the server will get 1080p backgrounds? The Upcoming Movies plugin is able to popup the fanart background on my server's client instantly and almost as quick on my extender/placeshifter for that plugin. I'm not sure why it's so quick compared to other plugins that use phoenix fanart backgrounds fullscreen.

I do have another question... if someone sends a 1080p background (cached or not) to an HD200/HD300, is the on-the-fly scaling done on the GPU of the HD200/HD300? Maybe the GPU of the HD200/HD300 can deal with image scaling faster/more optimally verses using the CPU and software code to downres.

Originally Posted by bialio

You can get into some unfortunate situations if you actually use your server as a client for viewing AND have extenders - there is just one Phoenix/BMT image cache, and images cached for the Server resolution (1080p) will not get cached a second time for the extender res, and vice versa. There isn't an elegant way around this. I run my server headless so don't have to deal with this - all of it's cache is at extender resolution.

btl.

[JREkiwi]

Originally Posted by mkanet

The Upcoming Movies plugin is able to popup the fanart background on my server's client instantly and almost as quick on my extender/placeshifter for that plugin. I'm not sure why it's so quick compared to other plugins that use phoenix fanart backgrounds fullscreen.

I've tried a few different caching/scaling settings over the last few versions. One of them was using the v7phoenix cache which off hand I think is scaled to something like 24% of the screen size. I think another version was using 50% scaling. I've been meaning to look at that part of the code again now that I understand the caching/scaling a bit better.

John

[Fuzzy]

There are ways to do it that work for server, client, and extender. Ideally, the fanart is stored locally on the server. No chaching is used for the server UI (as it's fast enough locally). Cahcing IS performed for the client (no-scale), so it stores the full images locally to the client. Caching IS performed for the extenders/including scaling. It's up to the plugins to handle this check.

[bialio]

Yes, if the plugin is smart enough to not scale on the server you can get around it. But that's up to the plugin dev of course....
btl.

[Fuzzy]

Hey, I don't even scale on the extender.. :-) but then again, the only fanart plugin I've got running is banners only.

[bialio]

Originally Posted by JREkiwi

I've tried a few different caching/scaling settings over the last few versions. One of them was using the v7phoenix cache which off hand I think is scaled to something like 24% of the screen size. I think another version was using 50% scaling. I've been meaning to look at that part of the code again now that I understand the caching/scaling a bit better.

John

v7phoenix cache is about that - it is the size (approx) that the screenshot in the default UI takes up. So it scales it for whatever size the UI is running in. Those cached items can be used for anything, but since it's so small using it as a background would be detrimental (to picture quality and performance).

Ideally you'd want one source of fanart for all your plugins so that you don't have to duplicate things.

btl.

[bialio]

Hi BTL (or anyone), sorry if I'm being dense, but does that mean if I have resizing set to -1 in BMT for fanart,

To be clear, there are a few different places scaling can come into play. The setting you refer to here is what I will call 'source' scaling - BMT downloads the art, and scales (or doesn't) based on this.

From there, you could have additional scaling (more accurately should be called 'caching') that plugins use to scale the source artwork to the size they want it. And if you have a lot of plugins, they could all do scaling differently. I know that PLUCKYSD's stuff uses a different scaling library than my fanart plugin, for instance.

btl.

[PLUCKYHD]

Originally Posted by bialio

PLUCKYSD's stuff uses a different scaling library than my fanart plugin, for instance.

btl.

come on am I HD!