[mikeSiLVO]

It happens randomly but just recently it occurred after opening DialogVideoInfo and the ListItem.Art(fanart) infolabel stops returning a value and requires a restart of Kodi.

After it last happened I added it as a label in debug overlay and it just randomly returns an empty value even after switching to Confluence. I checked the log and there is nothing mentioned.

Curious if anybody has had any similar issues?

I have experienced this on both Jarvis-20160114-d6d4e86 and Krypton-20160117-e9ecdb7

Thanks.

[ronie]

sounds like a bug...
if you can find the steps to reproduce it, please create a ticket on trac

[phil65]

I think I already experienced someting in the past and it was related to exceeding the maximum amount of allowed properties. It can easily get reproduced by writing random values to different home listitem properties in a loop. (i think after some houndred calls stuff breaks)

In other words: Your skin probably has become too large.

[ronie]

would be interesting to find out if skins are indeed hitting some limit.
looking at the kodi code, you should see this error in the log in that's the case:
"not enough listitem property space!"

[mikeSiLVO]

sounds like a bug...
if you can find the steps to reproduce it, please create a ticket on trac

I unfortunately cannot reproduce on demand but it does happen "frequently" for me but I am usually doing a lot of skin stuff and performing quite a few ReloadSkin() commands. That is what I originally chalked it up to (since strange things occur for me after too many reloads) but I have since received two users reporting a similar issue.

Here is as much info I can think to provide that seems relevant:
Using phils toolbox script to add extrafanart 1-4 to the library is not affected so only those places where that one infolabel is used like items without extrafanart, music, episodes, movie sets ect... Fallbacks are also not affected. I have not noticed any other art infolabel with the same issue.

I originally thought it was VAR related but after replacing it using the infolabel directly I saw that it just stopped returning a value.

Restarting fixes the infolabel and it outputs a value again.

Curiously it has happened, at least once, immediately following a restart after opening DialogAlbumInfo and returning to the view but I could not replicate it a second time

I do not see a property space limit error in my logs after this happens.

I think I already experienced someting in the past and it was related to exceeding the maximum amount of allowed properties. It can easily get reproduced by writing random values to different home window properties in a loop. (i think after some houndred calls stuff breaks)

In other words: Your skin probably has become too large.

I believe, if I am remembering correctly, you previously mentioning something in the MadNox thread related to too many properties causing disappearing skin textures. Is that similar to what may be happening here?

I do not think I am using too many in the skin currently, a quick search shows 306 instances of SetProperty but over 90% of them seem to be related to SetProperty(MediaMenu,True,home) and opening of the side menu.
Not sure what I should be looking for

Do you have any suggestions?

Thanks for the help so far guys.

Hoping it is not skin related...

[braz]

I've never had it happen during normal use, but I've also experienced it when skinning and reloading the skin numerous times.

[mikeSiLVO]

I've never had it happen during normal use, but I've also experienced it when skinning and reloading the skin numerous times.

It started happening for me, regularly, when using Jarvis and I cannot recall it being an issue on Isengard. Did it ever occur for you on Isengard?

I have had lots of weirdness after reloading the skin a lot but since this has been reported to me by others and I have had it happen even without modifying the skin or reloading it... I am, slightly, leaning toward it being a possible bug.

Nice to know that there is a small, remote, possibility that I may not be as crazy as I think I am

[mikeSiLVO]

Hmmm... Quick update... not sure if this is still relevant but it just occurred again. I was listening to music and paused it for a half hour or so and when I returned to Kodi to continue playback there was no mention of anything but when I pressed back to exit fullscreen music and return to the artist library there was no ListItem.Art(fanart) working...

[butchabay]

Sometimes i have no poster when i hit stop while playing a movie and goes back to library view.
Xperience1080 skin, kodi isengard - openelec

So maybe related to the same Problem using Art(poster).

[Mr. V]

I was having similar issues with madnox/silvo widgets. Randomly poster art would just disappear on some widgets.

I do have some thoughts on the matter. I cant say I have looked in depth on the silvo code for the various views but I am wondering if it could be related to using the same id within different controls in different library views, as i assume all the library views are within the same kodi window.

So for the widgets they are all within the same window. I had all kinds of trouble with the same panel id for artwork, navigation, visibility conditions (using info labels) and sometime the main menu would completely disappear. At first I put all this down to my code and with some experimenting and changing of how I group the controls I was able to overcome the issues, but still at random times I would have problems with disappearing posters and I could see nothing in the logs. My initial thought was due to all the F5 skin refreshes I was doing as a simple restart of kodi would fix the issue.

On grouping the controls this is the issue I was having at the start for Jarvis;
245927 (thread)
Note: StringCompare(Container(9000).ListItem.Property(widgetStyle),Panel) the position of the visibility condition between the two code examples. The second code was my workaround.

I had more trouble with Jarvis than Isengard for these issues.

