[hippojay]

HI,

I've noticed that something has changed in EDEN (over Dharma), which is causing some UI issues with my plugin.

XBMC is now storing a bookmark if I stop a plugin halfway through, and then prompts me if I want to resume or play from beginning. However I don;t want this functionality for my plugin, as the resume information could be wrong (such as if the file was played elsewhere):

Code:

13:30:56 T:5608   DEBUG: CSaveFileStateJob::DoWork - Saving file state for video item plugin://plugin.video.plexbmc/?url=http://192.168.1.200:32400/library/metadata/49257&mode=5&id=49257

Is there a way of modifying this behaviour so that I can turn off this bookmark, or at least allow me a way to modify the bookmark so that it resumes from the correct position. (it wold actually be very nice if I could tell XBMC to use a resume time, rather than having to seek to it manually).


EDIT: btw, I have tried working around it by adding an ignorable argument to the url (a random number), which works initally - but as the plugin is not refreshed, then the same number is used if you restart without navigating away from the current list.

[hippojay]

Hmm, still haven;t found a foolproof workaround to stop XBMC remembering what I've watched in a plugin and setting a bookmark for it - or allowing me to use this data better.

Not sure when this got added, but it was probably around October last year. Anyway to find out? then I might be able to see if I can alter how my plugin works, or make suggestions for code changes so that this is controlable.

[spiff]

there's no way to stop it from doing this as of now. why are you served differing videos on the same plugin:// url? anyways, the only way to avoid this is to have the plugin:// url change. we associate with the plugin:// url, not the resolved url. this is what changed, we used to associate with the resolved url, which was pretty much always transient.

i love the resume points on e.g. utub and it's not going away

[hippojay]

there's no way to stop it from doing this as of now. why are you served differing videos on the same plugin:// url? anyways, the only way to avoid this is to have the plugin:// url change. we associate with the plugin:// url, not the resolved url. this is what changed, we used to associate with the resolved url, which was pretty much always transient.

I'm not serving different videos on the same plugin:// url - the problem is that this bookmark value may not be correct and I have no way of controlling it. If I watch the media on one device, stop and resume on a different device, then the bookmark is incorrect.

I either need to find a way to stop it, or at least a way of controlling it so that it is right.

I know that you set a python listitem 'resume' as the resume point, but unfortunately this removes any option of restarting the media from the beginning.

Also, the bookmark database data is pulled out when a playable listitem is selected, but before any further plugin code is run before the setresolvedurl/player.play - so this removes any chance of updating bookmarks with the correct time.

It would be great if I could set a resume time prior to player.play/setresolvedurl (or even as an argument to it).

i love the resume points on e.g. utub and it's not going away

I too loooove resume points, but only when they resume from the right place

[Nuka1195]

The playmedia() built in supports a 'noresume' argument. You could call back to your plugin then use the built in.

But it would be nicer if pythons play() function was extended to support this.

[spiff]

see https://github.com/xbmc/xbmc/pull/1113

when/if that gets pulled it's just calling listitem.setProperty('startoffset','timeinsecs') on the *original* item.

stay out of my hair nuka, if you comment i won't persue the pr.

[hippojay]

see https://github.com/xbmc/xbmc/pull/1113

when/if that gets pulled it's just calling listitem.setProperty('startoffset','timeinsecs') on the *original* item.

Thanks - So if a startoffset was set (i.e. > 0), then would it display the "resume or start from beginning" dialog, or simple start up from the resume point?

Also, I guess this can only be set with the list item and not after (say in doing some processing after the user has selected a playable item from the GUI?).

If I get the chance I'll also build up a version with it in and see what happens.

[jmarshall]

@hippojay: Am I correct in the comment I made on the github PR:

https://github.com/xbmc/xbmc/pull/1113#i...nt-6748955

i.e. you basically just want to say "the item is resumable from 10:47 - up to the user whether they pay attention to this or not".

Cheers,
Jonathan

[hippojay]

i'll try and explain it a bit better.

My plugin (plexbmc) uses some data from a separate location to drive some decisions and settings before playing media. This includes setting up things like what media to play (SD, hd, dvd), where from, what subtitles to load, where to start it from etc.

In Dharma (and Eden until just before Beta releases):

Code:

