[Mr. V]

Are you using them outside of a list?

Yeah outside of a list.

Tested this both on madnox and silvo. I can break the fanart ect.

For example in Silvo the variables for background fanart
<value condition="!IsEmpty(ListItem.Art(fanart)) + !Skin.HasSetting(Disable.Fanart)">$INFO[ListItem.Art(fanart)]</value>

If I add the 'Container.' It wont break.

EDIT: I can replicate the same behaviour in Confluence.

[Hitcher]

ListItem.Art() should only be used inside a list or for DialogVideoInfo, anything else needs Container. adding to it.

[phil65]

ListItem.Art() should only be used inside a list or for DialogVideoInfo, anything else needs Container. adding to it.

Not 100% correct, omitting "Container" works for all media windows (the ones with a <views> tag) and the corresponding infodialogs.
EDIT: ....and also inside all item/focusedlayouts of course.

[Mr. V]

To Clarify using phil65's bit of code;

Code:

import xbmc
for i in range(1, 90):
    InfoLabel = xbmc.getInfoLabel("Container(9000).ListItem.Property(%i)" % (i))

In madnox listitem.art will break. I can set the range to 1200 the the container.listitem.art does not break.

In confluence exactly the same behaviour. In the logs if you set the range at some value over 1200 you will get;
CGUIInfoManager::AddListItemProp - not enough listitem property space!

So in confluence in the background building.xml around line 22

Code:

<control type="image">
            <depth>DepthBackground</depth>
            <include>BackgroundDimensions</include>
            <aspectratio>scale</aspectratio>
            <texture background="true">$INFO[ListItem.Art(fanart)]</texture>
            <include>backgroundfade</include>
            <fadetime>FanartCrossfadeTime</fadetime>
            <visible>!Skin.HasSetting(HideBackGroundFanart) + !IsEmpty(ListItem.Property(Fanart_Image))</visible>
            <include>Window_OpenClose_Animation</include>
            <visible>![Player.HasVideo + !Skin.HasSetting(ShowBackgroundVideo)]</visible>
        </control>

You can break $INFO[ListItem.Art(fanart)] but not $INFO[Container.ListItem.Art(fanart)]. (It is actually all listitem.art that breaks)

As far as I can see a lot of skins use just the plain old listitem.art. Seems like this would be an issue for all skins out there and would explain disappearing artwork on occasions. From my testing I am quite confident madnox is not reaching any property limit.

Is this something that will be addressed in upcoming RC releases?

If not I have a good feeling that atleast in madnox all library view xml are going to have to change the way they display artwork. If the end user does break the listitem.art from everyday use changing skins is not going to work unless kodi is restarted due to missing textures in the media views.

[chrissix666]

Hello and thanks @mikeSiLVO @ronie @phil65 @butchabay @Mr. V @Hitcher  for this thread and your posts

I'm on Kodi 17.6 with Aeon MQ7 Multi-Mod by @latts9923 . I have the same bug $INFO[ListItem.Art(fanart)] stops returning a value since then I alternatively implemented to use all multiimages instead of ListItem.Path use with fadelabel
 control with @rmrector 's ArtworkBeef
https://rmrector.github.io/script.artwor...onfreefun/

I use some fadelabel control multiimage, and per fadelabel control several Listitems are called up at the same time.
Movies: 10 x fanart, 10 x poster, 10 x keyart, 10 x characterart
TvShows: 10 x fanart, 20 characterart

In the following example, up to 30 additional ListItem are queried via fadelabel control:


At first I thought the bug was caused by new Skin.Strings that I put (maybe wrong), and then they collide. But it all works most of the time and the bug occurs only sporadically.

Question: Can the overuse of multiimage via fadelabel control cause this bug?

I have now set the "Container" as prefix of the List.Item on each fadelabel control multiimage and will see if that fixes the bug.

If yes, I would ask @rmrector to put in the ArtworkBeef wiki a note and update it, to use fadelabel control multiimage only with $INFO[Container.ListItem.Art(arttype)] instead of $INFO[ListItem.Art(arttype)]

I will continue to watch this.

____

EDIT 1: Nope, it happened once again also with the changes... but not as frequently as before.