From 082930cd32108a0b7348e44eaf8045f577510539 Mon Sep 17 00:00:00 2001 From: Tobias Gesellchen Date: Sat, 5 Sep 2026 21:01:28 +0200 Subject: [PATCH] docs(player): note that the speaker socket opens lazily The readback early-stop keys on `webSocketConnected`, which is the service's socket to the speaker and is opened on first fetch or control of a device rather than at discovery. Worth a line where the flag is already referenced, since it makes the first click after loading a device behave differently from later ones. Co-Authored-By: Claude Opus 5 (1M context) --- docs/content/docs/reference/PLAYER-SOURCE-BEHAVIOUR.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/content/docs/reference/PLAYER-SOURCE-BEHAVIOUR.md b/docs/content/docs/reference/PLAYER-SOURCE-BEHAVIOUR.md index a4aa7818..97e603f4 100644 --- a/docs/content/docs/reference/PLAYER-SOURCE-BEHAVIOUR.md +++ b/docs/content/docs/reference/PLAYER-SOURCE-BEHAVIOUR.md @@ -106,7 +106,10 @@ seconds later, surfacing as a transition to an error source - **Bounded readbacks** at 2s, 5s and 10s are the fallback for a speaker whose events are not arriving. They stop as soon as a confirmation arrives *and* the readback reports a live event stream, so a confirmed selection normally - costs one request rather than three. + costs one request rather than three. That signal is `webSocketConnected`, + which reports the service's own socket to the speaker; it is opened lazily + on first fetch or control of a device, so the very first click after + loading one can still take all three. - Readbacks use `GET /devices/{id}/now-playing`, which refreshes only `/now_playing`. The full device fetch runs a complete status poll: six sequential speaker calls plus `/getGroup` on a stereo-capable model, to