Playback Speed - #1667
Open
LMSSonos wants to merge 5 commits into
Open
Playback Speed#1667LMSSonos wants to merge 5 commits into
LMSSonos wants to merge 5 commits into
Conversation
LMSSonos
marked this pull request as ready for review
September 16, 2026 11:17
Adds a "speed" mixer feature (50-200%, applied via sox tempo in the transcoding pipeline) alongside the existing volume/bass/treble/pitch controls, with a speed dropdown on the Now Playing web UI. Speed changes reopen the current track at its playback position rather than restarting it, for mp3/flac/aac/mp4 sources. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: LMSSonos <sonos@envamo.com>
playingSongElapsed() combined startOffset with the player's raw songElapsedSeconds(), but that value is measured in the transcoded output stream's own timeline, which sox's tempo effect compresses or stretches relative to the original track. It needs to be scaled by the current speed before being added to startOffset, or songTime() drifts from the real position whenever speed != 100. mixerCommand's reopen-at-current-position logic also read songTime() after already writing the new speed pref, so once songTime() scales by the current speed, time played under the old speed would get scaled by the new one instead. Capture the position before changing the pref, then reopen with that saved value. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: LMSSonos <sonos@envamo.com>
…pen bugs Settings > Audio gets a new "Playback Speed Control" dropdown (off by default) that enables the Now Playing speed control and optionally resets it to 1x at the start of every track, or only when the album changes (so audiobook chapters keep the chosen speed). Disabling the setting doesn't clear the stored speed value, so TranscodingHelper and StreamingController's elapsed-time scaling now gate on the player actually having speed enabled, not just on that stored value, or a leftover non-100 value could keep quietly driving the tempo effect. The reset hook uncovered several bugs in the existing live-reopen mechanism along the way: - Song::open() only requests transcoder-level seek when Song::canSeek() == 2, and canSeek() caches its result the first time anything queries it - often earlier in the track's life, while speed was still 100 and no transcoding was needed, caching it as 1 instead of 2. Every later speed-change reopen then silently restarted the track from 0 instead of resuming. Fixed by clearing that cache right before the reopen. - Client::pluginData($key) as a single-arg getter only returns a per-key value for plugin callers; for any other caller it silently returns the whole data hash instead. That broke the "only reset on a genuine track change" guard (a hashref is never numerically equal to an integer song index), so with a reset policy enabled, the speed-change reopen kept re-triggering its own reset back to 1x. - Skip the reopen entirely within 2s of a track's end - asking the decoder to seek to virtually the end of the file produced harmless but alarming decoder/pipe errors for no audible benefit. - Subscribing to 'playlist newsong' at Commands.pm's top level broke server startup (Request.pm is still mid-compile when it `use`s Commands.pm, so Request::subscribe() doesn't exist yet); moved the subscribe call into Request::init(), which runs at actual server startup once everything is loaded. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: LMSSonos <sonos@envamo.com>
The web UI already exposes speed via a dropdown, but that's a skin-specific control - hardware players and apps navigate menus built from Slim::Menu::TrackInfo's OPML-based info providers instead (the same family that surfaces "Remove from playlist", "Play", and plugin-added items like a streaming service's "On: <Service>" entry). Adds a jive-only "speed" provider next to "Play" offering the same 1.0x-2.0x choices as the web dropdown, gated the same way (hidden unless the player has speed enabled) plus a check that it's only shown for the track that's actually playing, since this is a player setting rather than a per-track one. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: LMSSonos <sonos@envamo.com>
The repo owner doesn't want this file in the upstream repo. It's still useful as local working notes, so keep it on disk and ignore it going forward rather than deleting it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: LMSSonos <sonos@envamo.com>
LMSSonos
force-pushed
the
feature/playback-speed
branch
from
September 16, 2026 11:19
2c5011b to
ce46ad7
Compare
Contributor
Author
|
As discussed in #1342 tested as follow
|
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.
Added option to change playback speed
Feature must be activated per player in the settings -> audio options
Feature shows up in Trackinfo so that it can be changed on local device