3 commits

Author	SHA1	Message	Date
screentinker	26c059c1b8	Every build from alpha10 onward sorted below alpha8 (#270) ... A plain string compare on the prerelease tag put "alpha11" below "alpha8", because '1' < '8'. The OTA check therefore answered client-newer and refused to offer the update — while reporting the newer build as `latest` in the same response: latest_version: 1.9.34-alpha11 current_version: 1.9.34-alpha8 update_available: false reason: "client-newer" So a fleet on alpha8 or alpha9 could not be moved forward at all, silently, and nothing about the symptom pointed at version ordering. alpha10 was never really on offer either; the last update that genuinely worked was alpha6 -> alpha8, where the lexical order happens to be right by luck. This is what semver specifies for a single alphanumeric identifier, and it is simply not what the naming means. lib/version-precedence.js compares digit runs NUMERICALLY, so alpha8 < alpha9 < alpha10 < alpha11, while leaving everything else alphabetical — beta still outranks alpha, rc still outranks beta, and a release still outranks any prerelease of the same core. Dot-separated identifiers are compared per semver and a shorter run loses, so moving the naming to the semver-correct `-alpha.11` form later needs no further change here. TWO comparators carried the assumption, each with a comment asserting lexical was fine "for our naming" — true only while the counter stayed below 10. Both now use the shared helper rather than a third copy drifting into the same trap: - lib/ota-breaker.js the Android OTA path - lib/brightsign-update.js the BrightSign host package, where a wrong-way comparison replaces the script that boots the player lib/ghcr-check.js was checked and is unaffected: it rejects prerelease strings outright rather than ordering them. Tests pin the exact stranding case end to end — decide('1.9.34-alpha8', '1.9.34-alpha11') must be an offer, not client-newer — plus the reverse direction, so a future change cannot merely invert it. 1668/1668 pass.	2026-08-13 20:20:17 -05:00
ScreenTinker	df3a2879fa	Remote screenshots use the framebuffer, and an opted-in tester can move forward ... Two things reviewed against the hardware. REMOTE CAPTURE. An in-page canvas cannot read the hardware plane, so a screenshot from a BrightSign is a composite with the video missing. The player now asks the HOST, which uses the unit's own Diagnostic Web Server to capture the real framebuffer, video included. It has to run in BrightScript rather than the page for two reasons: the DWS is http on localhost while the player is served over https, so the page would be blocked as mixed content; and BrightScript is subject to neither CORS nor mixed-content rules. Credentials are the documented default — user "admin", password = the unit serial — which the host reads directly. It requires PRIMARY STORAGE: the endpoint writes the full-size capture to disk before returning a thumbnail, so a unit with no card or SSD answers "No primary storage found." That message is passed through verbatim rather than swallowed, and the canvas path still runs as a fallback, so a player with no disk keeps producing the partial screenshot it can rather than nothing at all. Verified against the real unit: the endpoint is reachable and blocked solely on storage. THE STUCK TESTER. An opted-in player on 1.9.29-rc1 was told "holding prerelease of the same core" when offered rc3 — so it would never move forward through rc1 -> rc2 -> rc3, which is the opposite of what opting in is for, and would have stopped our own XT245 ever receiving the next candidate. The hold rule exists to stop a test build being dragged BACK to its release. It now applies only when the advertised version IS that release: a newer prerelease of the same core is offered normally, the release still cannot claw a tester back, a newer core still lands, and a player that never opted in is still refused a prerelease. Also verified end to end on alpha: the advertised sha256 matches the served bytes exactly, size matches, and every member of the package is stored. 1063 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-05 12:33:34 -05:00
ScreenTinker	8fd6eb75d5	BrightSign: cache content for offline, and let the package update itself ... Two gaps that both end the same way — a panel nobody can fix without a van. OFFLINE. Content bytes were never persistently cached. The service worker skipped /uploads/content/ and leaned on the browser's HTTP cache, which is reasonable on a desktop and is not a documented-persistent store here: BrightSign guarantees survival across reboots for IndexedDB, localStorage and SQLite, and their own answer for offline video is to cache the bytes explicitly. A panel could come back from a power cut with its playlist intact — that lives in localStorage — and no media to play it with. The reason content was skipped is real, and player-cache-policy.js is what makes intercepting it safe. Seeking video issues range requests, and naive caching is worse than none: storing a 206 as the whole file means every later full request gets a fragment, and answering a range request with a 200 makes some media stacks fail outright. So only complete 200s are stored, and ranges are served by slicing the stored body into a correct 206. The content cache survives shell re-versioning, or every deploy would re-download the playlist over a link that may be exactly what is broken. SELF-UPDATE. The package can replace autorun.brs, so a truncated file is a dark panel with no app underneath. The safety is the ordering: download to .part, verify sha256 AND size, then delete the .done marker, rename, reboot. Marker first is not stylistic — leaving it makes the next boot skip the archive and the update silently never happens. A failed extract parks the zip as .bad instead of retrying every boot, which would be a loop indistinguishable from a hardware fault. sha256 because that is what roMessageDigest can compute; a checksum the player cannot verify is an unverifiable package. The decision lives on the server and is unit-tested, and the host only executes it — re-implementing the version comparison in BrightScript would put the prerelease trap somewhere untestable. That trap is honoured directly: a player on 1.9.29-rc1 is running something semver-OLDER than 1.9.29, so an opted-in player HOLDS a prerelease of its own core rather than being pulled off the build it was given to test. Narrowly — a newer core still lands, so opting in never means never updating again. Both loop conditions are closed by construction. The manifest and the download come from one buffer hashed once, so a checksum cannot describe bytes we are not serving. And the version is stamped into autorun.brs at build time by both builders, so the script reports the version it actually is — otherwise the player applies the update, still reports the old version, and is offered the same package forever. Failure always degrades to "keep running the old version": an unreachable manifest, a missing checksum, a failed verification, a full attempt counter and an unbuildable package all resolve to skip. 998 tests pass (was 954).	2026-08-05 10:09:00 -05:00