[REQUEST] Allow clients to belong to more than one group (i..e. each client should be allowed to belong to several groups)

[Hedda]

Please allow clients to belong to more than one group (i..e. each client should be allowed to belong to several groups).

At least the recent specification updates by @kahrendt seems to have limited group beloning to a single group per client -> #3

Use case examples:

• A single client should be able to belong to a group called "the whole house" at the same time it belongs to a group called "downstrairs".

• A single client should be able to belong to a group called "living area" (which may be a smaller part of a floor yet have several speakers) at the same time the same client belongs to a group called "downstrairs" which may be a a whole floor but perhaps not all areas on that floor, as users might for example like to exclude a garage area even if that area is on the same floor as a the other areas for "downstrairs").

For reference, I currently have this setup using a Google Cast for multi-room (with a mix of Chromecast Audio, Google Home speakers and Google Nest speakers) so know that it works setting this up in the Google Home application.

Note that in my case the "the whole house" group does on purpose not actually contain all speakers, but it is instead a currated list of speakers, (so just because I have Google Home speakers and Google Nest speakers in every room does not mean that the scenario in the example could be solved by simply allowing playback to all speakers instead of having them as a group).

[maximmaxim345]

I don't think that adding multiple groups per client to the spec is required to support that use case. The server can still have multiple groups with the same group members - Music Assistant already does that with player groups added through the settings.
Just one group player is part of can be active at a time, with your example:

• you can add the resonate speaker to "the whole house" and "downstairs"
• you play something on "downstairs" -> the speaker is part of the "downstairs" resonate group
• after that you play something on the "the whole house" groups -> the speaker leaves the "downstairs" group (or the "downstairs" group is completely stopped), and joins the "the whole house" group

After that the "downstairs" is still exists! It's just not active.

One thing that the current spec limits is playing multiple songs to the same speaker at the exact same time, but I really don't see any use case for that. And low powered devices are already busy enough with a single audio stream.

[Hedda]

One thing that the current spec limits is playing multiple songs to the same speaker at the exact same time, but I really don't see any use case for that. And low powered devices are already busy enough with a single audio stream.

FYI, Google Cast does not support that either, but it supports playing different songs to two different clients at the same time.

Scenario for that is your family members each playing different different songs to different speakers or groups of speakers as long as none of then overlaps (if they do overlap then Google Cast will always override the just use the last demand that came in).

[potelux]

(if they do overlap then Google Cast will always override the just use the last demand that came in).

There is a distinction between what is logically a group of speakers to the user and what is a group in the protocol. If you are making the qualification that the playback is overridden "if they do overlap", then the player never actually belongs to two groups. If you are only ever playing one audio stream at a time, then you only ever need to belong to one group at a time.

Since these nested and overlapping groupings only exist conceptually, they belong in the UI (Music Assistant), not the protocol. And, as @maximmaxim345 mentioned, this is already supported in Music Assistant.

[ojiudezue]

Came here to say this. If the user layer does not support multi group membership this will be significantly hobbled.
Would be good if this was further clarified. Agreed it can be implemented as single group membership in the protocol and the user layer can manage 'active groups' for each player, in a way that means groups can be added to and left more flexibly but why leave it to those kinds of implementation decisions when the protocol can solve this natively?
It's not that much more handling and gives native flexibility

[Hedda]

(if they do overlap then Google Cast will always override the just use the last demand that came in).

There is a distinction between what is logically a group of speakers to the user and what is a group in the protocol. If you are making the qualification that the playback is overridden "if they do overlap", then the player never actually belongs to two groups. If you are only ever playing one audio stream at a time, then you only ever need to belong to one group at a time.

Since these nested and overlapping groupings only exist conceptually, they belong in the UI (Music Assistant), not the protocol. And, as @maximmaxim345 mentioned, this is already supported in Music Assistant.

Has it already been decided that it will be implemented that way? I got the impression based on @maximmaxim345 comment in the stereo pairs question issue that implementations could potentially be made differently in the future?

Originally posted by @maximmaxim345 in #10

Another question is if the distinction between 2 grouped players and a stereo pair should be done in the application (so Music Assistant), the server implementation (so aioresonate), or somehow be integrated in the protocol (closely related to #5)

[Jackomatrus]

I've run into the same issue while setting up a group of speakers and trying to play something on a single one of them (a functionality I would've intuitively thought possible).
Targeting a single speaker in the group seems to me to be a very slight different nuance of this issue.

Traceback (most recent call last):
  File "/app/venv/lib/python3.13/site-packages/music_assistant/controllers/players/player_controller.py", line 177, in execute
    await fn(self, *args, **kwargs)
  File "/app/venv/lib/python3.13/site-packages/music_assistant/controllers/players/player_controller.py", line 951, in select_source
    raise PlayerCommandFailed(f"Player {player.display_name} is currently grouped")
music_assistant_models.errors.PlayerCommandFailed: Player Bedroom speaker (Sendspin) is currently grouped

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/app/venv/lib/python3.13/site-packages/music_assistant/controllers/players/player_controller.py", line 187, in wrapper
    await execute()
  File "/app/venv/lib/python3.13/site-packages/music_assistant/controllers/players/player_controller.py", line 179, in execute
    raise PlayerCommandFailed(str(err)) from err
music_assistant_models.errors.PlayerCommandFailed: Player Bedroom speaker (Sendspin) is currently grouped```