Skip to content
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

Don't re-load a Manifest's optional external resource each time if initial failed #1370

Merged
merged 1 commit into from
Feb 5, 2024

Conversation

peaBerberian
Copy link
Collaborator

@peaBerberian peaBerberian commented Jan 31, 2024

While doing some testing on <UTCTiming> elements in a DASH MPD, it has been brought to us that if all attempts to load its linked URL failed for the initial fetch of the Manifest (in which case we fallback to a mode where we don't rely on that element) and if the Manifest has to be refreshed multiple times, then the URL will be accessed every time the Manifest is refreshed, even if just one sucessful attempt would have been enough.

The issue was very simple to fix, as it was just that a newly obtained clockOffset - the actual metadata derived from parsing an <UTCTiming> element, was not actually copied when updating the base Manifest by its new parsed version.

Once that clockOffset is set to the base Manifest, that information will be communicated to our Manifest parser when the Manifest is refreshed, so it won't retry to load the clock and continue relying on the one fetched before.

@peaBerberian
Copy link
Collaborator Author

This looks like it would also be present on v3 and is very simple. So if/when merged, I'll backport this to v3

@peaBerberian peaBerberian added Priority: 1 (High) This issue or PR has a high priority. bug This is an RxPlayer issue (unexpected result when comparing to the API) needs-backporting The fix/improvment should be backported to v3 labels Jan 31, 2024
…itial failed

While doing some testing on `<UTCTiming>` elements in a DASH MPD, it has
been brought to us that if attempts to load an URL linked to it for the
initial fetch of the Manifest failed (in which case we fallback to a mode
where we don't rely on that element) and if the Manifest has to be
refreshed multiple times, then the URL will be accessed every time the
Manifest is refreshed, even if just one sucessful attempt would be
enough.

The issue was very simple to fix, as it was just that a newly obtained
`clockOffset` - the actual metadata derived from parsing an
`<UTCTiming>` element, was just not actually copied when updating the
base Manifest by its new parsed version.

Once that `clockOffset` is set to the base Manifest, that information
will be communicated to our Manifest parser when refreshed, so it won't
retry to load the clock and continue relying on the one fetched before.
@peaBerberian peaBerberian force-pushed the fix/update-clock-offset branch from e75e8d5 to 650f7d8 Compare February 5, 2024 10:44
@peaBerberian peaBerberian merged commit 94c61c6 into dev Feb 5, 2024
4 of 5 checks passed
peaBerberian added a commit that referenced this pull request Feb 5, 2024
Don't re-load a Manifest's optional external resource each time if initial failed
peaBerberian added a commit that referenced this pull request Feb 5, 2024
Don't re-load a Manifest's optional external resource each time if initial failed
@peaBerberian peaBerberian mentioned this pull request Feb 5, 2024
peaBerberian added a commit that referenced this pull request Feb 5, 2024
Don't re-load a Manifest's optional external resource each time if initial failed
@peaBerberian peaBerberian added this to the 4.0.0-rc.2 milestone Feb 5, 2024
@peaBerberian peaBerberian deleted the fix/update-clock-offset branch February 7, 2024 17:55
peaBerberian added a commit that referenced this pull request Feb 20, 2024
Don't re-load a Manifest's optional external resource each time if initial failed
peaBerberian added a commit that referenced this pull request Feb 20, 2024
Don't re-load a Manifest's optional external resource each time if initial failed
@peaBerberian peaBerberian mentioned this pull request Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This is an RxPlayer issue (unexpected result when comparing to the API) needs-backporting The fix/improvment should be backported to v3 Priority: 1 (High) This issue or PR has a high priority.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants