New Phoenix build (2.3.59)

[stuckless]

This build changes the fanart/image caching to use jpg format rather than the png format. The image quality should still be the same, but, the file sizes are drastically smaller. For example many of my cached images were over a 1mb and the same file as a jpg is around 50k.

Because of this change, the cached fanart that exists right now, will never be accessed again. Before or shortly after updating to the new phoenix api, you should delete your existing cache directory, in SAGE_HOME/userdata/Phoenix/cache/, and then allow it to be rebuilt.

I think Phoenix and Gemstone both provide options to pre-scale the fanart, which can take some time, but the option is there if you don't want to do it on demand.

If you don't prescale the fanart, then for the next few times that you use Phoenix/Gemstone then you'll notice some pauses as you navigate, since it will be rescaling and caching the fanart on the fly.

[JREkiwi]

stuckless, thanks for the change, it certainly makes a huge difference to the size of the files.

The "Phoenix Fanart for SageTV" plugin also has an option to pre-scale the fanart, which like Gemstone should be run from the predominantly used UI as the scaling is based on UI width.

John

[stuckless]

Originally Posted by JREkiwi

stuckless, thanks for the change, it certainly makes a huge difference to the size of the files.

The "Phoenix Fanart for SageTV" plugin also has an option to pre-scale the fanart, which like Gemstone should be run from the predominantly used UI as the scaling is based on UI width.

John

Yeah, I didn't realize just how much of a difference that jpg/png formats would be. I hoping there are no other side effects of switching to jpg.

There is also a new property in the Phoenix Fanart section for image compression. The default is set to 0.82, but for those that want to tweak this... you can search for the setting in the bmt configuration, "compression", and set it to a value between 0 and 1.0 where 1.0 mean no compression, and 0 mean compress ALOT. I think the default settings should suffice for most people, but, I know there are "tweakers" out there

[tvmaster2]

Originally Posted by stuckless

This build changes the fanart/image caching to use jpg format rather than the png format. The image quality should still be the same, but, the file sizes are drastically smaller. For example many of my cached images were over a 1mb and the same file as a jpg is around 50k.

Because of this change, the cached fanart that exists right now, will never be accessed again. Before or shortly after updating to the new phoenix api, you should delete your existing cache directory, in SAGE_HOME/userdata/Phoenix/cache/, and then allow it to be rebuilt.

I think Phoenix and Gemstone both provide options to pre-scale the fanart, which can take some time, but the option is there if you don't want to do it on demand.

If you don't prescale the fanart, then for the next few times that you use Phoenix/Gemstone then you'll notice some pauses as you navigate, since it will be rescaling and caching the fanart on the fly.

there are several dirs within the 'cache' dir on my system. "Imagetrans" and "url". Which one is related to Phoenix?

[stuckless]

Originally Posted by tvmaster2

there are several dirs within the 'cache' dir on my system. "Imagetrans" and "url". Which one is related to Phoenix?

Well, since they are all in the userdata/Phoenix/cache dir, they are all related to Phoenix

But the imagetrans is related to fanart, and the url, is related to metadata fetching, and there may be lots of other sub directories, depending on whether or not Gemstone is installed, or if you are using the bmt web ui, or the android client.

[tvmaster2]

Originally Posted by stuckless

Well, since they are all in the userdata/Phoenix/cache dir, they are all related to Phoenix

But the imagetrans is related to fanart, and the url, is related to metadata fetching, and there may be lots of other sub directories, depending on whether or not Gemstone is installed, or if you are using the bmt web ui, or the android client.

yes, I am using BMT, or I did when I rebuilt my system and lost some info. SO the imagetrans dir seems to contain all the png files - so trash that dir?

[stuckless]

Originally Posted by tvmaster2

yes, I am using BMT, or I did when I rebuilt my system and lost some info. SO the imagetrans dir seems to contain all the png files - so trash that dir?

Yeah, there's never any harm in trashing the entire cache dir... the worse thing that happens is that it gets rebuilt again over time.

