DVR streams start at the beginning on slow networks

[defagos]

When the network is slow (use e.g. the network link conditioner with the 3G setting), DVR settings very often start at the beginning of the DVR window.

This is a regression introduced with the improved 2.5 position support.

Issue type

Incorrect behavior

Environment information

• Library version: 2.5 and above
• iOS version: Tested on iOS 12
• Device: iPhone X

Reproducibility

Easily reproducible

Steps to reproduce

1. Enable the network link conditioner and use the 3G setting.
2. Open the SRG Media Player demo and play a DVR stream with an SRG Media Player based player.
3. Wait until the stream starts. The stream will likely start at the beginning, otherwise try again.
4. Do the same with the iOS standard player. Everything works correctly.

[defagos]

Ready for review on the feature/dvr-start-issue branch.

[defagos]

The problem is now properly understood and fixed.

With a slow connection, stream startup is slow. The player takes time loading the first chunk to be played, but already knows the chunk size because it could retrieve the playlist metadata. If the time to load the first chunk to be played is longer than a chunk, the window will be already offset by a chunk (in this example, 10 seconds):

(CMTimeRange) $20 = {
  start = 10000 1000ths of a second {
    value = 10000
    timescale = 1000
    flags = kCMTimeFlags_Valid
    epoch = 0
  }
  duration = 7150000 1000ths of a second {
    value = 7150000
    timescale = 1000
    flags = kCMTimeFlags_Valid
    epoch = 0
  }
}

Our code was incorrectly fixing the initial desired position to the time range, in this example of a slow startup to 10, making the player start at the beginning of the stream.

Fixing the position is wrong if we want a default start position (kCMTimeZero) with no initial segment selected. By adding this exception and fixing the position only in other cases, the bug could be fixed.

[pyby]

Reviewed. Tested. Unit tests passed. Nice investigation.