Checklist
Describe the bug
When watching a livestream and using the hold-to-speed (long-press) feature to temporarily accelerate playback, the speed becomes corrupted once the available buffer is fully consumed (i.e. the player reaches the live edge while still holding).
Instead of cleanly falling back, the playback rate drops to 0.33x and remains stuck at that incorrect speed. The only way to recover is to open the speed menu and manually reset it.
Comparison with expected/acceptable behavior:
If the user sets a permanent speed of 3x via the speed toggle/menu and then hits the no-buffer (live edge) limit, the player correctly falls back to 1x. This is the desired behavior.
The temporary hold-to-speed path does not follow the same recovery logic and ends up in a broken 0.33x state.
This makes the hold-to-speed feature unreliable specifically on livestreams.
Actual result:
Speed drops to 0.33x and stays broken until manually reset from the speed menu.
Expected result:
Speed should cleanly fall back to 1x (same behavior as when a permanent high speed hits the live edge), or at least restore the original pre-hold speed without entering a corrupted state.
Version
5.2.5
Frequency
Always (100% of the time)
Device
Samsung A50, Xiaomi Mi 5x , Redmi 4A
Steps to reproduce the bug
- Open any active livestream in PipePipe.
- Ensure there is some buffer available (not already at the live edge).
- Long-press (hold) on the video to activate temporary speed-up (e.g. the configured hold-to-speed rate such as 2x or 3x).
- Continue holding until the buffer is fully consumed and the player reaches the live edge.
- Observe the playback speed.
Additional context
- Permanent speed changes already handle the “no buffer left on livestream” case correctly (reset to 1x).
- Only the temporary hold-to-speed path is broken.
- The issue is specific to livestreams; it does not appear to affect regular VODs in the same way.
- Feature history: Long-press / hold-to-speed was added in earlier versions (around v3.5.0). Later versions also added automatic reset of permanent speed to 1x when reaching the livestream edge — the temporary hold path seems to have missed equivalent handling.
Checklist
Describe the bug
When watching a livestream and using the hold-to-speed (long-press) feature to temporarily accelerate playback, the speed becomes corrupted once the available buffer is fully consumed (i.e. the player reaches the live edge while still holding).
Instead of cleanly falling back, the playback rate drops to 0.33x and remains stuck at that incorrect speed. The only way to recover is to open the speed menu and manually reset it.
Comparison with expected/acceptable behavior:
If the user sets a permanent speed of 3x via the speed toggle/menu and then hits the no-buffer (live edge) limit, the player correctly falls back to 1x. This is the desired behavior.
The temporary hold-to-speed path does not follow the same recovery logic and ends up in a broken 0.33x state.
This makes the hold-to-speed feature unreliable specifically on livestreams.
Actual result:
Speed drops to 0.33x and stays broken until manually reset from the speed menu.
Expected result:
Speed should cleanly fall back to 1x (same behavior as when a permanent high speed hits the live edge), or at least restore the original pre-hold speed without entering a corrupted state.
Version
5.2.5
Frequency
Always (100% of the time)
Device
Samsung A50, Xiaomi Mi 5x , Redmi 4A
Steps to reproduce the bug
Additional context