mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-14 14:23:14 -06:00
b9bd83c48f
A BrightSign XT245 on shipped 1.9.32 went dark and STAYED dark. The exit beacon: crashed: Cannot access '_videoCompositingOk' before initialization @ player:3730:12 Boot restores the CACHED playlist and renders item 0 immediately, from a call site ~2300 lines above where `_videoCompositingOk` was declared. When that item was a video carrying a transition, `isVideoBufferable` read the binding while it was still in the temporal dead zone. A TDZ read is a THROW, not a `null`, so the player died during boot. The nasty part is the loop. The offending playlist came from the device's own localStorage cache, so the player never stayed up long enough to receive a corrected one -- every boot re-read the same poisoned cache and died the same way. Rebooting the player, the one remedy an operator has, did nothing. Recovery took editing the served player; nothing reachable from the dashboard would have helped. Fixed by declaring the cache in State, above Boot, where no call path can reach it early. Left a comment at the old site saying why it must not move back -- next to its function is exactly where it looks like it belongs. Not BrightSign-specific: any web-based player could hit it. Prod is not currently triggering it -- the one exposed playlist starts on an image, and the video check short-circuits before the read -- but that is luck, not safety. Reordering that playlist, or a daypart making a video the first active item at boot, arms it for those displays. Found while testing hwz routing for video transitions; the crash is unrelated to that work and reproduced on the unmodified released file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014skWYXJUWhF73EvNPgB2AS |
||
|---|---|---|
| .. | ||
| debug-overlay.js | ||
| index.html | ||
| sw.js | ||