When updating to Jarvis I had issues with info labels not working for visibility conditions at one point. Not sure if it was a corrupt database or some changes in Jarvis but a rescan of my database fixed the issue (may not be related to the disappearing poster widget but thought it would be good to mention)

With the upcoming widget update every widget has a unique panel id. All my workarounds of changing how I group the controls, how I handled the navigation are no longer needed. Fingers crossed, as I have not noticed any disappearing posters after multiple skin refreshes and skin setting changes.

@mike
You mentioned SetProperty(MediaMenu,True,home). Correct me if I am wrong but the id for the grouplist is 9050 for the side blade menu and this is the same for all views? Is it worth experimenting and making sure all the controls don't share the same id?

So to avoid the same control ids I did Something like this;

Code:

<include name="Info">
    <control type="grouplist" id="$PARAM[id1]>
        <control type="label">
            <label>$INFO[Container($PARAM[id2]).ListItem.Label]</label>
            <visible>IsEmpty(Container($PARAM[id2]).ListItem.TVShowTitle)</visible>
        </control>
    </control>
</include>

And called the code in the an xml like this

Code:

<include name="Info">
    <param name="id1">1000</param>
    <param name="id2">1001</param>            
</include>

It seemed to have done wonders in the widgets. Smoother, faster and everthing just works all the time even after multiple F5 refreshes (time will tell if this has really fixed the issue)

Edit: it would be interesting to know if butchababy uses the same control ids between different library views. Also I am wondering if Jayz2k has had similar issues with his skin as I believe he has resorted to different control ids due to some possible issues with kodi.

[mikeSiLVO]

@Mr.V I think we are talking about separate things... The control id issue with the widgets seems to only be related to displaying dynamic content and using the same id too many times. The fanart isn't being given a duplicate id and that grouplist is the same one being shown everytime so that also shouldn't matter. I was just mentioning how many times I set a property in the skin and most of it was just setting the same prop and clearing it for the sidemenu so I did not think it is the reason for this but since I have no idea, it seemed the more info I could provide the better

Something new with this issue:

watch gallery

The third label on the left is $INFO[ListItem.Art(fanart)] in a label control. When this last happened it starting displaying a genre instead of an empty value.

Displaying the wrong value seems to be pointing toward some kind of bug and my guess is that it might be tied to music playback somehow... Not sure how the skin can cause the fanart infolabel to be empty or output a genre instead but if anybody has any ideas what I should look for in the skin code or anything else I can do and report back here, please let me know.

Thanks.

[ronie]

The third label on the left is $INFO[ListItem.Art(fanart)] in a label control. When this last happened it starting displaying a genre instead of an empty value.

thanx, that's interesting to know. i'm pretty sure it's a bug in kodi.

a potential workaround is being discussed here: https://github.com/xbmc/xbmc/pull/8922

[Mr. V]

@Mr.V I think we are talking about separate things... The control id issue with the widgets seems to only be related to displaying dynamic content and using the same id too many times. The fanart isn't being given a duplicate id and that grouplist is the same one being shown everytime so that also shouldn't matter. I was just mentioning how many times I set a property in the skin and most of it was just setting the same prop and clearing it for the sidemenu so I did not think it is the reason for this but since I have no idea, it seemed the more info I could provide the better

thanx, that's interesting to know. i'm pretty sure it's a bug in kodi.

a potential workaround is being discussed here: https://github.com/xbmc/xbmc/pull/8922

Think I was barking up the wrong tree for some of the widget issues I mentioned. You are correct on the dynamic content with too many ids.


Makes sense now ronie. Cheers.

For the disappearing artwork (a random image here and there), I am thinking it may of been the issue Ronie mentioned. I did have 20 or so widgets setup from different addons with lots of different list item properties between them. ATM i don't have such a variation. I will have to do some more testing and try to break the widget artwork.

[Mr. V]

Thought I would do a quick post in regards to the disappearing fanart.

Its pretty much as mike explained and others, fanart stops returning a value. I am only seeing this in library views.

I have found other ListItem.Art values becoming empty also.

Code:

$INFO[ListItem.Art(fanart)]
$INFO[ListItem.Art(clearlogo)]
$INFO[ListItem.Art(clearart)]
$INFO[ListItem.Art(poster)]
$INFO[ListItem.Art(thumb)]

When the listitem.art becomes empty these values still work;

Code:

$INFO[Container.ListItem.Art(fanart)]
$INFO[Container.ListItem.Art(clearlogo)]
$INFO[Container.ListItem.Art(clearart)]
$INFO[Container.ListItem.Art(poster)]
$INFO[Container.ListItem.Art(thumb)]

EDIT
Question to the kodi dev team.

I ran phil65's script to try and break the artwork. What I noticed was any artwork within a library view that is outside of the list/panel container broke. As I understand currently kodi has a limit of 100 ids reserved for listitem.art and this makes sense. What I don't understand is container.listitem.art did not break (so a workaround for the time being). Do both values count towards the listitem.art limit? If so what I am seeing does not make sense.

[Hitcher]

Are you using them outside of a list?