EmbyCon - strm resume issues

[rayw 4]

Hey, I've just started using EmbyCon but I've run into a slight issue. I have a lot of my media library on Google Drive, so I use the Google Drive add-on for Kodi for the playback of any of that media. So, I create the .strm files and scan them into my Emby library alongside my local media. For reference I am using the EmbyCon add-on from the BETA repository.

The issue I am having is that there seems to be a discrepancy between the way movies and episodes are handled during playback - or more specially, during the stopping of playback.

When playing a movie or episode, they both appear in my Emby dashboard with the correct time counters, and so forth. Skipping along the video in Kodi/EmbyCon will also alter the timer on my web app dashboard, for instance. When I stop playing a movie before it ends, a resume point is made inside Kodi and I am asked if I want to resume the video when re-entering. This is not the case with episodes. If I end playback on an episode early, not only is a resume point not created, but the entire episode is marked as watched - which is not a very desirable outcome. This is only happening when using .strm files, playback of my local content ending early results in a resume point and the episode not being marked as watched, which would be the expected behaviour.

I would be happy to get you a debug log but wasn't entirely sure which you would need, a Kodi one or an Emby one, or possibly both? If you let me know which you need I will grab them for you at some point this weekend.

Thanks.

[TeamB 2352]

So strm movies work correctly but strm episodes dont, is that correct?

Are you creating links to the kodi plugin in the strm files or links to the media on google drive, can i see an example of an strm file content.

Strm files have some special handling in emby, especially strm files that contain kodi plugin links. The main special handling is all about the duration of the target media file, emby has no way of knowing the media duration so it waits for kodi to report it on first playback and then sets the duration.

One problem that can arise is emby never sets the duration correctly and thus when playing back and reporting current position and stop positions they mean nothing because emby does not know how long the media is thus it must marks it as watched.

Check in the emby web interface to see if your strm files have a duration, never played strm files should not, on first playback they should then have a duration.

If this is not happening then that is the issue.

[rayw 4]

12 hours ago, TeamB said:

So strm movies work correctly but strm episodes dont, is that correct?

Are you creating links to the kodi plugin in the strm files or links to the media on google drive, can i see an example of an strm file content.

Strm files have some special handling in emby, especially strm files that contain kodi plugin links. The main special handling is all about the duration of the target media file, emby has no way of knowing the media duration so it waits for kodi to report it on first playback and then sets the duration.

One problem that can arise is emby never sets the duration correctly and thus when playing back and reporting current position and stop positions they mean nothing because emby does not know how long the media is thus it must marks it as watched.

Check in the emby web interface to see if your strm files have a duration, never played strm files should not, on first playback they should then have a duration.

If this is not happening then that is the issue.

Correct, .strm files for movies are working correctly but not episodes.

I don't have access to the .strm files or the Kodi device right this second, but I just logged in to the Android app to check if durations have been set as you mentioned at the end, and it appears that episodes are not having their duration set but movies are.

I will grab a .strm example as soon as I can, I'll also grab a full Kodi debug log for you.

[rayw 4]

I can't seem to see an 'Edit' button for my post above, but here is the contents of a .strm file (I have removed the actual identification stuff):

plugin://plugin.googledrive/?action=play&content_type=video&item_driveid={item_driveid}&item_id={item_id}&driveid={driveid}

I will grab the debug log a little later.

[TeamB 2352]

@rayw That should be enough for me to investigate for now, i will see what i can find.

What version of Emby, Kodi and EmbyCon are you using?

Edited October 9, 2021 by TeamB

[rayw 4]

@TeamB thanks. I am using the following:

Emby 4.6.4.0
Kodi 19.2
EmbyCon 1.10.14 (via BETA repository)

If there is any other information you need from me please let me know. Have a good weekend.

[TeamB 2352]

I think I found the issue, it was a timing issue with when the progress was reported.

As I explained above, the playback progress report has a duration in it and if Emby does not have a runtime/duration for an item it will update its duration for that item based on what Kodi reports in the playback progress report. The problem was when Kodi first starts playing is can report 0 (zero) duration for a streamed item for the first 10 to 20 seconds. This means for the first few progress reports the duration is reported as zero i.e. not null but zero thus Emby sets the duration as zero and from that point on the duration is zero for that item in Emby. This is what is causing the episodes to never have a duration.

