What server version of Music Assistant has the issue?
2.9.0
How is the MA server installed?
Home Assistant OS Addon
Mandatory: Carefully read the Troubleshooting FAQ and confirm that
As Applicable: Carefully read the Troubleshooting FAQ and confirm that
The problem
On a universal_player, cmd_volume_set is intermittently ignored with:
WARNING music_assistant.players Ignoring command cmd_volume_set for unavailable player <name>
…even though the player is playing and players_get_player reports available: true
at the same time. The identical command succeeds reliably when the player is idle.
The effect is that an external controller (here, the built-in MCP server driven by an
LLM voice agent) cannot reliably change the volume while the player is in a turn/stream.
Environment
- Music Assistant 2.9.0 (server
3.3.1), accessed via the built-in MCP server
(/mcp/v1), tool volume_set.
- Target player: a
universal_player (provider universal_player, builtin) whose
active output protocol is a third-party sendspin-cli protocol (mDNS-discovered).
volume_control: follow_protocol, mute_control: follow_protocol
supported_features: [], per-player volume_level: null; volume is represented by
group_volume (standalone player, no sync members).
- Volume changes are audible and correct when applied at idle (verified with a held,
re-asserted 90→20 sweep that tracked audibly in lock-step).
What happens
During active playback (a Queue Flow stream running, with start/finish churn around
the moment), cmd_volume_set for this player is dropped:
INFO music_assistant.streams Start Queue Flow stream for Queue <name> - crossfade: disabled
INFO music_assistant.streams Finished Queue Flow stream for Queue <name>
INFO music_assistant.streams Start Queue Flow stream for Queue <name> - crossfade: disabled
WARNING music_assistant.players Ignoring command cmd_volume_set for unavailable player <name>
- The MCP
volume_set call itself returns success (isError: false, result null) —
the rejection is silent to the caller.
- A
players_get_player poll taken across the same window reports available: true,
powered: true throughout — so whatever availability cmd_volume_set gates on is a
transient that the player snapshot never exposes.
- The same
volume_set on the same player, issued while idle, applies immediately and
persists.
How to reproduce
Using a voice assist agent such as one I am working on [https://github.com/winoiknow/agent-voice-assistant]
Steps: (1) While music is playing through sendspin-cli client integration request volume change from agent.
(2) Agent uses built-in MCP to adjust volume.
(3) Agent Confirms volume change. -> No actual Volume change.
Repro sketch
- A
universal_player whose volume goes via follow_protocol to an output protocol
that reports supported_features: [] / volume_level: null (volume via group_volume).
- Start playback to it.
- Issue
volume_set (MCP tool, or media_player.volume_set) repeatedly during playback.
- Observe intermittent
Ignoring command cmd_volume_set for unavailable player while
players_get_player reports available: true; the same call works at idle.
Music Providers
Not Applicable.
Player Providers
Sendspin-CLI (tested)
HAVPE (tested)
Full log output
logs.md
Additional information
cmd_volume_set is the path used by both media_player.volume_set (HA integration) and
the MCP volume_set tool, so a controller has no working way to set this player's
volume while it is playing — the command is accepted and then discarded. For an LLM/MCP
caller this is especially bad: the model "successfully" calls the tool and reports done,
but nothing changes.
Suspected area
- In
PlayerController.cmd_volume_set, the if not player.available: guard appears to
fire on a brief unavailability that coincides with queue-flow stream (re)start on a
follow_protocol universal player. Should volume commands be queued/retried across
a short unavailability window rather than dropped?
- Is the transient unavailability originating in core's universal-player availability, or
is it the sendspin-cli output protocol reporting itself unavailable during stream
transitions? (Happy to gather more if you can point me at the right logger/flag.)
- At minimum, the silent drop is hard to diagnose from a caller's side — surfacing it in
the command result (rather than only a server WARNING) would help.
What version of Home Assistant Core (if used) are your running
2026.6.2
What type of installation are you running?
Home Assistant OS
On what type of hardware are you running?
Proxmox
Have you included ALL of the information specified in the Troubleshooting FAQ or explained why you cannot
What server version of Music Assistant has the issue?
2.9.0
How is the MA server installed?
Home Assistant OS Addon
Mandatory: Carefully read the Troubleshooting FAQ and confirm that
As Applicable: Carefully read the Troubleshooting FAQ and confirm that
The problem
On a
universal_player,cmd_volume_setis intermittently ignored with:…even though the player is playing and
players_get_playerreportsavailable: trueat the same time. The identical command succeeds reliably when the player is idle.
The effect is that an external controller (here, the built-in MCP server driven by an
LLM voice agent) cannot reliably change the volume while the player is in a turn/stream.
Environment
3.3.1), accessed via the built-in MCP server(
/mcp/v1), toolvolume_set.universal_player(provideruniversal_player, builtin) whoseactive output protocol is a third-party
sendspin-cliprotocol (mDNS-discovered).volume_control: follow_protocol,mute_control: follow_protocolsupported_features: [], per-playervolume_level: null; volume is represented bygroup_volume(standalone player, no sync members).re-asserted 90→20 sweep that tracked audibly in lock-step).
What happens
During active playback (a
Queue Flow streamrunning, with start/finish churn aroundthe moment),
cmd_volume_setfor this player is dropped:volume_setcall itself returns success (isError: false, resultnull) —the rejection is silent to the caller.
players_get_playerpoll taken across the same window reportsavailable: true,powered: truethroughout — so whatever availabilitycmd_volume_setgates on is atransient that the player snapshot never exposes.
volume_seton the same player, issued while idle, applies immediately andpersists.
How to reproduce
Using a voice assist agent such as one I am working on [https://github.com/winoiknow/agent-voice-assistant]
Steps: (1) While music is playing through sendspin-cli client integration request volume change from agent.
(2) Agent uses built-in MCP to adjust volume.
(3) Agent Confirms volume change. -> No actual Volume change.
Repro sketch
universal_playerwhose volume goes viafollow_protocolto an output protocolthat reports
supported_features: []/volume_level: null(volume viagroup_volume).volume_set(MCP tool, ormedia_player.volume_set) repeatedly during playback.Ignoring command cmd_volume_set for unavailable playerwhileplayers_get_playerreportsavailable: true; the same call works at idle.Music Providers
Not Applicable.
Player Providers
Sendspin-CLI (tested)
HAVPE (tested)
Full log output
logs.md
Additional information
cmd_volume_setis the path used by bothmedia_player.volume_set(HA integration) andthe MCP
volume_settool, so a controller has no working way to set this player'svolume while it is playing — the command is accepted and then discarded. For an LLM/MCP
caller this is especially bad: the model "successfully" calls the tool and reports done,
but nothing changes.
Suspected area
PlayerController.cmd_volume_set, theif not player.available:guard appears tofire on a brief unavailability that coincides with queue-flow stream (re)start on a
follow_protocoluniversal player. Should volume commands be queued/retried acrossa short unavailability window rather than dropped?
is it the
sendspin-clioutput protocol reporting itself unavailable during streamtransitions? (Happy to gather more if you can point me at the right logger/flag.)
the command result (rather than only a server WARNING) would help.
What version of Home Assistant Core (if used) are your running
2026.6.2
What type of installation are you running?
Home Assistant OS
On what type of hardware are you running?
Proxmox
Have you included ALL of the information specified in the Troubleshooting FAQ or explained why you cannot