[RFC] Publish multiple active media sessions to separate MQTT topics

[qweritos]

Android may have several MediaSessions active at once. Currently the app selects one current session and publishes only its state.

I propose keeping the existing topics unchanged for backward compatibility:

mediaSession/{deviceId}/playbackState
mediaSession/{deviceId}/playbackPosition
...

They would continue to represent the currently selected session.

Each active session could additionally be published under:

mediaSession/{deviceId}/sessions/{sessionId}/applicationId
mediaSession/{deviceId}/sessions/{sessionId}/playbackState
mediaSession/{deviceId}/sessions/{sessionId}/playbackPosition
mediaSession/{deviceId}/sessions/{sessionId}/mediaTitle
mediaSession/{deviceId}/sessions/{sessionId}/mediaDuration
mediaSession/{deviceId}/sessions/{sessionId}/mediaArtwork

sessionId could be assigned when a new MediaSession.Token is detected and remain stable while that session exists. This also supports multiple sessions created by the same application.

An additional retained topic could list active sessions:

mediaSession/{deviceId}/sessions/active

When a session disappears, its retained topics should be removed. The existing Home Assistant entities could remain unchanged.

[cbeyls]

What is the main use case for tracking multiple sessions at the same time? Which problem does it solve?

Is it about picture-in-picture mode, or the fact that you want to be able to pause the active session and resume a different one using the controller function that you proposed to add?

One problem I can think of is that the only unique identifier of a session is its Token, but Token is an opaque identifier (the id it uses is private and not exposed in the API). A Token can be used as an in-memory key but cannot be persisted or transformed to a value like a String in a stable manner. This means that once the algorithm restarts from scratch, either because of a connectivity loss, a configuration change or a manual app restart, the previous sessions will not be able to be matched with previously created topics and new topics will be created even if topics already exist for the same sessions.

This also means that stale topics must be cleaned at some point. I don't think there is a way to delete a topic in KMQTT, and even if there was, the app would need to persist them after they are created so they can be deleted during the next startup (or when a session ends). This adds a lot of complexity and I'm not sure it solves any big problem.