mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-14 06:16:20 -06:00
f4d309a0d4
Replacing the single item of a one-item playlist did nothing. The old promo, board or clip kept playing while the dashboard showed the new playlist published and the device perfectly healthy — only a reboot or a manual refresh cleared it. #157 defers a rotation so a live item is not yanked mid-play, and applies it "on the next natural advance". For a one-item playlist there is no such thing, by design: single-item rendering deliberately never advances. A video gets `loop = (playlist.length === 1)` and so never fires `ended`; a YouTube embed loops for the same reason and skips its safety net; a solo widget is "held" on a self-re-arming refresh that never calls nextItem, because reloading it would reset a directory board's scroll. Tizen is worse still — `single` makes every renderer skip its timer, so images freeze too. Two guards, the same pair already applied to the Android controller: - A one-item playlist is never deferred. There is nothing to protect from being cut off, since nothing was going to advance anyway. - Any deferral that does happen gets a 60-second deadline. The deferral is a bet that an advance is coming; if the bet loses, the change must still land rather than strand the screen on content the operator has already replaced. Verified in headless Chrome: a one-item playlist holding a solo widget (the "held" case that never advances), its only item replaced with a different widget — the screen followed, with no reload and no restart. Before the change it stayed on the replaced item indefinitely. 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 | ||