Support resuming videos

[anohren]

Describe the bug
If you send a partially watched url Kodi doesn't pick up where you left off.

Since Kodi is capable of resuming playback at the correct time we might just need to opt in to that somehow.

To Reproduce

• Send a url
• Start watching
• Stop mid-video
• Send the url again
• Video starts from beginning despite Kodi capability of resuming where you stopped

Kodi from Debian 17.6

[brevilo]

Why not just use a bookmark?

[anohren]

You might as well ask why Kodi has both resume and bookmark as two separate features instead of just getting rid of one of them; it's a Kodi feature that's prevalent in the application, expected to work the same everywhere, and therefore implicitly relied upon and desirable. Requiring the resume feature to be managed manually defeats its purpose, which is neatly underlined by your conclusion that it then turns into another, distinct feature: Bookmarks.

I'd highly doubt bookmarks are being used much in the wild — no one wants to manage resumption points when they can be managed automatically. I would certainly never remember to create one, never remember that I have created one, and therefore never remember to look for existing ones. Imagine having to navigate to the bookmarks list for every file you open just to check. Compare that to being prompted when playing the file the next time (or having it resume automatically). Night and day.

Not sure if this is still an issue, or if resume works in latest v21.

[brevilo]

Requiring the resume feature to be managed manually defeats its purpose

I'm not requiring anything, I'm asking a question because...

I'd highly doubt bookmarks are being used much in the wild — no one wants to manage resumption points when they can be managed automatically.

... not everyone is aware of the existence of bookmarks. You clearly are, though. Good.

it's a Kodi feature that's prevalent in the application, expected to work the same everywhere

Is it? I mainly know and use it for local media. Does Kodi support that for streaming media and provide an API for it that we can use in a way that's compatible with how this addon has to work? I honestly don't know. Is it even possible?

[anohren]

No, I know, you're not requiring anything, I mean that the decisions in this (and other) issues shape the plugin which could result in the plugin requiring users to manage it manually. That is how we would, in practice, require it. My arguments are against that.

Is it? I mainly know and use it for local media.

Well, it works for local media, networked media, in the YouTube plugin (which also has both native and remote "watched" tracking), and, I suspect, for most if not every item which has the same path as last time it played. I think that is reasonably indicative.

Does Kodi support that for streaming media and provide an API for it that we can use in a way that's compatible with how this addon has to work? I honestly don't know. Is it even possible?

This I don't know, so I put this issue up as a reminder to think about. Here's one guess: resume might possibly work already if the whole file/path field is exactly the same as last time it was sent to a machine (I mean, how else could it possibly work 🤔). Since we send options (ytdl parameters) in that same field — ugh — it's easy to send the same video and still conclude that resume never works.

Update: Completely slipped my mind here all the resolution done before passing the video to the player (the whole point of this issue 🤦‍♂️), so yeah, there'd have to be some Kodi support for providing an alternative "resume id" to the player. The following paragraph isn't really relevant and can be replaced with: Investigations might result in asking Kodi to support such a feature if it doesn't exist.

If we confirm that Kodi does a db query where resumePath == path then that might spawn a discussion about whether all plugin options could possibly be sent in another RPC field (seems unlikely since a plugin is supposed to simply react to navigating to a path, and should need little else by design, thereby reviving the plugin vs script discussion again 😅)

[brevilo]

Well, it works [...] in the YouTube plugin (which also has both native and remote "watched" tracking)

This is interesting. I used to use that exclusively until I had to switch to this addon, and I never experienced a resume option when just sending a video to it. How does that present itself? I would expect some dialogue, e.g the same I get for local files (resume playing at ), but I never encountered that with the YT addon.

Could it be that this only works if you use the YT addon via it's directly UI, instead of just sending a video URL to it? If so, then this is a different use case, due to the variable source issue below.

resume might possibly work already if the whole file/path field is exactly the same as last time

Right, this is how bookmarks work as well, I presume.

all the resolution done before passing the video to the player

Yep, as that typically changes the source (URL).

there'd have to be some Kodi support for providing an alternative "resume id"

Exactly.

[anohren]

Well, it works [...] in the YouTube plugin (which also has both native and remote "watched" tracking)

This is interesting. I used to use that exclusively until I had to switch to this addon, and I never experienced a resume option when just sending a video to it. How does that present itself?

I don't know about sending videos to it, and I don't know how it receives those (the usual virtual addon path/scheme I presume), but in Kodi-land local and remote UI aren't clearly separated even with the official remote.

