/
/
# What does this implement/fix? Shuffle and repeat only ever reached two places: a source Music Assistant bridges itself (a plugin session, like our own Spotify Connect), or the Music Assistant queue. A source the speaker runs on its own — a Sonos playing its own Spotify Connect session, a Bluesound input — has neither, so the command had nowhere to go and failed with "there is nothing playing to shuffle". The player models already carry `can_shuffle` / `can_repeat` per source and the app already shows the buttons for any source that claims them, so the first player provider to set those flags would have handed users a button that could only fail. This adds the missing path on the server so those providers can be written. A command can now also name the source it was aimed at. Without it, a shuffle click made while a source was playing could still land on the Music Assistant queue if the source ended in between — harmless at the time, but the setting then surprises you whenever that queue resumes. Only shuffle and repeat take the source name, not next/previous/seek: those two leave a setting behind that resurfaces later, while a stray skip is visible straight away. No provider implements this yet, so the new hook is not exercised end to end. The app change to send the source name is a follow-up. - Dispatch shuffle/repeat to the player when the active source is one its own device runs and declares the capability - New `set_shuffle` / `set_repeat` on the player model for providers to implement, forwarded by protocol-backed players - A source that does not claim the capability is now told so, instead of "there is nothing playing" - `players/cmd/shuffle` and `players/cmd/repeat` take an optional source, and refuse when that source is no longer playing - API schema version bumped, so the app can tell which servers accept it **Related issue (if applicable):** - related issue <link to issue> ## Types of changes - [ ] Bugfix (non-breaking change which fixes an issue) — `bugfix` - [ ] New feature (non-breaking change which adds functionality) — `new-feature` - [x] Enhancement to an existing feature — `enhancement` - [ ] New music/player/metadata/plugin provider — `new-provider` - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) — `breaking-change` - [ ] Refactor (no behaviour change) — `refactor` - [ ] Documentation only — `documentation` - [ ] Maintenance / chore — `maintenance` - [ ] CI / workflow change — `ci` - [ ] Dependencies bump — `dependencies` ## Checklist - [x] The code change is tested and works locally. - [x] `pre-commit run --all-files` passes. - [x] `pytest` passes, and tests have been added/updated under `tests/` where applicable. - [ ] For changes to shared models, the companion PR in `music-assistant/models` is linked. - [ ] For changes affecting the UI, the companion PR in `music-assistant/frontend` is linked. - [x] I have read and complied with the project's [AI Policy](https://github.com/music-assistant/.github/blob/main/AI_POLICY.md) for any AI-assisted contributions. - [ ] I have [raised a PR against the documentation repository](https://github.com/music-assistant/music-assistant.io/blob/main/CONTRIBUTING.md) targeting the main or beta branch as appropriate.