Treat a read as bytes, not a whole reply
mpv documents line-separated JSON messages. A local socket read is not a guarantee that exactly one complete message arrived. Keep a buffer, identify complete line boundaries and preserve an unfinished remainder for the next read.
Exercise both directions of the boundary
A developer review should include one message split across two reads and two messages received in one read. Add an unsolicited event between replies. The parser should produce complete objects without dropping the second message or decoding an incomplete fragment as a command failure.
Separate an event from a reply before changing a pending action's status. Receiving a valid JSON event does not mean the most recent user command completed. These are proposed acceptance cases, not results from a controller built for this article.
Keep failure visible and local
Define what happens with malformed input, disconnects and player exit. Preserve enough local diagnostic detail to trace the parser without publishing private paths. Framing correctness is one part of a controller; it does not change the protocol's documented insecure, local-control trust boundary.
Questions answered
Does every socket read contain one JSON message?
No. Design for partial messages and several messages in one read.
Does any valid incoming event complete my last command?
No. Handle events separately from correlated command replies.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.