An example: Using the official iOS remote app you can browse the YouTube addon (I'll admit that this is how I prefer to do YouTube + Kodi nowadays), but the contents is generated as if it were to be presented locally (and, I assume, using the same routines, which might not even be able to differentiate between local and remote access), and when you select a video you'll get all sorts of local prompts as if you were navigating the Kodi UI (video quality, resume). That's pretty bad, I think. As I recall it's still possible to tell Kodi to Always resume instead of prompting though, so it could possibly be set up to work decently for the "send an URL" use case even today.

Could it be that this only works if you use the YT addon via it's directly UI, instead of just sending a video URL to it? If so, then this is a different use case, due to the variable source issue below.

I'll have to get back to you on that — if I can work out how ti make sure to send an URL to YouTube instead of SendToKodi. Because of the blurry border between local and remote interaction it surely is a rats nest to work all this out without resorting to reading Kodi source. I can't remember all permutations.

[brevilo]

if I can work out how ti make sure to send an URL to YouTube instead of SendToKodi

Just use the "Cast Kodi" [1][2] browser addon. That still targets the YT addon, even with SendToKodi installed (which has its own browser addon).

[anohren]

So, when I did a local test it appeared that YouTube had stopped offering me to resume. I reasoned that it might have been doing that only earlier, when ISA was not being used, so I disabled it. Not surprisingly I could then not play a single video (which explains why I have ISA turned on in the YouTube addon nowadays). Conclusion: it's not even testable in YouTube anymore.

Since it's one of the larger addons I would have guessed that if this feature were present in Kodi they'd have opted in to it by now. The good news would then be that the YouTube addon also has a reason to ask Kodi for this feature if it doesn't already exist.

[brevilo]

How about adding a similar feature request to the YouTube addon? I expect them to have way more influence on Kodi then this project. If not, then just try and request that feature directly upstream at Kodi. Either way, it seems like it's not really for SendToKodi to resolve and I'd rather close this issue as won't fix - or, as a better fit, upstream.

[anohren]

What's the point of closing it with wontfix if it's a feature request that can be considered if there's support for it? And when that support can be requested if not yet existing? And especially before confirming that support is lacking?

What's the point of closing it as upstream if even when changes occur upstream the request isn't going to be fulfilled automatically?

I don't get it. Surely the purpose of the issue section isn't "to be empty" but as a place to remind people of what can be done next?

[brevilo]

And especially before confirming that support is lacking?

Sorry, I read your previous comment as confirming just that.

What's the point of closing it as upstream if even when changes occur upstream the request isn't going to be fulfilled automatically?

At that point it could be reopened 🤷‍♂

Surely the purpose of the issue section isn't "to be empty" but as a place to remind people of what can be done next?

Yes and no. IMHO, issues that can't be implemented until upstream provides the means are purely hypothetical until that happens. I for one would retain issues only as long as this project could in principle implement a solution. That said, this isn't my project, so only one opinion.

Again, my current understanding from your findings and my experience so far is that it's not possible right now. If that's wrong, please let us know how.

JM2C

[anohren]

when I did a local test it appeared that YouTube had stopped offering me to resume

I was mistaken about it not working in the Youtube addon — apparently no resume point was created when I tested (maybe I didn't fulfill the requirements and should have skipped ahead more?), but then I found an older video (2 h long) with an existing resume point where resume worked, in the local UI. When I sent the equivalent youtube url (sendtokodi iOS app, sendtokodi plugin disabled) it played the video from the beginning. I couldn't glean much from this though.

At that point it could be reopened 🤷‍♂

Ok, I see. It's not a big deal in this particular case, but I'll leave my opinion here for consideration, in case the situation crops up in the future. I think that the following would in general be a natural flow for new features:

1. End user discovers missing feature they'd like to see and reports it to the user-facing project they use
2. Project determines if request is reasonable, feasible, desired, etc...
3. If yes, project determines list of tasks to achieve it, including asking dependencies for required features
4. An issue is left open to track completion of these tasks
5. If a dependency declines the request, at that point the issue can be deemed infeasible and closed

I guess we have different opinions on number 3, where I'm of the opinion that a project (and by extension its issues) should also encompass and own tasks other than, basically, "write code immediately", including asking a dependency for a missing feature. I find it reasonable that an end user should not have to seek out and make the necessary requests to a project's dependencies on the project's behalf (if they even somehow knew which missing features were needed), and so the project itself should, as a principle, own and track those tasks.

From my perspective having an open issue accomplishes something: It lists a task that can be picked up by anyone with enough motivation, while both signaling that the task is not wasted effort as well as making the task easier to find.

[brevilo]

(sorry for the long absence)

I guess we have different opinions on number 3

Yep, you're right. I agree with you in principle but in this regard I do distinguish between commercial products and open source project run by volunteers. But sure, if we talk about actual end users with absolutely no technical expertise then we can't expect such a person to open a feature request. For some reason I don't regard you as such a person, though 😏 . I might of course be mistaken.

But this discussion now seems to be purely academic anyway, given that you could establish that Kodi appears to support resuming (as done by the youtube addon). That means it's up to our project to investigate.

Cheers

[brevilo]

A few notes:

• Sent videos end up in the files table as well as the bookmark table, as configured.
• Sending the same video reuses the files and bookmark records saved earlier, so the video is being recognized.
• Despite the above Kodi doesn't present the resume dialog. No idea yet why not. All info is there...