[realcopacetic]

Thanks @mame09 I'll try and check this out over the weekend.

Sorry I'm not really up on coding, can you explain the output log. What do the different numbers mean?

It's strange that the issue persists even when you remove the includes file containing the secondary list. That perhaps implies it's something wrong with the primary lists do you think?

As I understand it, preload only prefetches a max of 2 items (or rows/columns for a panel) - https://kodi.wiki/view/Image_Control.

And I think it only preloads images that have the background="true" argument included. 

So without that argument, I think nothing should be preloaded and also the textures should only be loaded into memory when their visibility conditions are met: https://kodi.wiki/view/Image_Control

So it could well be that there is another culprit at play if you've disabled background loading. The only other lists I have that are loading textures would be the widgets on the home screen and the old ones on the video info. The home screen ones are new, the ones on the video info are a mess. If I can figure out how to use your addon, I'll see if disabling those makes a difference.

[realcopacetic]

Thanks @Zazamastro - glad you like it

[mame09]

Sure. 

Sorry I'm not really up on coding, can you explain the output log. What do the different numbers mean?
Sure. So the application I wrote is kinda simple. It simulates 10 folders. Inside each folder, there are another 10 folders. And inside these ...
ROOT is the first view containing said 10 entries, that gets displayed. Thus the output log displays, that ROOT has been visited.
As I scroll to the third entry (in programming, we start counting at 0, thus it is ID2), each time an entry gets selected/passed, the output log registers, that the path associated with the entry gets visited (twice).
This should not have happened at all.

E.g.: I start the addon. I scroll towards the third entry. I click on the third entry (ID2) and a new view opens.
This resulted in this part of the log.

xml:


ROOT

ROOT_0

ROOT_0

ROOT_1

ROOT_1

ROOT_2

ROOT_2

ROOT_2

ROOT_2_0

ROOT_2_0

But in reality, it should have been like the pseudo log below, as I have not clicked on either of the entries, except the third one (ID2).

xml:


ROOT

ROOT_2

That perhaps implies it's something wrong with the primary lists do you think?
That is my impression, yes. I do not think, that it has to do something with the images associated with the entries.
But rather, that when (e.g. transferring the example to music) I go through the list of artists, the list of albums associated with each artist is preloaded (twice?) without actually opening the album view.

I hope the example above made it more clear.
​​​​​​​If not, I am happy to help

[realcopacetic]

Sure. 

Sorry I'm not really up on coding, can you explain the output log. What do the different numbers mean?
Sure. So the application I wrote is kinda simple. It simulates 10 folders. Inside each folder, there are another 10 folders. And inside these ...
ROOT is the first view containing said 10 entries, that gets displayed. Thus the output log displays, that ROOT has been visited.
As I scroll to the third entry (in programming, we start counting at 0, thus it is ID2), each time an entry gets selected/passed, the output log registers, that the path associated with the entry gets visited (twice).
This should not have happened at all.

E.g.: I start the addon. I scroll towards the third entry. I click on the third entry (ID2) and a new view opens.
This resulted in this part of the log.

xml:


ROOT

ROOT_0

ROOT_0

ROOT_1

ROOT_1

ROOT_2

ROOT_2

ROOT_2

ROOT_2_0

ROOT_2_0

But in reality, it should have been like the pseudo log below, as I have not clicked on either of the entries, except the third one (ID2).

xml:


ROOT

ROOT_2

That perhaps implies it's something wrong with the primary lists do you think?
That is my impression, yes. I do not think, that it has to do something with the images associated with the entries.
But rather, that when (e.g. transferring the example to music) I go through the list of artists, the list of albums associated with each artist is preloaded (twice?) without actually opening the album view.

I hope the example above made it more clear.
If not, I am happy to help

thanks for the explanation. I tried the link you shared but it says it's deleted. Could you reshare it and I'll try to investigate what's causing the issue.

Because I ended up manually building most of my views instead of relying on the built in list types to get the animations I wanted, the views are seperated into an empty list include and a seperate view include. I wonder if something with the way I've structured things means that multiple lists are running at the same time - for billboard, showcase and strip views.

[mame09]

Sure: https://www.mediafire.com/file/knwo1w875...r.zip/file
Hopefully the link will stay up longer

[realcopacetic]

hi @mame09 - thanks for the link. I installed it last night and understood how it works once playing around with it.

