Fix squeezelite power control

[allmazz]

What does this implement/fix?

Fixed power attribute update in the squeezelite player provider.
Added "squeezeplay" to PLAYER_DEVICE_TYPES to enable support for GPIO/script power control that squeezelite provides.

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
• Maintenance / chore — maintenance
• CI / workflow change — ci
• Dependencies bump — dependencies

Checklist

• The code change is tested and works locally.
• pre-commit run --all-files passes.
• 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.
• I have read and complied with the project's AI Policy for any AI-assisted contributions.
• I have raised a PR against the documentation repository targeting the main or beta branch as appropriate.

[allmazz]

A few concerns about this player provider:

• Shouldn't it be named "slimproto" instead of squeezelite?
• Why players are classified as PlayerType.PLAYER or PlayerType.PROTOCOL? Is it make sense since software players can provide power control too?

[allmazz]

will rename the list and/or update comment on L70 after #4829 (comment) is answered

[marcelveldt]

this is a software player so it does not belong in this list

[marcelveldt]

• Shouldn't it be named "slimproto" instead of squeezelite?

It was named this way previously but nobody understands what that means. We focus on software based (squeezelite) implementations so we named it that way accordingly.

• Why players are classified as PlayerType.PLAYER or PlayerType.PROTOCOL? Is it make sense since software players can provide power control too?

Software players can also run other protocols (e.g. airplay on picoreplayer) so those should be marked as protocol only and we only use the player type for actual hardware players here.

Is it make sense since software players can provide power control too?

We don't support power control for protocols at all and there is also no need. On squeezelite, we send a power ON when the stream starts and OFF when the stream stops.

[allmazz]

• Shouldn't it be named "slimproto" instead of squeezelite?

It was named this way previously but nobody understands what that means. We focus on software based (squeezelite) implementations so we named it that way accordingly.

• Why players are classified as PlayerType.PLAYER or PlayerType.PROTOCOL? Is it make sense since software players can provide power control too?

Software players can also run other protocols (e.g. airplay on picoreplayer) so those should be marked as protocol only and we only use the player type for actual hardware players here.

Is it make sense since software players can provide power control too?

We don't support power control for protocols at all and there is also no need. On squeezelite, we send a power ON when the stream starts and OFF when the stream stops.

Should player be considered as PROTOCOL if it exposes only one protocol and has exactly one way to control the player(i.e. standalone squeezelite)?

We don't support power control for protocols at all and there is also no need.

Why not if player supports it and user want to?

[marcelveldt]

Should player be considered as PROTOCOL if it exposes only one protocol and has exactly one way to control the player(i.e. standalone squeezelite)?

There is no way to define that. The only reliable way is hardware devices.

Why not if player supports it and user want to?

It is already supported today. We "power on" the protocol on playback start and off on playback stop.
Nothing special needed.

If you really want a power control to show up, assign a fake power control to the player but there should be no difference.

[allmazz]

If you really want a power control to show up, assign a fake power control to the player but there should be no difference.

There is though. I need to have ability to power on the player before playback started, or turn off later without hidden magic

[marcelveldt]

Ah ok now I understand the usecase. Let me think about it how to fix this properly. I'm assuming you have some sort of relay attached to the squeezelite power control?

[allmazz]

Ah ok now I understand the usecase. Let me think about it how to fix this properly. I'm assuming you have some sort of relay attached to the squeezelite power control?

Right! I think we can add POWER feature independently of player type(protocol/hardware) if protocol supports it.
Instead, we can set default power control based on player type: protocol=None, hardware=Native(if supported). This will make power control more flexible without breaking the UX.

If you're OK with it, I'm up to implement it.

[marcelveldt]

Well, supporting power control on a protocol is VERY difficult as that is not how we designed the protocols support.
When we tried to implement it, we ran into weird edge cases with multiple protocols and how to decide who wins.
So that is when I decided to simplify it and simple never allow power control on a protocol and fixed the cast implementation to not need a power control anymore to start/stop the cast app. I kind of forgot about the squeezelite implementation where you can have a something wired up to the slimproto power.

So far the only device I have seen in the wild that supports squeezelite as protocol is a WiiM device.
In all other cases, it would be fine to have squeezelite based players just be the native player themselves.
For the PiCorePlayer case, which can also have airplay as secondary protocol, AirPlay would just become an automatically linked subprotocol of the squeezelite player.

Let me run some tests if we can safely detect if a player is a WiiM device and then flip the whole logic:
A squeezelite player is just a PlayerType.PLAYER unless it is in the exceptions list, instead of the other way around.

[allmazz]

Well, supporting power control on a protocol is VERY difficult as that is not how we designed the protocols support. When we tried to implement it, we ran into weird edge cases with multiple protocols and how to decide who wins. So that is when I decided to simplify it and simple never allow power control on a protocol and fixed the cast implementation to not need a power control anymore to start/stop the cast app. I kind of forgot about the squeezelite implementation where you can have a something wired up to the slimproto power.

So far the only device I have seen in the wild that supports squeezelite as protocol is a WiiM device. In all other cases, it would be fine to have squeezelite based players just be the native player themselves. For the PiCorePlayer case, which can also have airplay as secondary protocol, AirPlay would just become an automatically linked subprotocol of the squeezelite player.

Let me run some tests if we can safely detect if a player is a WiiM device and then flip the whole logic: A squeezelite player is just a PlayerType.PLAYER unless it is in the exceptions list, instead of the other way around.

Okay, thanks. Waiting for updates from you.