Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add metadata support to Snapcast media players #117372

Open
wants to merge 8 commits into
base: dev
Choose a base branch
from

Conversation

mill1000
Copy link
Contributor

@mill1000 mill1000 commented May 13, 2024

Proposed change

Add metadata support to Snapcast media players.

Snapcast streams can contain metadata provided via a stream plugin or natively.

Snapcast includes support for the following sources:

  • Librespot via stream plugin
  • Mopidy via stream plugin
  • MPD via stream plugin
  • Airplay natively

Additionally I have developed a stream plugin for UPnP renderers: https://github.com/mill1000/snapcast-upnp

Example Screenshots
UPnP Stream Plugin
image

Airplay Native
image

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Deprecation (breaking change to happen in the future)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

  • This PR fixes or closes issue: fixes # N/A
  • This PR is related to issue: N/A
  • Link to documentation pull request: N/A

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • I have followed the perfect PR recommendations
  • The code has been formatted using Ruff (ruff format homeassistant tests)
  • Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • [N/A] The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • [N/A ] New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • [N/A ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
  • [N/A ] Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

@home-assistant
Copy link

Hey there @luar123, mind taking a look at this pull request as it has been labeled with an integration (snapcast) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of snapcast can trigger bot actions by commenting:

  • @home-assistant close Closes the pull request.
  • @home-assistant rename Awesome new title Renames the pull request.
  • @home-assistant reopen Reopen the pull request.
  • @home-assistant unassign snapcast Removes the current integration label and assignees on the pull request, add the integration domain after the command.
  • @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
  • @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

@mill1000 mill1000 marked this pull request as ready for review May 14, 2024 13:48
@mill1000 mill1000 marked this pull request as draft May 14, 2024 13:54
@mill1000 mill1000 marked this pull request as ready for review May 14, 2024 14:26
@luar123
Copy link
Contributor

luar123 commented May 14, 2024

That looks like a nice addition, thanks!
I will review and test it, but might take some time.

Copy link
Contributor

@luar123 luar123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added a few small comments, nothing critical. In general it would be much easier to review if you would split it in two PRs: one for the refactor and one for metadata support. Metadata support could be simplified by adding metadata properties to the python-snapcast client/group classes first but I think your solution is fine.

self._entry_id = entry_id
self._attr_unique_id = f"{GROUP_PREFIX}{uid_part}_{self._group.identifier}"
self._attr_media_content_type = MediaType.MUSIC
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not hard-code this. Snapcast could be anything, not only music.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand where you're coming from as the stream could be a broadcast, notification, etc,

But
A. MediaType.MUSIC is required for artist and album metadata to be parsed.
B. Snapcast doesn't currently provide a means to specify this.

Of the available MediaType, MUSIC and PODCAST might be the only relevant types.

class MediaType(StrEnum):
    """Media type for media player entities."""

    ALBUM = "album"
    APP = "app"
    APPS = "apps"
    ARTIST = "artist"
    CHANNEL = "channel"
    CHANNELS = "channels"
    COMPOSER = "composer"
    CONTRIBUTING_ARTIST = "contributing_artist"
    EPISODE = "episode"
    GAME = "game"
    GENRE = "genre"
    IMAGE = "image"
    MOVIE = "movie"
    MUSIC = "music"
    PLAYLIST = "playlist"
    PODCAST = "podcast"
    SEASON = "season"
    TRACK = "track"
    TVSHOW = "tvshow"
    URL = "url"
    VIDEO = "video"

We could attempt to deduce the type by checking the metadata. If an album or artist property is present set the type to MUSIC otherwise leave it empty.

self._entry_id = entry_id
self._attr_unique_id = f"{GROUP_PREFIX}{uid_part}_{self._group.identifier}"
self._attr_media_content_type = MediaType.MUSIC
self._attr_device_class = MediaPlayerDeviceClass.SPEAKER
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not hard-code this. Snapcast clients could also run on a TV/kodi. And for groups it does not apply, does it? (badaix/snapcast#956)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I went with speaker because even if running on a TV Snapcast can still only play audio.

Since that issue has not been addressed and no client type information is passed back to the server, what would you recommend? Leave it unset?

homeassistant/components/snapcast/media_player.py Outdated Show resolved Hide resolved
homeassistant/components/snapcast/media_player.py Outdated Show resolved Hide resolved
@mill1000
Copy link
Contributor Author

Thanks for taking time to review. I'll check out the comments.

I have added a few small comments, nothing critical. In general it would be much easier to review if you would split it in two PRs: one for the refactor and one for metadata support. Metadata support could be simplified by adding metadata properties to the python-snapcast client/group classes first but I think your solution is fine.

If you want me to split the PR in two that's no problem.

I am also working on another change to implement the grouping in line with this architecture discussion. It adds the media player grouping services and attributes. That PR would make the refactor here redundant as it eliminates the Group entities all together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants