positionIsWindowRelative

Whether currentTime is measured from the START OF A SLIDING WINDOW rather than from a fixed origin.

ExoPlayer reports live positions this way: Player.getCurrentPosition() is relative to the current Timeline.Window, whose start advances as segments age out. The consequence inverts every intuition built on the web contract — content playing at the live edge reports a roughly CONSTANT position, and a player falling behind reports a DECREASING one, because the window slides underneath it at real time.

Anything comparing position against elapsed wall time must know this. Measured on a Galaxy Tab S11 on 2026-08-25: continueContentDuringBreak computed expected = anchor + elapsedWall, which on a window-relative timeline runs away by the whole break, so a healthy break reported -155.9s of drift and raised a warning about it while the proxy showed content fetching 73 segments without a gap. The number was wrong, not the playback.

False is the safe default: an absolute timeline is what the web engines provide and what every existing calculation already assumes.