Shaka Offline Download Speed is SLOW

[jookeboxpm]

Have you read the Tutorials?
Yes

Have you read the FAQ and checked for duplicate open issues?
Yes

What version of Shaka Player are you using?
3.2.x

Please ask your question
I am attempting to download several DASH files from a Google Cloud Bucket for offline storage and playback. The code has taken an hour to download 120MB worth of data. I wish to know if there is a way I can speed up the download. I am running shaka-player on an Electron app, if that information helps

[jookeboxpm]

For reference, my download speed, on average, is 53.62 Mbps. The download, based on the Network tab, for Shaka download is averaging about 34Kbps

[joeyparrish]

There's certainly no deliberate code meant to slow down downloads. I don't even believe there's any API on the web that you could use to slow a download. Perhaps we're doing something poorly, but I don't know what it is.

Do you see the same download speed in the Shaka Player Demo in a typical desktop browser that you do in your Electron app?

Do you see any reason for the low speed when you look at the network tab for your app?

Do you get better speeds for the same files outside the app on the same machine (curl, wget, or browser)?

Is there a lot of downtime in the network panel where we aren't downloading?

How many segments are being downloaded for that 120MB of data?

[jookeboxpm]

I am using v3.3 and got the following message.

shaka.offline.Storage.store.then has been deprecated and will be removed in v4.0 . We are currently at version v3.3 . Additional information: Storage operations now return a shaka.util.AbortableOperation, rather than a promise. Please update to conform to this new API; you can use the |chain| method instead.

Could this be an issue?

[theodab]

That shouldn't have anything to do with download speed, no. It's just a deprecation warning for an API change we made in v3.0.

[jookeboxpm]

Do you see any reason for the low speed when you look at the network tab for your app?
No. The download progresses as expected without any downtime

Do you get better speeds for the same files outside the app on the same machine (curl, wget, or browser)?
wget gives me an average speed of 3.4Mbps. Browser averages about 23Mbps

Is there a lot of downtime in the network panel where we aren't downloading?
No. The nature of the application requires a consistent internet connection

How many segments are being downloaded for that 120MB of data?
Each DASH File has an average of 2000 seg files. So about 105000 files in total for 120MB worth of data.

[theodab]

That's a lot of individual files. Before we made some initial changes so we could later add background fetch support, all downloads happened sequentially. That is, we would download one segment, store it, then download the next segment once the previous one is fully stored.

So it might be that having to stop downloading and store a file 105000 times throughout the download process is what is causing things to go so slowly. I'm not super knowledgeable about IndexedDB, but I wouldn't be surprised if it had some amount of time overhead on operations.

In v4.0, on the other hand, downloads should happen more in parallel. We will still need to download and store each file separately, but at least we can be storing some files while we download others. Does the download go faster if you try v4.0?

[jookeboxpm]

I was trying to use v4.2.x but the python and docker commands to generate the shaka docs kept failing

[joeyparrish]

I don't think you need to generate the docs to use v4.2.x. You can see them here: https://shaka-player-demo.appspot.com/docs/api/index.html

[jookeboxpm]

I need the compiled docs. The latest update to the docker commands in 4.2.3 fixed the issue that prevented me from generating the compile files for 4.2.x. But when I used them in my source code, the storage instance started throwing a code:9017 error.

My storage configuration is as below:

[jookeboxpm]

I get the following error after the download manager executes

[theodab]

INDEXED_DB_INIT_TIMED_OUT is a new error that fires if indexedDB takes more than 2 seconds to initialize. It's meant to detect situations where window.indexedDB.open never fires any of its callbacks and just hangs indefinitely, which I've seen a few times in testing.

It's possible that 2 seconds is too short of a time for that timeout. Does it consistently take longer than that on your machine?

[jookeboxpm]

When I was running version 3.4, it never took that long. This time, the error is consistently popping up when I use the latest code from "main"

[avelad]

@jookeboxpm , with #4984 you should no longer see the error, can you try?

[github-actions]

Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including @shaka-bot reopen in a comment.