Add search possibility to Media Browser

[micha91]

Context

Some integrations such as Yamaha MusicCast, Kodi, Plex or Spotify could offer filter/search capabilities in the media browser. This would enable the user to search for specific items instead of browsing around for a while.

Proposal

We could add additional can_search and search_string attributes, which default to False/None, to the BrowseMedia class. If can_search is set, we could display a text field and a search button in the frontend on the top of the current view. The text field should be filled out with the value of the search_string attribute. When the user entered a search string in the frontend and hits the search button, the browse_media service should be called. This search string could be added to the browse_media service call as an additional search_string parameter. In the implementation of browse_media the search operation is applied and the BrowseMedia object is returned as usual, but with the applied search string set in the newly introduced search_string attribute.
In my opinion the search operation should always be performed using a function of the API, which is consumed by the integration, and not inside of Home Assistant.
In the UI it could look like this for directories, which set can_search to true:

[balloob]

Sounds like a good idea.

[allenporter]

Would we use something like this for filtering event types in the nest media player? A search isn't exactly ideal (compared to a filter) but it isn't the worst way this could work. This would require local filtering, going against the search via api recommendations. Here is an example now:

An alternative for this use case could be to expose additional virtual directories as event type filters

[balloob]

You can test a users query against the event types (sound, motion etc)

[OnFreund]

I missed this discussion and opened #1038.

I really think this has become even more relevant with the recent advancement in assistants.

[OnFreund]

Trying to resurrect this, I'm thinking through the backend implementation. I think search can be added to both media players and media sources (in the same way that both can support browsing).
The common interface would be a search function:

async def async_search_media(self, query: str, allowed_classes: list[MediaClass]) -> list[BrowseMediaSource]

The return value would be a list corresponding to the media classes available in the results, with the children of each BrowseMediaSource representing the actual items. In the future we can also consider adding a limit to the number of results, and an offset/page to allow retrieving additional results.

Media players would signal their support using a newly added feature flag - MediaPlayerEntityFeature.SEARCH_MEDIA.
For media sources we'll add a new MediaSourceEntityFeature type with both BROWSE_MEDIA and SEARCH_MEDIA constants.

What do you think?

[emontnemery]

I did chat with @balloob about this, we suggest to rename allowed_classes to allowed_content_types.
Also, we should consider allowing asterisks, so image/* etc.

[OnFreund]

Thanks. A few challenges I see with content types:

1. The semantics aren't clear - if the user wants to search for either albums or playlists, it will be the same content type (e.g. m3u)
2. I think most 3rd party services aren't going to have this granularity when searching, so we might see a lot of repetition where integrations convert those content types to classes.
3. I also think users would prefer marking classes (e.g. "I want either songs or albums", rather than "I want either mp3s or m3us")

[OnFreund]

I think we can take inspiration from Music Assistant here:

[balloob]

Yes, let's take inspiration from Music Assistant and use those media types.

[emontnemery]

To clarify, we should allow searching by (possibly a subset) of the MediaClass enum