6.6.4 - a range boundary keeps the bytes it was already handed

One fix, on the read path every VOD URL source goes through. No API change.

Fixed

• A bounded-range boundary no longer re-fetches bytes the origin already delivered. The #220 frontier refill opens the next range while data is still resident ahead of the read position, precisely so a range boundary does not become a stall. startPersistentConnection then reset the window start to that frontier and dropped the window with it, which for the refill is up to winLowWater (8 MB) of delivered but undrained data. The very next read therefore sat below the window start, took the backward branch, and pulled those same bytes back over the network in 4 MB detour blocks, blocking on the demux read thread. Two of them per boundary, once per 32 MB of source.

  A request that begins inside the resident window, or exactly at its end, is a continuation rather than a reposition, and now keeps its window. The narrow race where the old connection appends past the frontier the read loop computed truncates instead; the new range re-covers that span, so it never leaves a hole. Peak footprint goes down rather than up, since the discarded window used to come back as detour blocks on top of the new range.

  It needs a consumer slower than the transfer to appear, which is what playback is: the range completes long before the window drains, so the refill fires with the full low-water amount still resident. A test that reads flat out drains the window as fast as it arrives, reaches the boundary with nothing undrained, and sees nothing, which is why the existing #220 coverage stayed green through it. Issue295RangeBoundaryRefetchTests paces its consumer and asserts that no requested range overlaps another; before the fix the origin logs

  bytes=0-20971519          initial range
  bytes=20971520-54525951   frontier refill
  bytes=12582912-16777215   re-fetch
  bytes=16777216-20971519   re-fetch
  

  Reported by @rrgomes (#295) as brief picture glitches with no engine-log signature on a 6.7 Mbps SD MPEG-2 source, where a 32 MB boundary comes around every 40 s. The report that made it findable was a correlation run: linear playback with a pause tapped at each perceived glitch, every mark landing within reaction time of an [AVIOReader] detour fill line, at 40.2 s spacing. The engine had been logging the cause on every occurrence with nothing connecting it to a picture defect, which is now its own issue (#303).

Upgrading

Drop-in from 6.6.3. Nothing to change on the consumer side.