3 commits

Author	SHA1	Message	Date
ScreenTinker	db8846a139	BrightSign: report what the host knows, through the channels the other players use ... A BrightSign could see things the page cannot ask for — the uptime, the wired IP, the video mode in force, which volume it booted from, whether a staged package applied — and it printed all of it to a serial console. On a panel on a wall that is the same as reporting nothing. The cost was concrete and recent. A single bad string literal stopped the host script compiling; the only evidence anywhere was one line on a cable, and from the server the display looked identical to one that had never started. Diagnosing it needed someone physically present with a serial adapter. Every other player reports its own failures. Three hops, each thin: the host posts, the bridge carries, the player emits on the channels it already uses (device:log, device:event, and the telemetry the heartbeat has carried for releases). The pre-widget phase is the part that matters and the part that was hardest to reach — the storage probe, a pending package being applied, the video mode being set, all happen before there is a page to talk to. Those lines accumulate in a buffer and flush the moment the widget exists, so the boot story arrives even though it happened before anyone could listen. BrightScript has no global store here (no GetGlobalAA), so the buffer is threaded explicitly; losing the boot entirely was the worse option. Two things become incidents rather than console lines: the watchdog rebuilding a wedged widget, which is the most important thing a player does unattended and previously healed in silence — a panel rebuilding itself every two minutes looked exactly like a healthy one — and a load-error, which now names the resource that failed. Both use event types the server actually accepts; an invented one is dropped silently and would have been just as invisible. Host telemetry merges into the existing snapshot rather than opening a channel, and the host's numbers win where they overlap: navigator.storage.estimate() describes the widget's cache quota, not the disk, so a panel can report gigabytes free while the volume holding them is full. Two API traps caught in my own new code before it shipped, both the same shape as the ones being fixed: Str() applied to a value already documented as a String (it is for numbers, and would abort the event loop while reporting a diagnostic), and Stri() handed a float from an inline division. The checker now pins the first. Verified on the XT245: boots clean, plays, online. The bridge and player halves are served BY the server, so they take effect on the next deploy. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-06 00:02:33 -05:00
ScreenTinker	c2effc9f5f	BrightSign: use the platform's own file-existence idiom, and don't re-fetch a staged package ... Both found while watching a real self-update run end to end on the XT245. FileExists now uses roReadFile + type(), which is what BrightSign's own published autozip.brs does (their CheckFile). MatchFiles is for LISTING a directory; as an existence check it has already burned this codebase once, passing a full path as both arguments so it could never return true for anything. Correcting it to a directory plus a bare name did work — I misread a mid-cycle inspection as a second failure and it was not — but roReadFile takes the full path every call site naturally has, needs no reasoning about volume-root semantics, and is the form the vendor ships. The narrower idiom is worth having here precisely because nothing in CI can tell us when this is wrong. CheckPackageUpdate now returns early when a package is already staged. Observed on hardware: the periodic check fired in the gap between staging an archive and the reboot that applies it, and pulled the whole thing down a second time. Harmless on a desk; on a metered or marginal link it is exactly the waste the rest of this release exists to remove. The self-update chain is now proven on hardware, twice: check, download, sha256 and size verify, stage, reboot, staged unpack, move into place without touching screentinker.json, mark done, reboot into it. The player reports 1.9.29-rc5 and its autorun.brs carries the archive's timestamp rather than a hand-copied one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-05 23:22:09 -05:00
ScreenTinker	647a2bcc56	BrightSign: replace the Roku APIs, and a literal that stopped the script loading ... The host scripts were written against the wrong reference. BrightScript is Roku's language, the two API references read almost identically, and nothing here can run either — so a call to an object that does not exist looked exactly like a call to one that does. Verified on an XT245 and against BrightSign's published reference; every item below was confirmed, not guessed. THE ONE THAT COST A BOOT. `body$ = "{""width"":"` is not an escaped quote — BrightScript has no escape sequences, so that is three adjacent literals with no operator, and the compiler rejects the WHOLE FILE: ScriptLoadError: Syntax Error. (compile error &h02) in SSD:/autorun.brs(196) Not a broken feature — no player at all, on a display showing nothing. Built with Chr(34) now. THE ONE IN THE FIELD. MatchFiles takes a DIRECTORY plus a pattern and returns nothing when the pattern contains a separator; we passed a full path as both arguments. FileExists() could never return true, for any file, on any player. That is exactly what a consultant hit: "[st-autozip] no autorun.zip on any volume" printed while `dir SD:` listed autorun.zip. It also silently disabled the entire self-update path. (Related: `autorun.zip_invalid` on his card is not an accusation — it is the rename BrightSign's own example performs AFTER a successful unpack. Our STORED-only insistence fixed a problem that was never there; deflate32 is supported.) Roku objects that do not exist here, each of which disabled a feature quietly: roFileSystem (~20 sites — the update path could never mark a package applied), roMessageDigest (verification returned false unconditionally and burned an attempt counter), PostFromStringWithRetry (a snapshot request raised "member function not found" from inside the event loop and took the player down). Replaced with MoveFile/DeleteFile, roHashGenerator, and an async POST on a message port, which is the only documented way to read a POST body. Unpack() returns Void, so `if not package.Unpack(...)` was a type error dressed as an error check; success is now proven by looking for the extracted file. And Unpack() DELETES everything already in its target — unpacking an update to the volume root would have erased the player's provisioning and its whole content pool as a side effect of a routine upgrade. It stages to a directory of its own and moves files into place, deliberately never overwriting screentinker.json. Also: SetMode() takes one argument (rotation belongs to SetScreenModes, which REBOOTS, so it only fires on a real change); GetStorageStatus is unreliable with "USBn:"; a load-error names its resource in `uri`, not `url`. server/test/brightscript-api-surface.test.js is the cheap thing that would have caught all of it: a deny-list of Roku APIs plus the argument shapes and literal forms that compile and then do nothing. It cannot prove the scripts are right; it stops these specific mistakes coming back. It has already earned its keep — it caught a comment I had broken while writing this change. Verified on hardware: the player loads clean from the NVMe, restores its cached playlist and plays BEFORE the server connects, fetches media with the new ?rev= revision, and registers against alpha rc4. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-05 22:57:36 -05:00