But, specifically, the userdata/Phoenix/cache/imagetrans/ dir contains all the image transformations (ie, scaled images) for Phoenix fanart API, so deleting that just deletes the cached scaled fanart. And since png files are not used any longer, you can be picky and just delete the .png files if you want, or to be sure, blow it all away.

[PhilH]

Thank you very much for this change.

I am running SageTV on WHS v1.. I was running out of free space on C: drive..

I moved the fanart directory off of the C: drive & that freed up a good bit of space, but the cache was eating me up. I had 12.4 gig free space without the cache & only 7.8 free after the cache was built.

Now I have 11.9 GB free.. The cache size now is only 494 Meg.. With 6608 items.

Us WHS users wish to thank you..

Phil

P.S. My Fanart dir currently sits at 4.61 gig.. Great compression on the .jpg's.. The look as good as the png's...

[appelm]

I think I updated as explained but now my posters are low quality with jagged edges. Much faster! But not too pretty. What can I do to fix it? I'm specifically looking at center flow and to less degree list flow.

[HokiePerogi]

Ever since installing this update earlier today, I am missing all of the banner artwork in my TV submenu which is run by TVExplorer.

I know this isn't a TVExplorer thread, but I'm just wondering the latest update might have affect the API's which some older pluggin's were using. Backgrounds still work in TVExplorer, and if I disable TVExplorer, the banners show up in the Malore menus. Restarts of SageTV and my server don't seem to fix the issue. Neither did a complete delete of my cache and userData folders.

Any suggestions?

Thanks.

[jusjoken]

Originally Posted by appelm

I think I updated as explained but now my posters are low quality with jagged edges. Much faster! But not too pretty. What can I do to fix it? I'm specifically looking at center flow and to less degree list flow.

Are you using Phoenix or Gemstone... if Gemstone then this should be posted in the Gemstone forum.

If using Gemstone (you mentioned Center and List Flows)... then check out the UI Width setting as described in the Gemstone post regarding this change.

If using Phoenix UI then I am not certain if there is such a setting... so hopefully someone else can respond that does use the Phoenix UI.

k

[Skirge01]

Originally Posted by HokiePerogi

Ever since installing this update earlier today, I am missing all of the banner artwork in my TV submenu which is run by TVExplorer.

I know this isn't a TVExplorer thread, but I'm just wondering the latest update might have affect the API's which some older pluggin's were using. Backgrounds still work in TVExplorer, and if I disable TVExplorer, the banners show up in the Malore menus. Restarts of SageTV and my server don't seem to fix the issue. Neither did a complete delete of my cache and userData folders.

Any suggestions?

Thanks.

I just posted the same thing over in the TVE thread. At least I know it's not just me now.

EDIT: Also, I just looked at the image cache for TVE and all the new JPG banners and posters have the red hue to them. I recall this happening once before quite some time ago and someone had to fix something, but I can't remember who or what.

EDIT #2: I suspect they're actually being "displayed" because the text "banner" which should show when there's no image is NOT showing up either. However, for shows which did not have banners (e.g. American Horror Story), the text is there.

[Skirge01]

Rather than adding edit #3, I'll reply so it doesn't get lost. I just manually copied an original JPG poster from the server (no red hue) and renamed it on the client PC in the cache folder to its matching, red-hued JPG. That one now shows up as expected. So, I do believe the issue is caused by the red mask.

[routerunner]

Originally Posted by JREkiwi

stuckless, thanks for the change, it certainly makes a huge difference to the size of the files.

The "Phoenix Fanart for SageTV" plugin also has an option to pre-scale the fanart, which like Gemstone should be run from the predominantly used UI as the scaling is based on UI width.

John

Well, the huge file size was the main reason why I begged you to implement the "Don't Scale" option, remember? So, I do hope that this change will maintain the current "Phoenix Fanart for SageTV" plugin's behaviour as is, correct?

Also, you never commented my proposal to copy the original fanart file from the repository to the cache "as-is" when "Don't Scale" option is selected for easy relocation to RamDisk...unless the new Phoenix Fanart property set to 1.0 and enabling the cache on your plugin will now produce the "as-is" copy? Please comment

