[kit500]

Working with local video addon code, had encountered this:

If used "stack://http://my_url_1 , http://my_url_2 , http://my_url_3" link, "partially watched" sign is created, but playback (if choose "resume from ...") anyway starts from beginning.
If used "http://my_url_1" resume is works correctly.

Had someone encountered this?

[jmarshall]

Are you setting the resume point, or is XBMC handling it all?

[kit500]

In given case I'm not set it. XBMC is supposed to handle, but it's not

[jmarshall]

And can it compute the length of the stack? i.e. do you actually get the correct duration of the stack when you play the item?

Is the item being added from a plugin:// URL that is resolved on playback, or is the stack:// URL set when you return the plugin directory?

[kit500]

Is the item being added from a plugin:// URL that is resolved on playback, or is the stack:// URL set when you return the plugin directory?

Yes, it is resolved by plugin from path like plugin://id?[params]

And can it compute the length of the stack? i.e. do you actually get the correct duration of the stack when you play the item?

Yes, while playback the whole time (as sum of the parts) is displayed properly, i think it computes.

[jmarshall]

You need to take a look in your database and see if the stack times are stored for the stack:// item and whether a resume point is set for the stack:// item or for the plugin:// item - I suspect just the latter.

Thus, what happens is that the code for determining the stack start time doesn't work, as there's no resume point set for the stack item - it's stored for the plugin:// item instead.

What needs to happen is that the resolving of resume time needs to happen on the plugin:// URL and this needs to be used in the PlayStack() function, or alternatively the stuff that determines which stack to start needs to be moved out of the PlayStack() function - my guess is the former may be easier - you can compare to the resume stuff in PlayFile().

See Application.cpp. I doubt there'll be much effort from other devs to correct this in the meantime, but if you want to give it a crack, I'm happy to help direct etc.

Cheers,
Jonathan

[kit500]

Thank you very much. I think I need to try to figure it out.

there's no resume point set for the stack item - it's stored for the plugin:// item instead.

This is exactly what I have explored for now. I will continue the exploration.

[kit500]

For my understanding the chain for given case is: PlayFile() -> item.IsPlugin() -> PlayFile() -> item.IsStack() -> PlayStack() -> PlayFile()

Question is in what part of chain the resume property for item is losed.

Possibly in PlayStack() in:

Code:

if( item.m_lStartOffset == STARTOFFSET_RESUME )
        {
          // can only resume seek here, not dvdstate
          CBookmark bookmark;
          if( dbs.GetResumeBookMark(item.GetPath(), bookmark) )
            seconds = bookmark.timeInSeconds;
          else
            seconds = 0.0f;
        }

//timeInSeconds = resume time
Problem is that the item here most probably is already a stack item not a plugin.

In item.IsPlugin() in PlayFile():

Code:

if (XFILE::CPluginDirectory::GetPluginResult(item.GetPath(), item_new))
      return PlayFile(item_new, false);

I suppose item_new here is a plugin item.

In item.IsStack() in PlayFile():

Code:

if (item.IsStack())
     return PlayStack(item, bRestart);

(the same item).

Also may be in

Code:

CFileItem item(*(*m_currentStack)[i]);

in "for" loop for stack in PlayStack().


upd: Do anybody knows, is it works for local (non plugin) files? (i had tested only for plugins)

[jmarshall]

The problem is dbs.GetResumeBookMark(item.GetPath(), bookmark).

item.GetPath() is the stack URL. That's not where the bookmark was saved - check your database and you'll see it's saved for plugin://.

If you check the resume code in PlayFile() you'll see you need to use original_listitem_url to retrieve the bookmark.

[kit500]

So in PlayStack():

Code:

if( item.m_lStartOffset == STARTOFFSET_RESUME )
        {
          // can only resume seek here, not dvdstate
          CBookmark bookmark;
+         CStdString path = item.GetPath();
+         if (item.HasProperty("original_listitem_url") && URIUtils::IsPlugin(item.GetProperty("original_listitem_url").asString()))
+           path = item.GetProperty("original_listitem_url").asString();
-         if (dbs.GetResumeBookMark(item.GetPath(), bookmark))
+         if( dbs.GetResumeBookMark(path, bookmark) )
            seconds = bookmark.timeInSeconds;
          else
            seconds = 0.0f;
        }

(Can't test this because not have a compiler/IDE for now)

upd: Did compile and test. Patch completely fixes the issue. Also checked that local files (.-partN) works.

[jmarshall]

Yeah, exactly - will take a look at the PR.

Thanks!

[kit500]

thanks