To fix it I dont send a playback progress report when Kodi has no playback duration thus the item playing is fully loaded and Kodi is playing correctly. This will stop zero duration being reported to Emby for items.

This is in the latest Kodi 19 Beta 1.10.16

[pünktchen 1258]

14 minutes ago, TeamB said:

To fix it I dont send a playback progress report when Kodi has no playback duration

I must admit i haven't tested it yet, but from theory it will break live tv, because live tv never has a duration.

[TeamB 2352]

Does live tv need a progress report?

[Luke 37060]

18 minutes ago, TeamB said:

Does live tv need a progress report?

Yes so that the stream doesn't end up getting killed by the server.

[TeamB 2352]

Hmm ok, i will have a think

[TeamB 2352]

@Luke I can achieve what  need if I dont set

PositionTicks or RunTimeTicks

in the playback progress call, Is there any issue not setting the PositionTicks  for Live TV?

 

[rayw 4]

Should I test the new beta version or wait until the live TV isn't affected also?

[TeamB 2352]

test now if you can, if we can confirm not sending the zero duation fixes the issue that is a good step forward

[rayw 4]

9 minutes ago, TeamB said:

test now if you can, if we can confirm not sending the zero duation fixes the issue that is a good step forward

Tested. It worked as intended, playback sent to webapp dashboard, and on stop a resume point is made.

[pünktchen 1258]

11 hours ago, TeamB said:

Hmm ok, i will have a think

You could change the condition from 

if duration is not None and duration > 0:

to 

if live_stream_id is not none or (duration is not None and duration > 0):

 

[TeamB 2352]

Yeah that was my fallback next step if @Like said not sending the positiontick was a bad idea

[TeamB 2352]

I have made the changes to not send position and runtime if there is no Kodi duration to the latest betas.

[pünktchen 1258]

23 hours ago, TeamB said:

I have made the changes to not send position and runtime if there is no Kodi duration to the latest betas.

Although it works in general for live tv also, i would have prefered what i've suggested. Now it looks a little bit strange in Emby's dashboard for live tv.
Emby seems to autocount the PositionTicks for live tv and everytime the Kodi addon sends the playback progress without any PositionTicks at all, the counter gets reset in the dashboard: video.

Edited October 11, 2021 by pünktchen

[TeamB 2352]

@Luke what is your take on this? What is the best solution from a server point of view?

[Luke 37060]

Quote

emby has no way of knowing the media duration so it waits for kodi to report it on first playback and then sets the duration.

Actually this should only be the case for strms containing kodi plugin urls, as Emby Server doesn't understand those. For urls pointing to actual media urls, if using the /playbackinfo api then nowadays it will get probed prior to playback and the server will have a duration. (That's not anything new).

Am I correct in assuming that all issues here are pertaining to strm files containing kodi plugin urls?

[TeamB 2352]

47 minutes ago, Luke said:

Actually this should only be the case for strms containing kodi plugin urls, as Emby Server doesn't understand those. For urls pointing to actual media urls, if using the /playbackinfo api then nowadays it will get probed prior to playback and the server will have a duration. (That's not anything new).

Am I correct in assuming that all issues here are pertaining to strm files containing kodi plugin urls?

Yes correct but before you say limit to that edge case it is not easy to keep track of this internally with kodi.

[Luke 37060]

So what should we do, or what is the current state of affairs?

[TeamB 2352]

On 10/29/2021 at 3:25 AM, Luke said:

So what should we do, or what is the current state of affairs?

Not sure, one way is handle it on the server, if runtime is reported is zero dont use it to set the item runtime just ignore it.

[speechles 1917]

-> StreamInfo.MediaSource.LiveStreamId

That field is missing if it is not Live TV.

On 10/10/2021 at 7:16 AM, pünktchen said:

You could change the condition from 

if duration is not None and duration > 0:

to 

if live_stream_id is not none or (duration is not None and duration > 0):

 

Yep. That is "exactly" how the Roku does this except with brightscript instead of python. Same exact evaluation. That is what should be used.