thanks
Eddy

[stuckless]

Originally Posted by routerunner

Well, the huge file size was the main reason why I begged you to implement the "Don't Scale" option, remember? So, I do hope that this change will maintain the current "Phoenix Fanart for SageTV" plugin's behaviour as is, correct?

Also, you never commented my proposal to copy the original fanart file from the repository to the cache "as-is" when "Don't Scale" option is selected for easy relocation to RamDisk...unless the new Phoenix Fanart property set to 1.0 and enabling the cache on your plugin will now produce the "as-is" copy? Please comment

thanks
Eddy

The "compression" setting of 1.0 has nothing to do with scaling. ie, In the fanart caching, the images will still be scaled, but if 1.0 is used they will not be compressed. (Chances are your current originals are already compressed as well). Any ways, I just wanted to comment on the compression setting, since it has nothing to do with scaling.

[routerunner]

Originally Posted by stuckless

The "compression" setting of 1.0 has nothing to do with scaling. ie, In the fanart caching, the images will still be scaled, but if 1.0 is used they will not be compressed. (Chances are your current originals are already compressed as well). Any ways, I just wanted to comment on the compression setting, since it has nothing to do with scaling.

OK, I understand, many thanks.

A very minor thing, but if by "compression" you did mean JPEG quality, then I would personally prefer to use 0-100 instead which is the standard way JPEG images normally gets specified.

Eddy

[stuckless]

Originally Posted by routerunner

OK, I understand, many thanks.

A very minor thing, but if by "compression" you did mean JPEG quality, then I would personally prefer to use 0-100 instead which is the standard way JPEG images normally gets specified.

Eddy

I opted to use the same datatype the java api uses... because, well, this isn't my day job, and so I tend to want to get through it as quickly as possible. Using a float mean I just pass the value as is.

[JREkiwi]

Originally Posted by routerunner

Well, the huge file size was the main reason why I begged you to implement the "Don't Scale" option, remember? So, I do hope that this change will maintain the current "Phoenix Fanart for SageTV" plugin's behaviour as is, correct?

This doesn't change how the "Don't Scale" option works. It is still not scaling or caching.

Originally Posted by routerunner

Also, you never commented my proposal to copy the original fanart file from the repository to the cache "as-is" when "Don't Scale" option is selected for easy relocation to RamDisk...unless the new Phoenix Fanart property set to 1.0 and enabling the cache on your plugin will now produce the "as-is" copy? Please comment

If I recall, your issue with setting the scaling size to "Full" was that the file sizes were larger than the originals. With this API change with scaling set to Full and a compression setting of 1.0, it will result in a "copy" (not sure how "as-is" it will be) in the cache. It might get the results you are looking for.

John

[routerunner]

Originally Posted by JREkiwi

If I recall, your issue with setting the scaling size to "Full" was that the file sizes were larger than the originals. With this API change with scaling set to Full and a compression setting of 1.0, it will result in a "copy" (not sure how "as-is" it will be) in the cache. It might get the results you are looking for.

Hi John,

thanks for you reply, it looks like it might work, basically from what you're saying the Phoenix API should look for the compression value and if 1.0 then it should provide the unmodified file to you ("as-is") and the "Full" option in your plugin should save the unmodified file into the cache and using it thereafter. It would make more sense with the "Don't scale" option, but that is the special case you are using to read directly from the repository...

A good binary file comparison should give a definitive answer

Eddy

[stuckless]

Originally Posted by routerunner

Hi John,

thanks for you reply, it looks like it might work, basically from what you're saying the Phoenix API should look for the compression value and if 1.0 then it should provide the unmodified file to you ("as-is") and the "Full" option in your plugin should save the unmodified file into the cache and using it thereafter. It would make more sense with the "Don't scale" option, but that is the special case you are using to read directly from the repository...

A good binary file comparison should give a definitive answer

Eddy

I think the files will not be the same at a bit level. Since the headers may have changed. But the "image" might be the same.