Spun from bug 1089937 comment 18. "It feels to me that the fuzz should be used as an acceptable tolerance, but SelectReader() should prefer something closer to the expected, if available, so as to avoid possibly skipping over available frames. This can be a separate bug if you like. I also suspect the fuzz should be applied in SelectReader() or other SelectReader() callers will have similar problems. It might be necessary now however to find the closest available if applying the fuzz in SelectReader()." Need to look at all usage of MediaSourceReader::SelectReader and apply the selection logic so it takes into account of the time fuzz factor introduced in bug 1089937.

There are 3 situations where SelectReader() is used, and it seems we may want different approaches for at least some of the different situations. * On EOS If the current reader has not played up to the beginning of the range for the nearest next reader, then we can accept a gap up to some tolerance. If the current reader has played up to the beginning of the range for the next reader, but the current reader's buffered range says that the ranges overlap, then there is the issue that selecting the reader for a target matching the end of the last decoded interval may select the reader that has reached EOS. Advancing the target to the end the current reader's range, past the start of the range of the next reader, was the approach used to avoid this problem in bug 1089937. Perhaps another possible approach might be to use lower bounds for the end times of buffered ranges, when selecting a reader on EOS. If the current reader has played past the beginning of the range for the next reader, and there is considerable overlap in the ranges of the readers, then perhaps we need to seek into the next reader. * On seeking. If we are not sure whether one reader will provide data for a target time (because of uncertainty in the end time) then perhaps we can just advance to the next reader, if there is one close enough, or otherwise fail seek or report end of stream, as appropriate. That might be the easiest approach, and is similar to the EOS case. Alternatively, if we want to be more accurate, we could try the reader with the earlier range and follow a process like that of EOS above to move to the next reader only if the first reader fails to seek. * In RequestAudioData(). If we have a current reader, then we don't want to jump a gap to the next reader as in the EOS case, unless it is EOS, and I assume we can let the EOS code handle that. If there is more recent data in another reader for the range of the current reader, or "better" data, then we'd like to switch readers. I don't know whether better or more recent is more important, or specified. We may need to seek into the next reader, if ranges overlap.

This has been fixed by bug 1127203 and bug 1125776