This case is most likely to happen when re-preparing a multi-period
live stream after an error. The live timeline can easily move on to
new periods in the meantime, creating this type of update.
The behavior before this change has two bugs:
- The player resolves the new start position to a subsequent period
that existed in the old timeline, or ends playback if that cannot
be found. The more useful behavior is to restart playback in the
same live item if it still exists.
- MaskingMediaSource creates a pending MaskingMediaPeriod using the
old timeline and then attempts to create the real period from the
updated source. This fails because MediaSource.createPeriod is
called with a periodUid that does no longer exist at this point.
We already have logic to not override the start position and need
to extend this to also not prepare the real source.
Issue: androidx/media#1329
PiperOrigin-RevId: 634833030
dd7fb8178a