Give each pending action an identity
mpv's JSON IPC supports integer request identifiers echoed in replies. A local controller should associate each pending action with its own identifier. The next received object may be an event rather than the response the user is waiting for.
Keep a request map
For an authored design example, assign 41 to a position query and 42 to a pause-related query. Store the intended operation against each number, then route each reply by its identifier. Do not infer identity from arrival order when asynchronous actions or events can intervene.
Handle an error as a result for that same pending request. If the connection is lost, mark unresolved actions as uncertain rather than assigning the next reconnect message to an old button press. No controller was implemented or tested for this article.
Bound the trust assumption
Keep this mechanism on a trusted local endpoint. Request identifiers correlate messages; they are not authentication tokens and do not make mpv's IPC a secure network protocol. Record the player version and keep pending-state logs free of unnecessary private media paths.
Questions answered
Do request identifiers authenticate the controller?
No. They correlate responses and do not add authentication or encryption.
Can I use response arrival order as the only association?
Use explicit identifiers and separate event handling, especially with asynchronous commands.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.