Open loicraux opened 4 months ago
For those facing this issue, there is a workaround to mitigate it until this bug is fixed :
The idea is to have a sort of store in your application where you have your downloads in progress. On the download in progress data structure you need at least 2 properties :
abortableOperation
that was returned by storage.store
when you started the download...When in the UI, the user cancel a download in progress, you need to :
abortableOperation
: abortableOperation.abort()
.. But you do not remove the download in progress from your store at this point !
Now it can happen that the call to abortableOperation.abort()
does not work (this is the bug filed here).
The idea/workaround is to have your progressCallback
event handler checking whether or not the content being downloaded is indeed already cancelled (by checking the flag)... Is this is the case, then you must attempt once again to abort the abortableOperation
(abortableOperation.abort()
) and do not update your store with progress data...
After a certain number of abortion attempts, the download will eventually successfully be aborted. Shaka player code will in this case throw an error with code shaka.util.Error.Code.OPERATION_ABORTED
and it's up to you catch this error (which is the sign that the abortion is successful) and now remove the download in progress from your store.
This workaround works fine, but it can also happen that the user cancels the download when it's almost finished, in this case it can happen that none of your abortion attempts work and the download --despite being cancelled-- ends up completed in IndexedDB. So you have to add an extra workaround in your code that is run after the awaited download operation, to check whether or not the completed download corresponds to a download in progress marked as being cancelled in your store ... If this is the case, then you have to storage.remove
the completed download (and also in any case remove the download in progress from your store)...
There you go, it may help some people who are facing this problem...
@loicraux are you interested on send a PR to fix it? Thanks!
Have you read the FAQ and checked for duplicate open issues? Yes
If the problem is related to FairPlay, have you read the tutorial? N/A
What version of Shaka Player are you using? Latest version 4.7.11
Can you reproduce the issue with our latest release version? Yes
Can you reproduce the issue with the latest code from
main
? YesAre you using the demo app or your own custom app? Own custom app.
If custom app, can you reproduce the issue using our demo app? This cannot be reproduced in Shaka Player demo app, since there is no mean to interrupt/abort a download operation from the Demo UI. (correct me if I am wrong)
What browser and OS are you using? Chrome in a VMP-signed Electron.
For embedded devices (smart TVs, etc.), what model and firmware version are you using? N/A
What are the manifest and license server URIs? This is not specific to a manifest nor a specific license server.
What configuration are you using? What is the output of
player.getConfiguration()
? See code sample below.What did you do? My app basically revolves around downloading some content, but also being able to cancel an ongoing download. It is important that when a download is interrupted, the fetching of segments operations are indeed stopped and the manifest-v5 table does not contain the interrupted download anymore.
Here is the code that runs when the download button is clicked :
The code that basically runs when the user clicks on the CANCEL button to cancel an ongoing download is the following :
What did you expect to happen? I expect :
the corresponding manifest to be removed from
manifest-v5
table ofshaka_offline_db
database in IndexedDB(I would be OK with a few extra progress events sent and even a couple of orphaned segments in IndexedDB after the download has been interrupted/canceled)
What actually happened? Sometimes, but not always (I'd say one out of two times), when I click on the button to cancel the download in progress, the download actually continues, right to the end (100%). At the end, the manifest-v5 table contains the download I had interrupted!
What I've observed is that when the download interruption is successful, a
shaka.util.Error.Code.OPERATION_ABORTED
exception is thrown by the call tostore()
. I can then catch this error in my code and make the current download disappear from my UI. For me, this exception is indeed a sign that the download cancellation has been successful.But sometimes (I'd say one out of two times), this error isn't thrown by
store()
following a call toabort()
, so the download continues, as if I hadn't calledabort()
.At this point, the user needs to click a couple of times on the cancel() button until the cancellation eventually occurs...
At first I thought that this problem of the interrupt not working only appear if you interrupt the download very quickly at the beginning, but in fact it can occur at any time during the download.
Note #1 : I have also observed that a couple of progress events are sent to the progressCallback, even if the download has already been interrupted (meaning after I have caught the
shaka.util.Error.Code.OPERATION_ABORTED
exception), but this is not a problem to me, I can easily ignored those events.Note #2 : I have also observed that after a download is successfully interrupted, there are most of time always a couple of orphaned segments left in the
segment-v5
table. I think this another issue to address, not related to the interruption of the download.