aiosendspin[server]~=6.0.1 pin locks out 6.1.x, where MediaCommand.SEEK lives — servers advertising seek silence the daemon

Open Beginner friendly
#280 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
cli

Research direction

Start at the package dependency declaration for sendspin 7.5.0 and verify how the aiosendspin constraint is resolved by pip. Done means a fresh installation permits the 6.1.x client and the reported server/state message with seek commands no longer prevents streaming; confirm the dependency resolution and affected behavior before release.

Written by the indexing model from the issue text.

Description

sendspin 7.5.0 (current release) declares:

aiosendspin[server]~=6.0.1

~=6.0.1 resolves to >=6.0.1, <6.1.0, so a fresh pip install sendspin can never receive aiosendspin 6.1.x.

That matters because 6.1.0 added seek and seek_relative to MediaCommand, and servers have started advertising them. Loxone/Sonn Core 4.0.0-beta.21 puts both into controller.supported_commands for any track with a known duration. On aiosendspin 6.0.x that value cannot be parsed, and since supported_commands is typed list[MediaCommand], the whole server/state message is thrown away:

ERROR:aiosendspin.client.client:Failed to parse server message: {"type":"server/state","payload":{"controller":{"supported_commands":[...,"seek","seek_relative"],"volume":10,...,"seek_max_ms":310000}}}
ValueError: 'seek' is not a valid MediaCommand
mashumaro.exceptions.InvalidFieldValue: Field "supported_commands" of type list[MediaCommand] in ControllerStatePayload has invalid value [...]

The daemon then never starts a stream — the room is simply silent, while volume commands (a different message) still apply, so the client looks alive. Live streams with no duration keep working, which makes it look source-specific rather than protocol-specific.

Installing aiosendspin==6.1.1 fixes it completely (verified here across 5 rooms: Stream started with codec pcm immediately after the restart, audio at the card), but leaves the install outside the daemon's own declared range:

ERROR: pip's dependency resolver ... sendspin 7.5.0 requires aiosendspin[server]~=6.0.1, but you have aiosendspin 6.1.1 which is incompatible.

Would you consider relaxing the pin to >=6.0.1,<7 (or cutting a 7.5.1 that does)? The 6.0.5 → 6.1.1 delta is additive on the client side — two enum members, the matching ControllerStatePayload fields, and small server-role changes.

Server-side context and the interop side of this: sonn-audio/core#382.

Dominant language
Python
Stars
190
Forks
36
Avg merge
11d 19h
Merged PRs (30d)
2

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Sendspin/sendspin-python-cli

All issues in Sendspin/sendspin-python-cli

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.