Fix skip last calculation at increased playback speeds#5230
Conversation
There was a problem hiding this comment.
Pull request overview
Fixes Skip Last triggering too early at higher playback speeds by making the skip threshold represent listening time rather than media time, and adds unit tests to lock in the corrected behavior.
Changes:
- Added pure helper functions (
effectiveSkipLastMs,shouldSkipLast) to compute Skip Last thresholds using playback speed (clamping sub-1x to 1x). - Updated the Skip Last trigger logic to use the helper and included playback speed in the diagnostic log line.
- Added unit tests covering 1x baseline, >1x scaling, sub-1x clamping, and edge cases (null/zero config, invalid duration/position).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| modules/services/repositories/src/main/java/au/com/shiftyjelly/pocketcasts/repositories/playback/PlaybackManager.kt | Introduces helper-based Skip Last thresholding that scales with playback speed and updates the runtime skip check/logging. |
| modules/services/repositories/src/test/java/au/com/shiftyjelly/pocketcasts/repositories/playback/PlaybackManagerSkipLastTest.kt | Adds unit tests verifying speed-scaled Skip Last behavior and key edge cases. |
|
Version |
|
@sztomek would you mind looking at the comments above? |
…-increased-speed # Conflicts: # CHANGELOG.md
- Guard effectiveSkipLastMs against NaN playback speed - Capture playbackStateRelay once in updateCurrentPosition - Clamp remainingMs to avoid negative time-saved stats - Fix misleading test comment about prior behaviour
|
@geekygecko addressed the comments |
|
Version |
|
@geekygecko no pressure, but did you have a chance to review the code? |
|
Thanks for addressing the comments, I will take a look today. |
geekygecko
left a comment
There was a problem hiding this comment.
I could be misunderstanding, but I’m not sure this change makes sense to me.
I thought the idea of ‘Skip Last’ was that a podcast regularly has a segment at the end of each episode that is always the same length. The user’s playback speed shouldn’t change that duration.
I tested this with ‘Skip First’ set to 60 seconds and playback speed set to 2x, and it still only skipped the first 60 seconds for me.
Description
Skip Last was not accounting for playback speed: the trigger compared media-time remaining against the configured
skipLastSecs, so a user playing at 2x with Skip Last set to 2:00 only saved ~1:00 of listening time before the episode auto-skipped. This was reported via Zendesk #11111728 and confirmed by the reporter's own investigation at 2x speed.This branch extracts two pure helpers (
effectiveSkipLastMsandshouldSkipLast) onPlaybackManager's companion object and multiplies the threshold by the current playbackSpeed, so the setting now represents listening time regardless of speed. Sub-1x speeds are clamped to 1x so slow-playback users never get a shorter skip window than they configured, and the log line now includes playbackSpeed to make future support tickets easier to diagnose.At 1.0x the behaviour is identical to before, so users who don't change speed see no change. New unit tests lock in the 1x baseline, verify the 2x trigger at the correct listening-time threshold, cover the sub-1x guard, and guard the null/zero edge cases.
Fixes PCDROID-542 https://linear.app/a8c/issue/PCDROID-542/skip-last-fires-too-early-at-higher-playback-speeds-skipping-less
Testing Instructions
Checklist
./gradlew spotlessApplyto automatically apply formatting/linting)modules/services/localization/src/main/res/values/strings.xml