Native Bluesound Draft PR #1604
Conversation
| return ( | ||
| ConfigEntry( | ||
| key=CONF_IP_ADDRESS, | ||
| type=ConfigEntryType.STRING, | ||
| label="IP-Address (or hostname) of the BluOS device.", | ||
| required=True, | ||
| ), | ||
| ConfigEntry( | ||
| key=CONF_PORT, | ||
| type=ConfigEntryType.STRING, | ||
| default_value="11000", | ||
| label="Port to use to connect to the BluOS device (default is 11000).", | ||
| required=True, | ||
| category="advanced", | ||
| ), | ||
| ) |
There was a problem hiding this comment.
this must be left out - you are using mdns to discover players
| """ | ||
| DEMO/TEMPLATE Player Provider for Music Assistant. | ||
|
|
||
| This is an empty player provider with no actual implementation. | ||
| Its meant to get started developing a new player provider for Music Assistant. | ||
|
|
||
| Use it as a reference to discover what methods exists and what they should return. | ||
| Also it is good to look at existing player providers to get a better understanding, | ||
| due to the fact that providers may be flexible and support different features and/or | ||
| ways to discover players on the network. | ||
|
|
||
| In general, the actual device communication should reside in a separate library. | ||
| You can then reference your library in the manifest in the requirements section, | ||
| which is a list of (versioned!) python modules (pip syntax) that should be installed | ||
| when the provider is selected by the user. | ||
|
|
||
| To add a new player provider to Music Assistant, you need to create a new folder | ||
| in the providers folder with the name of your provider (e.g. 'my_player_provider'). | ||
| In that folder you should create (at least) a __init__.py file and a manifest.json file. | ||
|
|
||
| Optional is an icon.svg file that will be used as the icon for the provider in the UI, | ||
| but we also support that you specify a material design icon in the manifest.json file. | ||
|
|
||
| IMPORTANT NOTE: | ||
| We strongly recommend developing on either MacOS or Linux and start your development | ||
| environment by running the setup.sh scripts in the scripts folder of the repository. | ||
| This will create a virtual environment and install all dependencies needed for development. | ||
| See also our general DEVELOPMENT.md guide in the repository for more information. | ||
|
|
||
| """ |
There was a problem hiding this comment.
please fix all the docstring
| self.logger = prov.logger.getChild(player_id) | ||
| self.connected: bool = True | ||
| self.client = BluosPlayer(self.ip_address, self.port, self.mass.http_session) | ||
| self.sync_status = self.client.sync_status() |
There was a problem hiding this comment.
is this free of IO ? So async friendly ?
| async def update_attributes(self) -> None: | ||
| """Update the player attributes.""" | ||
| # self.logger.debug("checking master") | ||
| sync_status_result = await self.client.sync_status() |
There was a problem hiding this comment.
So BluPy is written in a rather strange manner, for each player .sync_status() returns information on connected speakers, whether it is grouped. .status() checks more basal info regarding what is being played etc. There however is not much documentation on what the keys inside sync_status return exactly hence I read the entire variable from time to time. This is what I'm working with: https://github.com/LouisChrist/pyblu/blob/main/src/pyblu/entities.py
Strange parts are for example that there is no clear "This player is the master player (when not working with zones)" rather I have to deduct whether a player is the master based on If it could have any followers and does not have a master itself...
| @@ -251,6 +251,7 @@ class PlayerState(StrEnum): | |||
| IDLE = "idle" | |||
| PAUSED = "paused" | |||
| PLAYING = "playing" | |||
| CONNECTING = "connecting" | |||
There was a problem hiding this comment.
Let's not do this - instead map it to one of the existing states please
There was a problem hiding this comment.
make sure to add a final logo at some point
scripts/run-in-env.sh
Outdated
There was a problem hiding this comment.
let's not make unrelated changes in this PR - create a new PR for that (maybe combine it with the devcontainer improvements?)
No description provided.