Latest Quasar - Playback issues with library integration

[KillerJoeBR]

Looks like the latest version (with improved Library integration watch status and resume status) caused some playback behavior/problems.

When i start an episode, whenever i pause the playback, it goes back to the begining of the video. For example, if i start a subtitle search which pauses the playback, after i get the subtitle the episodes starts again from the begining. If i pause to go to the bathroom or see the download status, same thing happens.

Also, if i quit the playback midway. If i try to watch it again it won't start the video again (it's unresponsive). I need to exit the series view, go back to Kodi Home menu, get back to the series/episode and then hit enter again. And then it gives me the option to Restart the episode or Resume from where i was. If i select "Restart", it doesn't matter. It resumes from where i left it anyway. And the pause bug happens too, but now it goes back to the resume point everytime.

https://www.dropbox.com/s/ked5tsetzt1lz3h/kodi.log?dl=0

EDIT: I tried with SPMC/Kodi 16 and i think these playback issues don't happen there. But then, it seems like the resume function also doesn't work and the watch status neither. So it's proably related to these functions which are working on Kodi 17.

[heartlogic]

Hello...

I have LibreELEC 7.95beta6 (Kodi Krypton 17.1 RC) in a S905X TV box and i have the exact behaviour as described above...

[jellespijker]

Same behaviour on Arch Linux 4.9.8-1 running kodi 17.0rc2-1 with Quasar 0.9.72

File plays/pauses normals when it is completly downloaded and played without quasar as a regular file.

[drake0101]

Lubuntu 16.10 and Kodi 17 with quasar 0.9.72. Exactly the same issue.

[scakemyer]

Nice one... only when playing from library integration, but that's what I get for focusing solely on "does it save the damn resume point now"...

[scakemyer]

Alright, got most of it fixed, except for when choosing not to resume playback; it looks like Kodi isn't giving us any way to know what the user chose. The Playlist.OnAdd notification only passes the playlist id (typically always 1 but that doesn't matter) and the item position (always 0, also not of any use to us), and that's about it. I'll look into other Player.onPlayBack* events on the Python side of things to see if any of them do send something useful, but so far it doesn't look possible so we'd have to choose one or the other, and maybe add another setting in Quasar for that preference.

[KillerJoeBR]

Good news scakemyer, altough there is a catch. But not a major one. For me at least, i would prefer the "not resume" option, but that could be an option inside Quasar for the user to choose.

BTW, if i don't save the Video/Torrent, and then later i choose to resume playback from where i left, does quasar can start the download of the torrent from that waypoint? Cause i thought the download would always start the download parts from the begining of the movie and goes from there. (which would probably cause playback issues)

[scakemyer]

Yes, it can, I'm sure it could be improved and sometimes fails, but it already re-prioritizes pieces if you seek to a part that's not already downloaded, so you'd get a bit of buffering but on a fast connection it actually works pretty well right now.

[scakemyer]

Regarding the resuming, I'm leaning towards keeping it as the default, since I'm pretty sure most users would prefer to actually resume a movie where playback was stopped halfway, especially when Kodi now shows it as such. It's a lot easier to just rewind to the beginning than trying to get to 52:04 after having to remember what Kodi was saying it would resume at...

[scakemyer]

Another idea would be to resume only if we find a match in current active torrents, and/or when the now-renamed-as-keep-downloading-background-handling is enabled... but I think the former would make the most sense, as we'd be preventing buffering issues even if it usually works.

[scakemyer]

Aaand I can confirm the other Python events are useless in this case, which means we need to choose a compromise here... So either something like a "Resume playback from library integration" setting, resuming from active torrents only, or a combination of both, which could get confusing unless the setting allows to choose between "Always / Never / Active torrents"

[KillerJoeBR]

Well, if the resume playback from the middle when restarting a download works okay like you said, then i guess keeping resume as default is a good choice.

[KillerJoeBR]

But i would like the option to disable it (specially if my third world slow connection doesn't play it nice)

[scakemyer]

Yeah, I don't like having to force that default on users, if you don't want to resume your damn movies then you should be allowed to choose so, even if Kodi's before-I-click-play choice isn't working in this case.

[scakemyer]

So, I'll add that setting (and, you know, implement it... hopefully not a big pita), and will default it to "Active torrents only" which I think is what makes the most sense.

[KillerJoeBR]

Sounds good! BTW, i don't know if these changes will also make it work for kodi 16, if not, then later you could look at it, cause right now these new library integrations aren't working for kodi 16

EDIT: Give me a hint (or a punch in the face) if you need a log and a new thread for that)

[scakemyer]

I'll look into it afterwards, but I don't think they will, iirc the RPC methods we need to use are broken / not working as expected in Kodi 16.

[elgatito]

Are there any issues with "resume" on Windows?

• I have a movie added to the library.

• Click from the movies menu,

• It asks to use previous stream, I agree

• Starts to check the file, when it's done - start playing

• I rewind somewhere, wait for a minute or so, and exit.

• Kodi shows movie in watching state, and progress correctly

• Log shows messages like "Watched ..., duration ..."

• When I start same movie from movies list it asks to resume, I click yes, it asks to re-use the stream, it checks the file and open from the start...

No visible errors in the log while playing the video (will attach it tomorrow).