3 commits

Author	SHA1	Message	Date
screentinker	9a1a82a100	Run the ScreenTinker server on the player it serves (#288) ... * Make a BrightSign say what it is running, and what it is plugged into A panel on a wall could not answer three questions an operator asks first: which version am I, which page am I running, and which screen is that. All three had answers already travelling over the socket; nothing was reading them. VERSION. device_info.app_version was the literal '1.1.0-web' for every web player, BrightSign included — the same string as PLAYER_VERSION, which already travels separately as client_version. So the column carried no information at all: a panel provisioned this morning and one running a year-old host reported identically. app_version is now the ON-DEVICE host package, the artifact OTA replaces and the only one here that can be stale, and PLAYER_VERSION is stamped at serve time from VERSION rather than being a constant nobody bumped for the whole 1.x line. No '-web' suffix: client_version is only compared for equality today, but X.Y.Z-web is a semver PRERELEASE that sorts BELOW X.Y.Z, and this project has been bitten by exactly that before. The host version arrives asynchronously and can land after the page registers, so register sends what it has and the heartbeat corrects the record — which also catches the version changing under a live page, which is what a self-update is. THE CARD SHOWED FOR NOBODY. The Info tab's version card sat inside the block gated on android_version && !startsWith('Web/'). A BrightSign registers as "Web/<ua>", so the panel that most needed a version never displayed one. THE PAD THAT COULD NOT BE CLICKED. System View was gated on tier === 2. tier is an Android device-owner concept, NOT NULL DEFAULT 0, written only by the APK — so a BrightSign or Tizen panel sat at 0 forever and rendered HOME, BACK, POWER, the D-pad and OK permanently pointer-events:none, for keys those players genuinely handle. Greying an Android gate over a working control is the "button that cannot work" the capability system exists to prevent, inverted. Only Recents (KEYCODE_APP_SWITCH) and Settings are truly Android-only; those are now the only things hidden. THE PACKAGE POINTED AT THE WRONG SERVER. autorun.zip carried the committed default, so a player self-updating from alpha or a self-hosted box was handed a config pointing at screentinker.com — which surfaces as a pairing bug, miles from the packaging code that caused it. It is now stamped with the URL it was fetched from. The bytes therefore vary per origin, so the cache is keyed by origin and BOTH routes derive it identically: the manifest checksum and the served bytes must come from one buffer or every player downloads, fails verification and retries forever. EDID. getEdidIdentity() answers seven questions and cannot answer any others — manufacturer, EDID version, physical size, gamma and the mode lists exist only in the raw block, which getEdid() returns as 2048 bytes. The player ships those on the register (identity, not a reading: it changes when someone swaps the screen) and the SERVER parses them. That split is the point: a new field becomes a server deploy instead of a bridge update behind a 4h CDN plus an OTA for the host. Verified against real hardware — an XT245 with a CX101 decodes to RTK / 0x1010 / serial 1 / 2020w26 / 22x13cm, preferred 1920x1200@62, matching the player's own DWS field for field. The odd-looking 62 is right: 168.5MHz over 2200 x 1245 is 61.5Hz, and rounding it to a nicer 60 would contradict the panel. Also corrects two comments that had outgrown their reasoning: the BrightSign capability baseline still explained its exclusions with "a canvas cannot read the video plane", which native capture made obsolete, and player-parity.md claimed the bridge is "always current" when a zone-wide Cloudflare Browser Cache TTL had been rewriting its no-cache to max-age=14400 for months. Every new guard is mutation-tested — the fix was reverted in the source and each test confirmed to fail. 1676 -> 1714 tests, all green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014kfhrUPit5MCqxeTQyqr56 * Run the ScreenTinker server on the player it serves A BrightSign XT245 now downloads, installs and runs the server itself, with the display showing what it is doing until it is up. WHY IT NEEDED A NEW SHAPE BrightSignOS cannot open a large autorun.zip. The 73MB build failed at boot with "ZipArchive error at line 91", and the OS renamed it autorun.zip_invalid - which is how a device that had already unpacked once came back up with no autorun at all. The identical package cut to 32KB and five files boots fine; paths (182 chars) and depth (8) are unremarkable, so the limit is in the boot-time reader, not the archive. BrightSign's own notes acknowledge package size as a problem and point at webpack; that route needs the dynamic requires in scripts/ removed first, so instead autorun.zip carries only what starts the process and the payload arrives over HTTP into a Node that has no such limit. The payload can also be updated without re-provisioning the device. WHY roNodeJs AND NOT THE WIDGET The first version ran the server inside an roHtmlWidget with nodejs_enabled. That is a Node context inside an Electron renderer, and it is not Node. Four separate boot failures came out of it, each invisible to a local test because a local test runs on real Node: - shebangs are not stripped, so any `#!/usr/bin/env node` file dies with "Failed to construct 'ContextifyScript': Invalid or unexpected token". Note it names no token - "#" is not one. An ESM file compiled as CJS says "Unexpected token 'export'" instead, which is how the two are told apart. - require() of an ESM-only package is unsupported, which plain Node 24 handles. uuid 14 is ESM-only and 21 files import it. - setInterval is the DOM's and returns a NUMBER, so setInterval(...).unref() throws. Two call sites were unguarded; sixteen more were written defensively and had been silently not unreffing. - worker_threads cannot create a thread at all. BrightSign's dev-cookbook is explicit: roNodeJs "for long running processes like ... running a web server", roHtmlWidget "for browser-based apps". Their cra-template examples do exactly this - server in roNodeJs, widget pointed at localhost. It also fixes the lifecycle problem that was the original argument against a server on this hardware: in a widget the server dies with the page, taking an open SQLite WAL with it. The shims for the first three are kept in the packager for now rather than removed in the same change that moves the container, so that if something breaks it is the move and not four simultaneous removals. CHANGES THAT ARE NOT BRIGHTSIGN-SPECIFIC db/database.js, routes/status.js fs.copyFileSync does not merely copy bytes: it fchmods the destination to match the source. exFAT has no permission bits, so the pre-migration snapshot failed with EPERM and the failure path called process.exit(1) - which inside a widget also killed the page, leaving a black screen and no diagnostic. The guard was right; the copy was wrong. lib/fsutil.js copies without touching mode. db/wal-checkpointer.js the module already degraded correctly when its worker died or could not be respawned, but the FIRST spawn was not wrapped, so a host that cannot make threads lost the whole server rather than falling back to inline autocheckpoint. db/sqlite-compat.js a better-sqlite3 facade over node:sqlite. With it the bundle contains no native code at all, which is what lets an x86_64 laptop build a package for an aarch64 player. 1719/1719 tests pass on Node 24 through this shim. The packager refuses to build if a source file is untracked (git ls-files decides what ships, and lib/fsutil.js reached a player without shipping alongside the code that required it), if any .node binary is present, if a shebang survives, or if a database, upload, cert or .env is staged - the first build of this package swept up a real 33MB database and 105MB of uploads. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014kfhrUPit5MCqxeTQyqr56 --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Dan Walters <dan.walters@bytetinker.net>	2026-08-18 15:16:09 -05:00
ScreenTinker	4e1de8ec0e	Make the Tizen and BrightSign players do what they say they do ... Both players carried calls that compile, read correctly, and are documented to do something else. Verified line by line against docs.brightsign.biz and Samsung's Smart TV Filesystem reference; every fix below cites the doc that proves it, and the linter has been extended so each one fails here next time. TIZEN The offline media cache could never have worked on a panel. Its adapter used the deprecated Filesystem API in three ways the IDL rules out: `tizen.filesystem.resolve()` is declared `void`, so `var dir = resolve(...)` was always undefined and MediaCache.create() returned null on every panel in the fleet; `openStream()` is asynchronous, so appendPart read `written` before any callback could run and returned 0 forever; and `moveTo()` is asynchronous, belongs on the parent directory, and takes (origin, destination) — it was called on a file handle with the arguments transposed. Rewritten against the 5.0 synchronous FileSystemManager, which is genuinely synchronous and is what the decision layer needs. A Tizen 4.0 panel now reports available() false instead of being handed a cache that silently writes nothing. Writes are now POSITIONED rather than appended at EOF. Power cut between a write and the index save — the exact event this feature exists for — replayed the last chunk, and an append landed it twice: a silently corrupt video that promoted as complete. A positioned write makes the replay idempotent. Three decision-layer bugs alongside it: a 206 with no readable Content-Range fell back to Content-Length, which is the CHUNK length, so the first megabyte of a 50MB video promoted as a complete 1MB asset; a 200 whose body was short of its own Content-Length returned 'done'; and a server with no ETag or Last-Modified was re-fetched from zero on every sweep, forever, on precisely the marginal link this feature exists to be gentle on. The volume slider was dead. The dashboard sends `{level: 0..1}`; this handler read `value`/`volume` as a 0..100 percentage, so it matched nothing and logged "no usable value in payload" on every slider move while the panel declared audio.volume as working. Both halves had to move together — taking `level` as a percentage turns 50% into 0.5%, which is inaudible and looks like a fix. Verified by driving the real handler in headless Chrome, before and after. BRIGHTSIGN FindMemberFunction is documented as available only when roDeviceInfo.HasFeature("FindMemberFunction") is true. It was called unguarded from the capability probe and from host telemetry — both on the event loop — so a player without the feature would have died within a minute of boot and taken the display with it. The guard needed guarding. The boot report never arrived. The host flushed its buffer straight after Show(), before the page had been fetched, while the player correctly waits for its socket before subscribing. Between two correct decisions every boot line fell on the floor. The host now waits for the page's `probe`, and the bridge buffers until a consumer registers. offline.cache was claimed on `navigator.serviceWorker` being present. It is present on a BrightSign widget and will not run a worker — our XT245 passes the check and never fetches sw.js. Now requires a controller, matching the web player. Removed from the brightsign baseline for the same reason. display.resolution was claimed on @brightsign/videooutput, which has no setMode at all; mode setting lives on @brightsign/videomodeconfiguration. roStorageHotplug.GetStorages() answers "USB1:/" while GetStorageStatus() is documented as unreliable for "USBn:" — feeding one to the other re-created the bug the static fallback list exists to avoid, and only on the OS versions that have the enumerator. dual/clone output mode put two full-screen widgets on output ONE, on top of each other, while output two stayed dark: roHtmlWidget has no output selector, and a second output is addressed by its display_x/display_y within the SetScreenModes canvas. Now positioned properly, or refused with a reason. Also: a manifest missing sha256/size passed `invalid` into typed parameters, a runtime error at the call the comment already described and did not prevent; storage_quota was a string where the docs say use a double; and the comment crediting brightsign_js_objects_enabled with gating require("@brightsign/*") named the wrong flag — it is nodejs_enabled. TESTS The two suites that mattered most were the ones that passed while the code was broken, because they asserted on source text or against a fake more correct than the platform. The host-diagnostics regexes now execute the bridge; the media-cache suite now drives the shipped adapter against a fake tizen.filesystem written from Samsung's IDL. Ten new rules in the BrightScript linter, each verified to fail against the source it was written to reject. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-06 10:51:15 -05:00
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