Kolibri: Video can't be forwarded in h5p_viewer in Google Chrome

[jredrejo]

Observed behavior

When using Chrome to watch a video that's inside a h5p container, when clicking on the video timeline to move to a different point the video always goes back to the beginning. THere's no way to jump to a new position

Using Firefox (both normal and developer version) this feature works correctly.

Expected behavior

The video timeline should allow the user to move to different parts of the video

User-facing consequences

No way to go back or forward when watching a video

Errors and logs

In the browser console:

:8080/zipcontent/612a7a2941596b60ef89709e150f8cc3.h5p/content/videos/files-5fb7f16f211b2.mp4#tmp:1 Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH

As a side note, this error is also shown in the browser console:

pluginMediator.js:122 Kolibri Modules: kolibri.plugins.media_player.main registered
vue.runtime.esm.js:1888 TypeError: Cannot read property 'icon' of undefined
    at Sub.svgIconComponent (index.vue:62)
    at Watcher.get (vue.runtime.esm.js:4479)
    at Watcher.evaluate (vue.runtime.esm.js:4584)
    at Sub.svgIconComponent (vue.runtime.esm.js:4836)
    at Sub.<anonymous> (index.vue?648c:1)
    at Sub.Vue._render (vue.runtime.esm.js:3548)
    at Sub.updateComponent (vue.runtime.esm.js:4066)
    at Watcher.get (vue.runtime.esm.js:4479)
    at new Watcher (vue.runtime.esm.js:4468)
    at el (vue.runtime.esm.js:4073)
logError @ vue.runtime.esm.js:1888

This second error is not important: if the resource has not an icon it appears in the console. Theorically it should not be related to the forward/backward problem, but just in case.

Steps to reproduce

Load content from a channel with a h5p video and test it

Context

Kolibri 0.14.6
h5p plugin enabled with kolibri plugin enable kolibri.plugins.h5p_viewer
Browsers: Google chrome Versión 88.0.4324.96 (Build oficial) (64 bits)
Firefox 84.0.2
Firefox developer 83.0b7
OS: Ubuntu 20.04

[rtibbles]

We would need to add byte range support to the zipcontent endpoint in order to support this. This might be better addressed by productionizing the clientside H5P rendering prototype I have created, as I believe (though I can't find conclusive documentation) that the blob URLs it uses in the client side should support these byte range requests.

[kollivier]

Note that this happens for any HTML5 content, not just H5P. (Videos in SCORM modules had the same problem.)

[jredrejo]

@rtibbles why is it working in Firefox? is it just because it is a better browser ;) ?

[rtibbles]

The fact that it is working in Firefox is the part that is confusing to me! (I have no idea)

[rtibbles]

@kollivier's point about this happening in other zip content types suggest we may want to try to support this for the zipcontent endpoint regardless - I think we can do this, but we'd have to reimplement CherryPy's byte range requests in that endpoint.

[kollivier]

It makes sense that seeking should be possible once the full video has been downloaded, as at this point all data is cached locally and we shouldn't need to call back to the server to fetch the part of the video we're seeking to. I think this is actually a Chrome bug, though not sure the cause of it.

[rtibbles]

Following up here - the simple implementation of this (simply adding Range support to the zipcontent endpoint) is difficult for Python versions less than 3.7, as the seek method on files from within zipfiles is only supported from 3.7 onwards.

If we did want to robustly support this, we would have to unzip zip files.