Mobile: fix playback speed resetting to 1.0x on episode start and interruption resume - #974
Open
mrmichaeladavis wants to merge 2 commits into
Open
Conversation
added 2 commits
August 28, 2026 21:46
…ayback speed on play - Auto-resume playback when AVAudioSession reports an interruption ended with shouldResume (e.g. a Siri or notification readout), instead of leaving the episode paused with no way to resume it if the screen is off. Real phone calls don't set shouldResume, so they're unaffected. - AVPlayer.play() always resets rate to 1.0, discarding a user-selected playback speed on episode start, lock-screen play, and interruption resume. Track the desired rate and reassert it after every play() call. Fixes the iOS side of madeofpendletonwool#882.
…l speed Root cause of both madeofpendletonwool#882 (iOS) and madeofpendletonwool#963 (Android): getPlayEpisodeDetails parsed the server's playback_speed field but dropped playback_speed_customized, which the Rust backend sends to distinguish a real per-podcast override from it echoing back the account-wide default (Users.playbackspeed). The mobile speed selector only writes to local SharedPreferences and never syncs to that server column, so for anyone who hasn't set it via the web UI it sits at 1.0. playPinepodsEpisode() then unconditionally called setPlaybackSpeed with that value right after starting playback, stomping whatever speed playEpisode() had just applied locally, on every episode start, on both platforms. That's why tapping the in-app speed +/- buttons after playback started seemed to fix it: it's the only path with no follow-up override. Add playbackSpeedCustomized to PlayEpisodeDetails and only apply the server's speed when it's an actual customization, in both the main playback path and the local-download background enrichment path. This doesn't replace the AVPlayer.play()-resets-rate fix already applied for iOS. That's a separate, contributing bug.
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
1 participant
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.
Fixes #882
Fixes #963
Fixes #973
Root cause
Two separate bugs caused the playback speed to reset to 1.0x.
On iOS,
AVPlayer.play()resetsrateto 1.0 on every call. This happenson episode start, on lock-screen resume, and after an interruption. Each
call erased the user's chosen speed. The fix tracks the desired rate and
sets it again after every
play()call.On both platforms,
getPlayEpisodeDetailsreads the server'splayback_speedfield but ignoredplayback_speed_customized. Thebackend sends this second field to show whether the value is a real
per-podcast override or the unchanged account default. The app set the
local speed first, when playback started. Then it applied the server
value too, on every episode start, on both platforms. The server value
overwrote the local value each time.
Also in this PR
On iOS, playback now resumes automatically when the system reports an
interruption with
shouldResumeset. An example is a Siri ornotification readout. Previously, if the screen was off, the episode
stayed paused with no way to resume it. A real phone call does not set
shouldResume, so calls are not affected.Testing
I tested this manually on iOS and Android.
notification readout, and keeps the correct speed.
overwritten.
UI, still uses the server value. This is the intended behavior.