[gdoumen]

Summary

Production logs show mobile video_not_ready ride-start cancellations at about 2.5x the desktop rate. The start check seeked to 0.1, then back to 0, and only became ready after a second confirmed onSeek, with no time limit anywhere. A seek the player never confirms blocked the start indefinitely, and seeking back to the very start of a streamed file forces a fresh fetch whose confirmation waits for the player's default ~2.5s playback buffer.

What changed

• Dropped the seek back to 0. Once the bootstrap seek to 0.1 is confirmed the video is ready; being a few frames in is within tolerance, and every ride start saves a network round trip.
• Bounded wait. New VIDEO_SEEK_TIMEOUT_MS (300ms): if the initial seek (bootstrap or direct to startTime) is not confirmed in time, the frame currently showing is accepted and onLoaded fires. The timer is cleared on completion and on unmount.
• Smaller Android buffer. VideoView passes bufferConfig={{ bufferForPlaybackMs: 1000 }} to the native player (Android only; default is 2500ms).

Not part of this change: videos that never get past the native load event, and the load start event log that always reports null fields.

Test plan

• New Video.test.tsx: bootstrap seek confirmed -> ready with no second seek; unconfirmed seek -> ready after the timeout (bootstrap and startTime); late confirmation does not complete twice; no timeout after unmount
• New VideoView.test.tsx: bufferConfig passed to the native player
• Full jest suite, tsc, eslint
• Check on a real Android device (ride start with and without a resume position)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud