Based on empirical observation, it seems that the websocket that liveview relies on gets killed when the phone is locked.
Since the mediaSessions API is recent, we might choose to resolve this problem by finding a way to work around this killing of websocket.
The current pattern is that play-pause events are to be captured by the AudioPlayer hook and then emitted to the MediaBridge server livecomponent which handles similarly to a user event. This breaks down in the case where a user locks their phone and the websocket is dead / inactive in the background.
A pedestrian solution would be to @ heartbeats, let there be a listener module which handles:
listening and log-stream creation
possible: teardown of a hook -- save last known states to localStorage and re-init when user's screen is unlocked again. This could be part of an overall push for better network-robustness as well.
putting this as low priority for now and high lift
Present Context
Based on empirical observation, it seems that the websocket that liveview relies on gets killed when the phone is locked.
Since the mediaSessions API is recent, we might choose to resolve this problem by finding a way to work around this killing of websocket.
The current pattern is that play-pause events are to be captured by the AudioPlayer hook and then emitted to the MediaBridge server livecomponent which handles similarly to a user event. This breaks down in the case where a user locks their phone and the websocket is dead / inactive in the background.
A pedestrian solution would be to @ heartbeats, let there be a listener module which handles:
putting this as low priority for now and high lift