-
Notifications
You must be signed in to change notification settings - Fork 2
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
fix: rebuffering percentage inflated if client ads fail to load #68
Conversation
a720804
to
98db116
Compare
// content. The events all really happen and there really is a short playback interuption so | ||
// it's good to count it all | ||
if (muxPlayerState == MuxPlayerState.REBUFFERING) { | ||
stateCollector.pause() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question(non-blocking): any concerns with failing to unpause later (e.g. due to other jank conditions?) thereby deflating rebuffering?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, it would be ok. We technically "unpause" when we get adbreakstart
because MuxPlayerState
goes from PAUSED
to AD_BREAK_STARTED
or something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.. and the other part of your question: the rebuffer tracker doesn't check for pause
so it's safe to send from that perspective.
A pause
event is also not-wrong here, since content stopped playing. After the ad is over, playing
will be sent, which will unpause us, and media3 makes it easy to protect that process from jank by checking exoplayer's state, which we do
MuxPlayerState.REBUFFERING, stateCollector.muxPlayerState | ||
) | ||
|
||
Assert.assertTrue( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion(non-blocking): As long as this has been smoke tested, I don't think this should be a blocker, but we should probably have 1+ test case(s) validating buffering after leaving ad playing state, ideally that adequately represent what can happen in real world usage, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'd be ok, becuase that pause()
call will end the rebuffering state at the beginning of the ad break (mentioned in other comment). And the way that it "ends the rebuffering state" is twofold: 1) setting our overall muxPlayerState
thing to PAUSED
2) if muxPlayerState
was REBUFFERING
before that, it sends rebufferend
to the core (and backend and dashboard)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving with a couple of nb callouts.
## New * `MuxErrorException` now allows you to report non-fatal and business-related errors ## Improvements * update: Updated MuxCore to version 8.0.0 * update: Updated Android Core to version 1.2.0 ## Fixes * fix: renditionchange sent in situations where rendition was only reset (#73 ) * fix: Capture IMA CSAI media failures with LOG events (#67) * fix: rebuffering percentage inflated if client ads fail to load (#68) Co-authored-by: Emily Dixon <edixon@mux.com> Co-authored-by: GitHub <noreply@github.com>
No description provided.