You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The application has a hero video section on the home page that is prominently displayed and can be played. Below it there are category sections and the same video in the hero section is repeated below in its own category.
However, it looks like the hero video and the corresponding category video are not connected because user can download the one in the category section for offline viewing, make the service worker go offline, but still the hero video does not play.
This can be confusing to the user, since we claim that all videos are downloadable for offline viewing. Clearly the hero video is NOT in this category.
Expected Behaviour
If we claim that all videos we host are available for offline viewing, then the Hero section video should also be downloadable and should be able to be played after going offline - right from the home page !
Thank you, Kamalesh, this is interesting and not expected.
This can be confusing to the user, since we claim that all videos are downloadable for offline viewing. Clearly the hero video is NOT in this category.
@kkalarickal It is the same video as you downloaded below. Service worker should be able to take over and serve data from IDB. If you refreshed the homepage in offline mode and played the hero video, it would play just fine. (Or at least that is the expectation.)
However, it seems that entering the offline mode mid-playback confuses the browser somehow. I'll need to investigate the issue more closely to figure out what really happens and how to make sure the transition from online to offline serving is seamless even for the currently playing video.
Update: Investigated further and the reason for the playback break is this:
The hero video is a DASH video, the issue is not going to happen with non-streaming sources.
When the video starts playing, the online manifest is loaded.
The Streamer module selects an appropriate video representation based on the available bandwidth.
This representation is likely to be the highest bandwidth available in our testing.
When the video is downloaded, all representations other than HD (720p) are stripped from the manifest.
This modified offline manifest is stored in IDB.
When the browser goes offline, there is no mechanism in place to tell the player to reload the manifest and use the offline version of the manifest to determine which chunks to request.
The video player will continue to request the highest quality chunks, but browser is no longer online and can't serve them.
We need to make sure the player is able to respond to connection status changes and use the resources (media chunks) from the offline manifest whenever the client is offline.
Because this is a larger effort that would address a relatively rare edge case, I'm treating this a low priority. As a partial workaround, the user can refresh the page and play the downloaded video in full, because the video player will reinitialize with the offline manifest.
Bug Description
The application has a hero video section on the home page that is prominently displayed and can be played. Below it there are category sections and the same video in the hero section is repeated below in its own category.
However, it looks like the hero video and the corresponding category video are not connected because user can download the one in the category section for offline viewing, make the service worker go offline, but still the hero video does not play.
This can be confusing to the user, since we claim that all videos are downloadable for offline viewing. Clearly the hero video is NOT in this category.
Expected Behaviour
If we claim that all videos we host are available for offline viewing, then the Hero section video should also be downloadable and should be able to be played after going offline - right from the home page !
Steps to reproduce
Screenshots
Screencast of reproducing the problem: https://share.getcloudapp.com/12uoYL7m
Additional context
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
Implementation brief
QA testing instructions
Demo
Changelog entry
The text was updated successfully, but these errors were encountered: