-
Notifications
You must be signed in to change notification settings - Fork 1.3k
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add background fetch to the library #879
Comments
Updated to include both background sync and background fetch as tools we may want to use for this, and closing #881 as a duplicate. |
Issues implementing background fetch & sync so far:
Given all of the above, I am moving this issue to the backlog for now. |
According to Chrome team, background fetch is not ready for production yet. Leaving this issue on the backlog until that changes. |
It would have been grate if the Native File System could be used somehow. |
This changes the order that things happen when the offline storage mechanism stores a manifest, so that the manifest is made and the segments are downloaded in separate steps. This is in preparation for adding background fetch support. Issue #879 Change-Id: I4451db839b654f6134f06a58c240a9ca98d31a4e
It is unlikely that we will be able to load DRM sessions inside the service worker for BG fetch. However, sometimes we have to get the DRM keys from the init segments. This changes Storage.downloadSegments_ to download the init segments first if it looks like they will contain needed init data to create license requests. This also fixes a typo that was preventing us from getting init data from segments, and adds a test that would catch that issue. Issue #879 Change-Id: Ide859ed0eb2d9208150787f14d915135df681d96
This refactors the storage mechanism so that the method that attaches a segment to the manifest is be a stateless async method, and no longer needs to be in the same session as the method that stored the manifest. This is the end of phase one of the work towards allowing Shaka Player to use background fetch to store assets offline. This change will allow a service worker to store the segments as they are downloaded, without having to keep the Shaka Player instance alive. Issue #879 Change-Id: I6a3545c57bacaf7229fe8c32669e88c6cc4e4138
@theodab I have seen that with the latest changes all the initialization segments will be downloaded, even of qualities that are not going to be downloaded, is it intentionally? |
@avelad What assets are you seeing that happen on? I tried downloading |
@theodab I have recorded a video, but it is too big to attach here, I have mailed it to you. |
We load the init segments so that we can create the segment index for those variants; that asset uses It's not a new behavior. For example, I loaded that same asset you showed in We have been working on a variety of performance enhancements recently (see, for example, #1936). I believe one of the planned enhancements is to lazy-load the segment index, which should fix this problem. |
This may be blocked on changes in Chrome for now: https://bugs.chromium.org/p/chromium/issues/detail?id=1256838 |
Possibly also blocked by this: https://bugs.chromium.org/p/chromium/issues/detail?id=1255711 |
@joeyparrish I have seen that of the two issues that block the implementation, one is closed and the other has a commit, but it is not closed. Do you know if this is already working in the latest versions of Chrome? |
We are waiting for the changes to become on-by-default and in the stable branch of Chrome. AFAIK that has not happened yet. |
Once we have a PWA (#876), we should look into the use of background sync and/or background fetch to fetch segments for offline storage. This also depends on Fetch support (#829).
With this, one could begin storing content for offline consumption, then close the app and let the segments be fetched and stored in the background, as connectivity is available.
The text was updated successfully, but these errors were encountered: