Closed oliviermartin08 closed 11 months ago
For the question of Charles on the previous PR here: https://github.com/newrelic/video-agent-iOS/pull/20#discussion_r1226565258
I thought we wouldn't need this condition and would simply rely on
isSeekingDuringPlayback
changes to call [self sendSeekStart];. Is makingisSeekingDuringPlayback
KVO compatible a solution that could work?
No, it doesn't really fix it for the case where a user spams the seek button very quickly as mentioned in this PR Notes. βοΈ Basically, I think that we still need an internal state inside the tracker to provide sending multiple seek events when the player is already seeking (goSeekStart function purpose). This basically regroups multiple seek interactions inside a single seek event when the buffering occurs in the same time frame.
@oliviermartin08 PR looks good. As this is a major change due to function names changing, please bump up the version to 2.0.0
here. Thanks.
Bumped version to 2.0.0
, thanks @miransar π
π Description & Context
On iOS, a fix has been recently done to the video tracker in order to improve the seek events. What was done in https://github.com/newrelic/video-agent-iOS/pull/20:
CONTENT_SEEK_START
andCONTENT_SEEK_END
events.CONTENT_BUFFER_START
andCONTENT_BUFFER_END
with theirbufferType = seek
rather thanconnection
when seek occurs.β οΈ However, this fix did not cover correctly when a user made a seek during the pause state.
CONTENT_SEEK_END
event was only sent once the playback was resumed. That behavior was corrupting thetimeSinceSeekBegin
timer.CONTENT_BUFFER_START
andCONTENT_BUFFER_END
events were simply not sent, while it's still not possible to directly resume playback for a certain buffer time.π· Fix
Modified the state
isSeekingDuringPlayback
forisUserSeeking
. With this solution, the lib integrators are now 100% handling when a seek event starts (on a user seek interaction). Then, with the KVO observers, the tracker is handling by itself when the seek ends as well as its buffer. So, right now:CONTENT_SEEK_START
andCONTENT_SEEK_END
events are sent when paused (without the need to restart the playback).CONTENT_BUFFER_START
andCONTENT_BUFFER_END
events are sent when the player stays in a pause state. TheCONTENT_BUFFER_END
is sent when it's possible for the user to resume playback without any loading time (which is when the observerplaybackLikelyToKeepUp
changes totrue
during the pause state while seeking).π Notes about this solution
CONTENT_SEEK_END
was not handled by the tracker on par with the buffer events, it was leading to certain race conditions and unwanted behaviors.SEND_SEEK_START
,SEND_SEEK_END
and its buffer start/end.