1. Plugin runs and locates video entries.  These entries point to an XML file containing the above info.  This is added to the GUI as a Link set to "isPlayable=true".
2. When the user selects the link, the plugin runs and does the pre-processing on the XML file and sets up the environment as required.
3. If there is multiple media type (sd, hd, etc) then the users is allowed to select via a dialog box
4. If there is a resume time >0 then user gets to select that, or to start from beginning
5. If we are starting from beginning, then pass to player.play() and finish
6. If we are resuming, then pass to player.play(), pause, seek to time and unpause.

In released EDEN:

Code:

1. Plugin runs and locates video entries.  These entries point to an XML file containing the above info.  This is added to the GUI as a Link set to "isPlayable=true".
2a. When the user selects the link, XBMC auto checks the bookmark and if matching, returns a resume dialog box.
2b. the plugin runs and does the pre-processing on the XML file and sets up the environment as required.
3. If there is multiple media type (sd, hd, etc) then the users is allowed to select via a dialog box
4. If there is a resume time >0 then user gets to select that, or to start from beginning
5. If we are starting from beginning, then pass to player.play() and finish
6. If we are resuming, then pass to player.play(), pause, seek to time and unpause.

So, in EDEN there is an extra dialog box (2a) that pops up and alters the item startOffset.

In an ideal world, it would be great to be able to set the startOffset after the user has clicked on the item. Either as a property fed into player/setresolvedurl or as an argument to those commands. We would then have more control over the playback of media from a source other than xbmc bookmark (would probably be then possible to implement some custom chapters list or jump in points for recorded TV shows, etc). This would stop me having to pause/seek/unpause (which isn't as messy as it sounds )

Or, is a practical world, the ability to stop the check/use of a bookmark value.

Recording plugin resumes is great and it definitely has it's uses, but on the flipside there should be some control to allow it to be turned off.

I have previously tried to find how to do this in the xbmc code, but tracking the m_lStartOffset through the files (and the python interface) takes me days and days.

[spiff]

my patch/pr points out where the startoffset is modified. that's where the shoe presses. it's trivial to allow specifying it on the resolved item as well should we want that. i still think what i did is what you need

[hippojay]

i still think what i did is what you need

I've just tried this and, yes, for my plugin this has removed the bookmark generated resume dialog. However, I think that this change is also going to alter the bookmark resume for all plugins.

If I set startOffset property, then the dialog isn't displayed, and the media starts from the offset
My plugin doesn't set the startOffset property - yet it still doesn't display the bookmark resume

This means that all plugins will now bypass the bookmark resume dialog and restart from startOffset (which is probably going to be from tge beginning). I've checked with youtube and I cannot get the plugin to resume an item.

I'm not a selfish guy, so I don't want to globally remove a feature that people (like yourself) are using/expecting.

[spiff]

right then it's missing an initializer somewhere, probably in the python listitem class.

[hippojay]

right then it's missing an initializer somewhere, probably in the python listitem class.

yeah, you were right, initialising m_lStartOffset to STARTOFFSET_RESUME in listItem.cpp fixed it. Having some github issues at the moment, so i'll generate a commit when I sort them out.

EDIT: https://github.com/hippojay/xbmc/commit/...2c8d592223

This reverts behaviour back to pre-Eden if startoffset is set. If it's not specifically set, then it acts as it does now.

Now I've just got to find out how to modify it and use it directly in player.play and setresolvedurl.

[hippojay]

Been spending some time looking into getting setResolvedUrl to accept a 'startoffset' - mainly through the existing listItem property startOffset, as the mechanism and interface is already there.

Looks like the problem is that startoffset isn;t store as a listItemn property but directly within the FileItem - this means that the existing functions to update the listItem with the data passed in by setResolvedURL weren't updating startoffset, so it was ignored. This patch changes that:

From the listitem passed into AddDirectoryItem:
* if startoffset isn;t explicitly set, it is let at -1. This will allow bookmarks to be checked as a resume dialog to be shown
* if startoffset is set to any other number, then the media will start from this point. (there a 0 will remove dialog and always start from the beginning)

These items are set when the user clicks on the link. If you want to change the value after this point, i.e. feed directly into setResolvedUrl. Then you simply set the property again into the listItem passed into setResolvedURL.
* if startoffset isn't set, it will remain as the initalised -1 value. This will be ignored by setResolvedURL and teh previous value not updated
* If startoffset is set to any other value, then this is regarded as being explictly set by the user and will override the previous startoffset value. Media will resume from this new value instead.

https://github.com/hippojay/xbmc/commit/...2bea86534b