Posts: 300
Joined: Mar 2008
Reputation:
14
All,
Is there anyway of altering a list item once it has been displayed, but without refeshing the entire contents?
I want to alter the watched status (and therefore the 'overlay' property), but without having to reload all 500 items again...
Posts: 26,215
Joined: Oct 2003
Reputation:
187
Not from a plugin (at least not without hackery that you probably shouldn't be doing!)
What is it you're writing a plugin for?
Posts: 26,215
Joined: Oct 2003
Reputation:
187
Technically you'll (potentially) need to refresh the listing (not necessarily retrieve the listing) on change of watched status anyway, as the user may have a filter to apply, so the items will need re-filtering etc.
If you're doing it in response to the XBMC context menu (which you have overridden in your plugin) then we could look into it I should think.
I'm not sure what your startOffset thing is - currently we don't support backends setting that, so we query the local db instead for it. I presume you have the ability to set that directly at time of listing? If so, some changes to the XBMC side would allow that to be taken into account, so that it would work out of the box. I'm not sure if the python side of it can set the startOffset param?
Cheers,
Jonathan
Posts: 300
Joined: Mar 2008
Reputation:
14
Thanks for you reply.
I used to do a container.refresh, but this loaded the whole lot from scratch and took as long as the original build of the view (so around 3-4 seconds for 500 items).
as for startOffset - it's a listitem property i've tested and it works. Set it before addDirectoryItem and it allows the media to be started at a point part way through - the only problem I have it that I ask the user before playback whether to resume or start from beginning and this can only be done after the item has been added (so I can't set the property). I've tried setting it as part of the ListItem used in SetResolvedUrl, but that doesn't seem to work..
There is probably an amount of square peg into a round hole. I'm trying to emulate the full library experiance in a plugin and perhaps that's not really what a plugin is for.
Posts: 26,215
Joined: Oct 2003
Reputation:
187
Regarding the resuming, as I understand it:
1. You know that the item is partially played before addDirectoryItem, so can set the startOffset.
2. You want XBMC to do it's normal thing and prompt the user at this point, but it doesn't, so you're emulating this in your plugin?
3. It doesn't work as you can't set the startoffset.
Seems like the solution is that XBMC should recognise that the item is resumeable and automatically take care of the prompting and resuming for you? This would be useful across other systems where a remote database (upnp for instance) tells us that the item is resumeable.
Cheers,
Jonathan
Posts: 300
Joined: Mar 2008
Reputation:
14
This is pretty much stop on. I can set startOffset, but not after prompting the user to either resume from that offSet or start from the beginning.
What confuses me is that, we build a listitem instance and feed this into addDirectoryItem - but then before we play the item (in a seperate function), we build another listItem instance and feed that into setResolvedUrl. I don't understand how setResolvedURL knows about the 1st listItem instance?
Posts: 26,215
Joined: Oct 2003
Reputation:
187
setResolvedUrl is required only if you wish to translate a plugin:// url item into the actual url at play time. It's primarily for the case where you can't supply the real URL to the item at the addDirectoryItem stage (eg further webpage scrapes or fetches, or the use of one-time URLs that would otherwise timeout etc.)
If you have the URL of the item at addDirectoryItem stage, then just set it then and forget about setResolvedURL.
As to how setResolvedURL knows about the 1st listitem instance: the user clicked on it, so XBMC holds that item. However, we pass only the URL to your plugin, so all the plugin knows about is the URL. In Dharma, we just alter the URL.
In master we also set various properties that are sent into setResolvedUrl.
Back to the task at hand: Assuming that if startOffset is set during addDirectoryItem XBMC automatically picked this up and prompted for the resume of the item from that position you'd be OK?
Cheers,
Jonathan
Posts: 26,215
Joined: Oct 2003
Reputation:
187
It probably should, yes.
So we need:
1. Support for startOffset directly in listitems added via addDirectoryItem.
2. Support for startOffset in the listitem given to setResolvedUrl.
Mind opening a trac ticket with this detail so we don't forget? You can cc me.
Cheers,
Jonathan
Posts: 300
Joined: Mar 2008
Reputation:
14
Woops - I'm embarrassed...
Looks like this isn't implemented at all - seems that it's picking up some data from the sql database and presenting a resume select dialog based on some old bookmarks... I'll keep any eye on this as it may turn out to be a bug.
Posts: 26,215
Joined: Oct 2003
Reputation:
187
IIRC what you needed was a way to set the startoffset (in fact, that can already be done I think via setProperty - see listitem.cpp in xbmc/interfaces/python/xbmcmodule?) in the listitem. Looks like what's not supported is the reading of that startoffset where it's needed (somewhere in GUIWindowVideoBase.cpp is my guess).