Skip to content

cmd_volume_set dropped as "unavailable player" during active playback, while the player reports available: true #5638

@winoiknow

Description

@winoiknow

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

  • I have examined the logs and tried to resolve this issue
  • I have fixed any errors or warnings in the logs that relate to tags
  • I am not running MA across a VPN, VLAN, subnet, behind a firewall, or using local SSL or have any other complex network setup
  • I am not using or have disabled tools such as AdGuard, Pi-hole or pfSense and retested
  • I have checked my network setup to ensure mDNS/multicast is not being blocked
  • I have reviewed the Open and Closed Issues and Discussions
  • I have reviewed the applicable player or music provider documentation
  • I have reviewed the MA Status Page
  • I have tried restarting MA and rebooting the host

As Applicable: Carefully read the Troubleshooting FAQ and confirm that

  • If using HA, I have confirmed the internal URL is set correctly
  • I have tried a wired connection for issues related to interrupted or poor playback quality
  • If the problem relates to a device then I have checked the device settings
  • If it is a frontend issue, I have tried a different widely used browser
  • For voice problems, I have sought help elsewhere before returning here
  • For playback problems, I have recycled power to the physical device

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

  1. A universal_player whose volume goes via follow_protocol to an output protocol
    that reports supported_features: [] / volume_level: null (volume via group_volume).
  2. Start playback to it.
  3. Issue volume_set (MCP tool, or media_player.volume_set) repeatedly during playback.
  4. 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

  • Yes

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions