Repository navigation
fix: Auto-skip re-seeking forever at the end of a segment - #1178
Open
MrRussLuther wants to merge 1 commit into
Open
MrRussLuther wants to merge 1 commit into
MrRussLuther wants to merge 1 commit into
Conversation
MediaSegment.inRange included the end, so skipping a segment (which seeks to its exact end) left the position still inside it. With the action set to Skip, auto-skip fired again on the next rebuild and kept seeking to the same spot, freezing playback there. It shows up on high-bitrate files where the player is still sitting at that position after each seek, e.g. an intro from 0 to 33.6s on a Blu-ray remux. A segment is now [start, end): the end is where it's over. Skips still land exactly on the marker, and back-to-back segments hand over at the boundary instead of both matching it. The native Android player had the same inclusive check. It got away with it by auto-skipping to 250 ms past the end, which cut that much off the start of what follows, and its Skip button seeked to the exact end so the button stayed up after pressing it. It now uses the same [start, end) check and seeks to the exact end in both cases.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request Description
MediaSegment.inRange included the end, so skipping a segment (which seeks to its exact end) left the position still inside it. With the action set to Skip, auto-skip fired again on the next rebuild and kept seeking to the same spot, freezing playback there with the Skip Intro button still up. It shows up on high-bitrate files where the player is still sitting at that position after each seek. Repro: a 32 Mbps remux with an intro from 0 to 33.6 s, loaded through the queue (next-up or the previous button). A fresh start or a mid-play seek doesn't trigger it.
A segment is now [start, end): the end is where it's over. Skips still land exactly on the marker, and back-to-back segments hand over at the boundary instead of both matching it.
The native Android player had the same inclusive check. It got away with it by auto-skipping to 250 ms past the end, which cut that much off the start of what follows, and its Skip button seeked to the exact end so the button stayed up after pressing it. It now uses the same [start, end) check and seeks to the exact end in both cases.
Three tests in test/media_segments_model_test.dart cover the range, the skip-to-end case and the back-to-back handover.
Issue Being Fixed
No issue filed.
Screenshots / Recordings
None, the fix is a boundary check.
Tested On
Checklist