mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-14 06:16:20 -06:00
8f2195a6e3
A display panel usually has no keyboard and no pointer, so a recovery path that waits for input is not a recovery path. When the server stopped recognising a device, the player revealed the server-URL form — typing that cannot happen on a screen-only panel — and hid the pairing section, which was the one thing that would have rescued it. The screen then sat on "Device was removed from server" until someone physically reloaded it, even though the player was still connected to the right server and could have asked for a new code itself. Both handlers now drop the stale credentials and reconnect on a short countdown. Reconnecting re-registers with no device_id, so the server issues a fresh pairing code and the existing registered handler puts it on screen. config.serverUrl is known-good by construction — we are talking to that server at the moment we are rejected — so there is nothing for a human to re-enter. The URL field stays editable throughout, and typing cancels the countdown, so someone who does have a remote and wants to repoint the player is not yanked mid-edit. The countdown is the same helper the first-boot path already used, lifted out and shared rather than duplicated; its input listener is bound once at setup instead of per countdown, which would have stacked a listener each time. The Android player already behaved this way (ProvisioningActivity repair mode); this brings the web player in line. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL |
||
|---|---|---|
| .. | ||
| debug-overlay.js | ||
| index.html | ||
| sw.js | ||