• 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 22
HEADS UP: Filling a list from a directory/plugin
#46
Does setting the streaminfo in python work for you? I tried that a while ago an it didn't work. If it still doesn't, I'll try to fix it.

You also will be able to just do listitem.setart(art) soon (I hope). It was very easy to add (will do a pull request soon) -> https://github.com/Black09/xbmc/commit/d...772d4e95c6
Image
Reply
#47
I get an out of index error when adding all streamdetails. I can catch that error and send it to /dev/null but that isnt good practice i guess so I commented out that part.
Single item does work, but only for the first item of video or music.

adding setArt() would be great.
Reply
#48
I also tested it with the plugin.test.me and everything seems to work fine.

Edit: pull request for setArt().
Image
Reply
#49
(2013-12-15, 23:12)`Black Wrote: I also tested it with the plugin.test.me and everything seems to work fine.
Mind sharing your code, I'm still learning python so it would be a great help.
Reply
#50
I added this to jmarshalls plugin.test.me:

PHP Code:
# add stream info
for keyvalue in item['streamdetails'].iteritems():
    for 
stream in value:
        
liz.addStreamInfokeystream 
Image
Reply
#51
I see what i did wrong there, thx.
Reply
#52
Anyone willing to share code for NODE property that JM said needs to be used in order to set visibility condition on per list item basis?

My python is very far from fluent...
My skins:

Amber
Quartz

Reply
#53
Check how Unflegdged has done this in his script:
https://github.com/unfledged/script.skinshortcuts
Reply
#54
(2013-12-13, 10:21)Martijn Wrote:
(2013-12-13, 10:20)BigNoid Wrote: Yeah, it was much much faster coding a widget then with all the window properties Tongue
Seriously though, its faster then service.skin.widgets, but since it re-loads every time on window load it does need that time everytime, whereas window properties stay in memory and dont necessarily change on window load.

will help with that as i have an idea how to solve it

Any hints?

Does the provider have to be a plugin, or can a script also generate and serve a directory? I have been operating on the assumption that my script can provide the directory to a skin, but just now thought I should confirm.
Reply
#55
I've been profiling the speed of my Skin Shortcuts addon, to try and figure out where the bottlenecks are, and have found that a lot of them actually come from this method of filling a list and so have a couple of requests.

To be fair, these tests were all conducted on a Raspberry Pi (the device I own which shows speed problems) and with BigNoid's Library Data Provider in use (speeds are greatly improved without it, but using it provides a more realistic user scenario.)

Problem 1 is just the time it takes to actually call the script to begin listing items. I understand that this is limited by the physical power of the platform, but my tests have shown - when the system is under pressure (e.g. Processor usage between 90 and 100%) - it can take between four and six seconds to call the script when the URI is changed (when the system isn't under pressure it generally takes between half and one and a half seconds for the script to be called). Knowing the answer is no, is there anything that can be done to speed this up?

The second is probably more specific to my script - when browsing main menu items the submenu that should be displayed (listed by the script) can change very quickly - quicker than it actually takes for XBMC to load the script for the change and much quicker than it takes to actually list the items (especially when the system is under pressure.) This means that there ends up being multiple instances of the script running - several of which are now no longer needed - and taking up processing power. Is there any way the script can be informed that it's no longer necessary to return a value (as the URI has now changed, and another instance of the script is running and will provide the list)? Something similar to AbortRequested would be very useful!

Edit: One more question - is this method meant to work when the list being filled is hidden? I haven't had the time to test this fully yet, but it seems like the plugin is only called when the list is visible (which is to say <visible>true</visible>, I know for certain that it works when a fade animation to 0% is used.) If this is right, is it for any reason other than performance, as it would seem that background loading could improve the ux (on devices other than the Pi!)?

Hope all of that is clear. Any questions, please ask. And any solutions are very welcome!
Reply
#56
(2014-01-08, 06:10)Unfledged Wrote: The second is probably more specific to my script - when browsing main menu items the submenu that should be displayed (listed by the script) can change very quickly - quicker than it actually takes for XBMC to load the script for the change and much quicker than it takes to actually list the items (especially when the system is under pressure.) This means that there ends up being multiple instances of the script running - several of which are now no longer needed - and taking up processing power. Is there any way the script can be informed that it's no longer necessary to return a value (as the URI has now changed, and another instance of the script is running and will provide the list)? Something similar to AbortRequested would be very useful!

My idea (for another add-on) was to use 1 list control containing all submenu items (I want to populate recently added but let's stick to your example and submenu) but in this case you need to set visibility on per item basis in your submenu, so that movie shortcuts are listed when MOVIES are focused in main menu etc. JM suggested this could be done using NODE (if I understood him) but my python skills are very rudimentary so I never understood how would I do this Smile

Anyway, I believe it would be much quicker to populate all submenu items and then flip them on/off then to repopulate them on main menu focus change.

Another thing I noticed is when you use static list with properties, which are populated from a script (like skin.widgets) things are snappier. In another words, it seems that filling window.properties is quicker than filling list contents - don't know why.
My skins:

Amber
Quartz

Reply
#57
(2014-01-08, 12:33)pecinko Wrote: My idea (for another add-on) was to use 1 list control containing all submenu items (I want to populate recently added but let's stick to your example and submenu) but in this case you need to set visibility on per item basis in your submenu, so that movie shortcuts are listed when MOVIES are focused in main menu etc. JM suggested this could be done using NODE (if I understood him) but my python skills are very rudimentary so I never understood how would I do this Smile

Anyway, I believe it would be much quicker to populate all submenu items and then flip them on/off then to repopulate them on main menu focus change.

If you're running a service which is monitoring the first list for change of user focus and then updating the visibility of items in the second list, I imagine it would be significantly faster and I won't be at all surprised when I see addons using your method in the future. However, as I'm not running as a service (which I'd prefer not to for various reasons), I'd still have to have the script called on change of URI as I do now, and then set the visibility from that. This means this method wouldn't have any effect on the waiting time from URI change to script execution or on the multi-execution for me.

I do wonder, though, whether it could be done skin-side. Ask the skinner to have a stringcompare visibility test against a listitem property in both lists. As skins react so quickly to property changes, that has the potential to be pretty much instant. Something I will look into! thanks for the idea Smile
Reply
#58
No, I don't have service add-on either:

In my case I have a container with main menu items:
movies, documentaries, tv shows, tv documentaries, hd clips, concerts, music, etc which are in fact various library sections on a server, each with unique ID

Each of those sections have recently added items that I would like to show when appropriate section is highlighted in main menu - recent movies for movies, recent documentaries for documentaries and so on. Contents of this list can change if a movie has been watched or a new one added at a server side. Thus, list needs to be updated from time to time when URI has been changed. Still, if I have 10 sections on a server it will be inefficient to call a script again each time highlighted section changes in main menu (very much similar to your main menu and subitems) in order to fetch recently added.

Instead, I was going to populate all recently added to single pile but then StringCompare (or some other visibility check) is needed to be supplied by the script itself on per recently added item basis. You can use StringCompare or other check in a skin only if you have static content. When list is filled by a plugin, it's content is empty in a skin and thus there's no place to put visibility checks in a skin code.

What I would like to achieve is:

Quote:liz=xbmcgui.ListItem(item_title, thumbnailImage=thumbPath, visibility="StringCompare(MAIN_MENU_STRING, PLUGIN_ITEM_STRING)")

or some such.
My skins:

Amber
Quartz

Reply
#59
That makes even more sense, and if it's doable verges on the genius.
Reply
#60
I'm declaring it genius.

Using
Code:
liz.setProperty( "node.visible", [visibility condition] )
is working perfectly. Means the script isn't having to run multiple times, and it's faster to boot. Just need to sort out the time taken to call the plugin in the first place, and I'm sorted Big Grin
Reply
  • 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 22

Logout Mark Read Team Forum Stats Members Help
HEADS UP: Filling a list from a directory/plugin1