Does <multiimage> currently not support resource:// paths?

Does <multiimage> currently not support resource:// paths? - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Skinning (https://forum.kodi.tv/forumdisplay.php?fid=12)
+--- Thread: Does <multiimage> currently not support resource:// paths? (/showthread.php?tid=238224)

Does <multiimage> currently not support resource:// paths? - MacGyver - 2015-09-08

Am I correct in guessing that <multiimage> currently doesn't support resource:// paths yet in Kodi 16 alpha 2?

As per here, I just spent 2 hours trying to get this to work:

Code:
<control type="multiimage">

    <description>Weather Multi-image background</description>

    <posx>240</posx>

    <posy>50</posy>

    <width>800</width>

    <height>450</height>

    <imagepath>resource://resource.images.weatherfanart.multi/$INFO[Window(Weather).Property(Current.FanartCode)]/</imagepath>

    <timeperimage>5000</timeperimage>

    <fadetime>2000</fadetime>

    <pauseatend>10000</pauseatend>

    <randomize>true</randomize>

    <loop>yes</loop>

    <aspectratio>stretch</aspectratio>

</control>

but it didn't work, so I'm using this currently because it does work:

Code:
    <imagepath>special://home/addons/resource.images.weatherfanart.multi/resources/$INFO[Window(Weather).Property(Current.FanartCode)]/</imagepath>

Single image controls work fine with the resource:\\ paths.

Any ideas?

RE: Does <multiimage> currently not support resource:// paths? - braz - 2015-09-08

I can confirm that it doesn't work, I tried setting up animated weather icons in Mimic using the resource addons.

RE: Does <multiimage> currently not support resource:// paths? - mkortstiege - 2015-09-09

Will check and PR a fix.

RE: Does <multiimage> currently not support resource:// paths? - Montellese - 2015-09-09

@MacGyver: could you provide a code snippet that I can copy & paste into confluence to be able to reproduce this?

RE: Does <multiimage> currently not support resource:// paths? - MacGyver - 2015-09-09

Sorry, you said confluence.

Replace line 8 in Home.xml

Code:
<include>CommonBackground</include>

with

Code:
<control type="multiimage">

    <description>Weather Multi-image background</description>

    <posx>0</posx>

    <posy>0</posy>

    <width>1280</width>

    <height>720</height>

    <imagepath>special://home/addons/resource.images.weatherfanart.multi/resources/$INFO[Window(Weather).Property(Current.FanartCode)]/</imagepath>

    <timeperimage>5000</timeperimage>

    <fadetime>2000</fadetime>

    <pauseatend>10000</pauseatend>

    <randomize>true</randomize>

    <loop>yes</loop>

    <aspectratio>stretch</aspectratio>

</control>

to show that the syntax is correct and that the addon is installed correctly.

then replace the image path with

Code:
<imagepath>resource://resource.images.weatherfanart.multi/$INFO[Window(Weather).Property(Current.FanartCode)]/</imagepath>

to show it doesn't work.

FYI: you may need to manually install the resource.images.weatherfanart.multi as the mirror server isn't working correctly either.

RE: Does <multiimage> currently not support resource:// paths? - Montellese - 2015-09-09

Thanks will test ASAP. The mirror is working fine for me for resource.images.weatherfanart.multi-0.0.2.zip but the file is huge (824 MB). I'll check if something is wrong with the addon ZIP as version 0.0.1 was only 80 MB in size.

RE: Does <multiimage> currently not support resource:// paths? - MacGyver - 2015-09-09

No, don't it. There is something wrong with 0.0.2 it's 800mb and only shows the prairie images and only static. I could tell you why, but someone turned it into a Texture.xbt file so I have no idea what the structure looks like inside. Needless to say it doesn't work right. Use the 0.0.1 version instead.

RE: Does <multiimage> currently not support resource:// paths? - Montellese - 2015-09-09

See PR8000 for a fix for multiimage resource:// paths.

Concerning the resource image addon both seem to work fine for me but yes there's an issue with the file size of 0.0.2 which uses a Textures.xbt (which was requested by ronie) and I haven't figured out what the issue is yet. But that has nothing to do with the multiimage issue.

RE: Does <multiimage> currently not support resource:// paths? - MacGyver - 2015-09-09

Thanks Montellese. Smile

BTW, I think the file size is ok, but it is showing only a static prairie image and not the files from the multti pack. The high-def images packs have always been HUGE, but being a texture.xbt who knows what's going on inside.

Thanks again for looking into it.

RE: Does <multiimage> currently not support resource:// paths? - Montellese - 2015-09-09

Well the actual size of all the images in it is around 80 MB and when we run texturepacker on it to create an XBT it becomes 800MB so there's definitely something wrong. Unfortunately I don't really know the whole idea behind the texturepacker so it might just be that it's not suited for high resolution and/or large images. My fear is that the LZO compression being applied to the raw images extracted from the JPEGs is much worse than the JPEG compression resulting in much bigger XBTs than the original files.

RE: Does <multiimage> currently not support resource:// paths? - Montellese - 2015-09-09

Forgot to mention that you can inspect XBTs with Kodi's file manager i.e. browse to an XBT in the file manager and open it and you can browse the directories and files in it and you can also view the images by opening them. It's obviously more cumbersome than doing it in a proper file explorer but better than nothing Wink

RE: Does <multiimage> currently not support resource:// paths? - Montellese - 2015-09-09

It looks like my suspicion concerning JPEG compression vs LZO compression might be right. I checked the filesize that the XBT contains for the images which are around 30KB in JPEG and the XBT says that the filesize is 2.5MB and when I open such a JPEG and save it as a BMP (i.e. without any compression) it is around 2.6MB in size. So either we need a better compression for images in XBTs or we shouldn't try to create XBTs for these images.

RE: Does <multiimage> currently not support resource:// paths? - phil65 - 2015-09-09

(2015-09-09, 14:30)Montellese Wrote: It looks like my suspicion concerning JPEG compression vs LZO compression might be right. I checked the filesize that the XBT contains for the images which are around 30KB in JPEG and the XBT says that the filesize is 2.5MB and when I open such a JPEG and save it as a BMP (i.e. without any compression) it is around 2.6MB in size. So either we need a better compression for images in XBTs or we shouldn't try to create XBTs for these images.

I think we shouldnt try to create XBTs for those, skinners also do not put their larger images into XBTs.