Add lookup service for media sources

[jjlawren]

Context

While looking into how to fix the Plex media_player.play_media service usability, @balloob linked to this comment. The current service misuses the service to embed a search query as as the media identifier.

Proposal

Separate the media lookup and playback functions by creating a new media_player.media_search service. This service would accept a search query and return 1) human-readable descriptions of the media and 2) static identifiers which can be used to play the media on this source using the existing play_media service.

The linked case suggests a tree form, so perhaps a dictionary which allows for a nested structure where each leaf must be a playable media item.

Consequences

media_player integrations which provide both media sources and playback capabilities will have these functions separated, which will add another step to starting playback where the media identifier isn't already known. The number of integrations this would affect seems relatively small.

This could be a step in the direction to allow exposing a media browser in the UI.

[balloob]

I think that it's a great idea to add a new search endpoint. We would expose it via the websocket API and not a service. Would the result just be a list with identifier, name, optional picture url?

[jjlawren]

I guess it depends on how much metadata you want to be able to return. Also, a song would return very different metadata than a movie.

Maybe a separate service to obtain detailed metadata for individual items?

[balloob]

Search results are search results, I wouldn't want to make it more complicated. Just start with a title for now.

[jjlawren]

Any suggestions on a payload format? Should each search return only the current level or a partial/full tree? For example, should a search for an artist return only matching artists, or all their albums, or albums+tracks, etc? Or should a type be attributed to each node, some of which indicate that they contain more levels ("artist", "album", "season")?

[balloob]

Only show current level. Indeed differentiate between artist, album, season, episode, show, folder.

Then for each item can_play and can_expand.

[
  {
    "id": "abcdefgh",
    "title": "Lion King",
    "type": "movie",
    "can_play": true,
  },
  {
    "id": "xcvzxczcx",
    "title": "Lion King movies",
    "type": "playlist",
    "can_play": true,
    "can_expand": true
  }
]

[cgtobi]

While implementing this for Sonos I wonder if something speaks against adding the uri to the response as well. This would save extra lookup when media is to be played as the id is not directly playable nor is the uri usable as an identifier as far as I can tell.

[
  {
    "id": "abcdefgh",
    "title": "Lion King",
    "uri": "//nas/movies/lion_king.mp4",
    "type": "movie",
    "can_play": true,
  },
  {
    "id": "xcvzxczcx",
    "title": "Lion King movies",
    "type": "playlist",
    "uri": "//nas/movies/lion_king_movies.pls",
    "can_play": true,
    "can_expand": true
  }
]

[balloob]

for Sonos, type URL and ID = uri would work?

Here is the current response values we're looking at. The parent is what is returned from browse. Children is a list of items without children.

export interface MediaPlayerItem {
  title: string;
  media_content_type: string;
  media_content_id: string;
  can_play: boolean;
  can_expand: boolean;
  thumbnail?: string;
}

export interface MediaPlayerItemParent extends MediaPlayerItem {
  children: MediaPlayerItem[];
}

[frenck]

This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.

For that reason, I'm going to close this issue.

../Frenck