After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 776609 - adaptivedemux: actually retry on download errors
adaptivedemux: actually retry on download errors
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.12.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-12-30 09:17 UTC by Matthew Waters (ystreet00)
Modified: 2017-05-29 07:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
adaptivedemux: retry fragment download MAX_DOWNLOAD_RETRY_COUNT times (1.34 KB, patch)
2016-12-30 09:18 UTC, Matthew Waters (ystreet00)
committed Details | Review

Description Matthew Waters (ystreet00) 2016-12-30 09:17:00 UTC
The download error case was not taking into account the MAX_DOWNLOAD_ERROR_COUNT and could cause a long wait (for live streams waiting for a manifest update) or an immediate error (for non-live).
Comment 1 Matthew Waters (ystreet00) 2016-12-30 09:18:52 UTC
Created attachment 342607 [details] [review]
adaptivedemux: retry fragment download MAX_DOWNLOAD_RETRY_COUNT times
Comment 2 Thiago Sousa Santos 2017-01-21 21:23:07 UTC
Does retrying instantly the same fragment help for your use case? Wouldn't it get the same error a few times in a row and wait anyway?
Comment 3 Matthew Waters (ystreet00) 2017-01-23 01:27:16 UTC
Yes, retrying immediately helps.

The waits with a certain manifest (that I unfortunately don't have access to anymore) would wait for the next fragment for hours.
Comment 4 Sebastian Dröge (slomo) 2017-03-02 17:27:58 UTC
Comment on attachment 342607 [details] [review]
adaptivedemux: retry fragment download MAX_DOWNLOAD_RETRY_COUNT times

Maybe it should wait a smaller time then, and only do the long wait if all else fails?
Comment 5 Sebastian Dröge (slomo) 2017-03-02 17:28:11 UTC
Retrying immediately is not ideal in any case
Comment 6 Matthew Waters (ystreet00) 2017-03-14 04:56:14 UTC
It's not immediate in any case, there are currently a few levels of waiting.  The flow is as follows without this patch:
1. Request returns 4xx/5xx.
2 we may or may not be in the seek range:
2.1 outside seek range: none of the existing wait/retries apply here and we get to the changed line which returns EOS when the number of retries is less than the MAX DOWNLOAD_ERROR_COUNT (which is pretty much always true).
2.2 before seek range: we advance the fragment and try again
2.3 after seek range we wait until the seek range comes into play and try again.
3. EOS returns result in waiting for hours for manifest update.

With the change:
1. The same
2.1 for the number of download errors < MAX DOWNLOAD_ERROR_COUNT, we return some kind of error which causes the download thread to try again later (after half the fragment duration).
2.2. for number of download errors >= MAX DOWNLOAD_ERROR_COUNT we return EOS which results in the manifest wait time again (i.e. hours).

Also, with the change we don't double increment stream->download_error_count as that seems counterproductive to actually waiting a specified number of times.
Comment 7 Sebastian Dröge (slomo) 2017-05-25 10:34:03 UTC
commit 430a90df20881dcfb3b1d84e60f5e49549d11490
Author: Matthew Waters <matthew@centricular.com>
Date:   Fri Dec 2 17:51:57 2016 +1100

    adaptivedemux: retry download MAX_DOWNLOAD_RETRY_COUNT times before erroring
    
    What we want is to retry downloading the fragment on 4xx/5xx errors
    however returning EOS will cause waiting for a manifest update for live
    (which may be a really long time) or stop everything for non-live.
    
    Change that to only return EOS/ERROR once we've reached the error limit.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=776609