/
/
# What does this implement/fix? The Spotify Soloist backend decides where one track's audio ends and the next begins from two different engine events: a track change, and a playback state report. The difference matters — a track queued twice in a row is reported under the same track ID on both sides of the boundary, so only a track change may move on to the second play. A state report arriving in the last seconds of the first one must not, or it would cut that track short. That distinction had no test covering it: every boundary test called the internal handler directly, so swapping the two event kinds around passed the whole suite. These tests drive the real events instead, so the mix-up cannot come back unnoticed. ## Types of changes - [ ] Bugfix (non-breaking change which fixes an issue) — `bugfix` - [ ] New feature (non-breaking change which adds functionality) — `new-feature` - [ ] 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` - [x] Maintenance / chore — `maintenance` - [ ] CI / workflow change — `ci` - [ ] Dependencies bump — `dependencies` ## Changes - A track change for the track already playing moves on to its queued repeat. - A playback state report for that same track does not, so the first play keeps its tail. - An event of either kind naming another track still cuts at the boundary and carries the new track's duration over. - Both `playback_state` snapshots and `playback_changed` deltas are covered, since they decode to the same payload and only the event type tells them apart. - The engine events also decode to the payload each one expects, so they cannot start decoding into each other unnoticed. - The position report the boundary check reads was untested too, and is now covered: it is what tells a track that played out from one the engine was pulled off. ## 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.