Fix: Sync progress to library when no runtime info

[ruinernin]

TVDB does not provide runtime metadata for episodes. If this can not then be
filled by Kodi introspecting the file for the item (e.g. library item that is
a .STRM file) the info label will be 0. Meaning the resume position set by
Trackt will be 0 as the calculation is runtime * progress_pct.

Episode runtime metadata exists in the metadata provided by Trakt for episodes
so this can be queried in these cases to calculate a resume time that is
reasonably accurate.

This depends on fuzeman/trakt.py#69 being merged and propagated to
Razzeee/script.module.trakt

[coveralls]

Coverage decreased (-0.006%) to 8.947% when pulling c3529f0 on ruinernin:runtime into bb2dae9 on trakt:master.

[coveralls]

Coverage decreased (-0.006%) to 8.947% when pulling c3529f0 on ruinernin:runtime into bb2dae9 on trakt:master.

[razzeee]

First of all, thank you :)

Does this affect movies too, as you only updated the episode code?
And how is performance? Did you check how long it takes?

[ruinernin]

Does this affect movies too, as you only updated the episode code?

It may potentially though I have not seen it in practice as TMDB provides
runtime metadata.

And how is performance? Did you check how long it takes?

I didn't notice any perceptible major slowdown but my Trakt account doesn't have
a major amount of partially played episodes. I'll try get some hard numbers to
add to this PR.

[razzeee]

Now that you repeat it, tvdb has runtime data, but only on the show level. So is your scraper having problems or did you find an episode where the show was just recently created?

[ruinernin]

I'm using the metadata scraper The TVDB 3.0.16, looking at the XML you're
right it does seem like it should be scraping the runtime, I'll look into why
that's not working. It does seem like it would be less accurate, especially in
cases where episode lengths vary (extended runtime finales for instance).

I'd still say there is some logic to be fixed here even if it's to simply skip
over items without a runtime, avoiding overwriting existing resume times with 0.

Not sure what connection this GitHub project has to Trakt itself, but being
completely ignorant of the storage implementation it would appear it may make
sense to return something like a progress_seconds or progress_minutes
attribute on calls to sync/playback. Avoiding imputation or additional API
calls to contextualize the percentage value, given the Trakt source has the
necessary data.

[ruinernin]

After investigating the plugin metadata.tvdb.com it does in fact add runtime
info, but at the show level as it is in the API. This is not further added to
any items below this level (shows/episodes) by the scraper or Kodi.

I paused a few episodes that produce this issue in an attempt to increase the
sample size to get some data on the increased runtime of the call in the PR.
Obviously without access to users datasets I have no idea if this is a
representative sample size of partially played episodes a user may have that
would take this branch.

The code used to produce the following log is

additional_calls = []
episodes = []
for show in kodiShowsUpdate['shows']:
    for season in show['seasons']:
        for episode in season['episodes']:
            if not episode['runtime']:
                starttime = time.time()
                episode['runtime'] = Trakt['shows'].episode(show['ids']['trakt'], season['number'], episode['number'], extended='full').runtime
                additional_calls.append(time.time() - starttime)
            episodes.append({'episodeid': episode['ids']['episodeid'], 'progress': episode['progress'], 'runtime': episode['runtime']})
xbmc.log('Extra API Calls N: ' + str(len(additional_calls)), xbmc.LOGERROR)
xbmc.log('Extra API Calls SUM: ' + str(sum(additional_calls)), xbmc.LOGERROR)
xbmc.log('Extra API Calls AVG: ' + str(sum(additional_calls)/float(len(additional_calls))), xbmc.LOGERROR)
def pct(p, nums):
    x = (p / 100.0) * (len(nums) + 1)
    if x >= len(nums):
        return nums[-1]
    a, b = nums[int(x-1):int(x+1)]
    return a + x % 1 * (b - a)
additional_calls.sort()
xbmc.log('Extra API Calls P50: ' + str(pct(50, additional_calls)), xbmc.LOGERROR)
xbmc.log('Extra API Calls P90: ' + str(pct(90, additional_calls)), xbmc.LOGERROR)
xbmc.log('Extra API Calls P95: ' + str(pct(95, additional_calls)), xbmc.LOGERROR)

ERROR: Extra API Calls N: 14
ERROR: Extra API Calls SUM: 0.360143899918
ERROR: Extra API Calls AVG: 0.0257245642798
ERROR: Extra API Calls P50: 0.0260390043259
ERROR: Extra API Calls P90: 0.0321450233459
ERROR: Extra API Calls P95: 0.0328290462494

Then taking into account

$ ping -qc 10 api.trakt.tv
PING api.trakt.tv (104.20.82.229): 56 data bytes

--- api.trakt.tv ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.905/10.696/19.557/3.452 ms

[razzeee]

Did you check if you actually have cases where episode['runtime'] is set?
As you said, that the scraper is not setting it on the episode level, so only way would be if kodi send the detected one. But I'm not even sure if it pushes the detected time to the database at some point.

[ruinernin]

I can confirm the tag is set in the cases where it is parsable from the source, and is preferred https://github.com/xbmc/xbmc/blob/35a72fdf51cde38de22505799533f50abc460a74/xbmc/video/VideoInfoTag.cpp#L1232-L1243

[razzeee]

Thank you, I'll merge for now even if we're waiting for upstream to align.