Firstly, I can confirm the double lookup was indeed the secondary lists. Removing all the "Secondary_List" includes from "Includes_MyViews.xml" indeed makes the problem go away. I think the reason why this behaviour was persisting even when you disabled Secondary Lists in the skin settings or removed "Includes_Secondary_List.xml" from the main "Includes.xml" file can only be explained by my sloppiness (I'll blame chronic sleep fatigue and dealing with two young children!). With the first, I think I just forgot to actually link the skin boolean to a visibility condition, and with the second, I think the conditions I added to my primary list navigation were trying to focus the secondary list (id: 4501) even when it wasn't there. The focus was then passing back to the primary list (e.g. id=50) when it couldn't focus 4501. I can only guess that this might have been causing the second ROOT entry if the path was visited a second time when 50 took back focus.

Anyway, I can confirm using your addon that disabling the secondary list in skin settings now prevents any additional ROOT entries from being created. The secondary list is no longer visible during scroll animation of the primary list, which is 360ms (*0.8 because I've set a slight acceleration on all my animations in the addons.xml file).

I can confirm that this drastically cuts down the number of ROOTs in your addon.

I've also tightened up the visibility conditions for the secondary list so it should only be running when the primary list is focused on any of these four conditions:

xml:


Container.Content(movies) + ListItem.IsCollection]

Container.Content(sets)

Container.Content(tvshows) + Integer.IsGreater(ListItem.Property(TotalSeasons),1)

Container.Content(artists)

 

I believe your dummy addon is set as as Container.Content(tvshows). So it will no longer record any additional attempts to access ROOT because the ListItem.Property(TotalSeasons) will be blank. 

You might want to test it out for Artists to get a better sense of the impact on your network resources, as in this view, the secondary item will be visible for every ListItem in the primary list.

I've pushed an update: https://github.com/realcopacetic/skin.copacetic

[mame09]

Hi Quizkid

With my addon unchanged and the skin being updated to 0.0.189 I get the following log:

xml:


ROOT

ROOT_0

ROOT_1

ROOT_2

ROOT_3

ROOT_5

ROOT_4

ROOT_7

ROOT_8

ROOT_6

ROOT_8

ROOT_8_0

The double entries are nowhere to be found   
Thanks!

One question though.
As I did not change anything in my addon yet - shouldn't the output rather be the following (e.g. I open the addon, scroll towards entry 8 and click on it):

xml:


ROOT

ROOT_8

Do you get the same results as the first log or the second one? In the case of the first log, would it be possible, that the singular preloads are also "removed"? Or is that rather difficult due to the structure of the skin?

Many thanks again,
mame09

[realcopacetic]

@mame09 bear in mind the reason there's no duplicates is because your addon is set to tvshows but doesn't provide a TotalSeasons value, so the new visibility condition for the secondary list will always be false. For Container.Content(sets) or Container.Content(artists) the visibility condition is less strict because it is assumed there will be secondary list content for every item in the primary list (movies in the set, albums by the artist) so you will have to disable secondary lists in skin settings to avoid duplicate entries in your log.

I do wonder though, if the duplicatrds are from the secondary list, should it not instead look like this? Because after each item is looked up, the first child item would be what should be in the secondary list.

xml:


ROOT_0

ROOT_0_0

ROOT_1

ROOT_1_0

etc

Regarding your question, I'm not sure, I'll have to look into it. Is that standard behavior on other skins when scrolling, do you know?

xml:


ROOT

ROOT_8

I assume it would need to look up every item to know what to populate there list with? Otherwise wouldn't the list go blank while scrolling?

[realcopacetic]

@mame09 I just tested on Estuary and indeed it just shows ROOT until you click. It's something I'll need to look into. What exactly Kodi is doing when ROOT is recorded in the addon?

[realcopacetic]

@mame09 - I think I found the culprit. A hidden list in my <include name="MyViews_Hidden_Controls"> that is used for checking actor/set info, but appears to be running all the time. I think I was using this for some infoscreen widgets and info labels primarily, I'll have to go through the code and figure out a better way to do it. The infoscreen widgets need redoing anyway. But in the meantime, if you delete this code, it should stay on ROOT until you click an item.

xml:


    <!--Hidden set/actor/seasons list-->

            <control type="list" id="4500">

                <width>0</width>

                <height>0</height>

                <orientation>vertical</orientation>

                <itemlayout />

                <focusedlayout />

                <content sortby="year" sortorder="ascending">$VAR[Sets_Path]</content>

             </control>

Hopefully this eases the required network resources in the meantime

[mame09]

Hi Quizkid,

Deleting the abovementioned code lines did indeed fulfill the job

I think since the skin is still WIP and the bug more or less affects legacy or WIP code, one may do a cut here and just mark this problem as solved for now.
Thus, thank you very much for taking your time in investigating and fixing this bug !

I am pretty stoked about how this skin will turn out during the next months of development!

[Romik2505]

I have a question, where can I download the zip file for that skinned. I am from Poland and I am happy to test it.

[Romik2505]

I have a zip, but I can not install, because the error of dependency version xbmc.gui version 15.14.0.

[Romik2505]

Sorry 5.14.0

[realcopacetic]

What version of Kodi are you using? This is currently for Matrix only, although if you are still on Leia I think it will work if you change the xbmc.gui version in add-ons xml.

You can get the current version here: https://github.com/realcopacetic/skin.copacetic