5 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	bf9ad16486	The checkpointer startup line no longer describes a policy it stopped having ... It still read "escalate >16MB or 3 growing runs" after #240 added a size floor and a cooldown to that second rule. Growth-across-three-runs on its own is exactly the half that no longer holds, so the line described a checkpointer that does not exist — and it is the line an operator reads to learn the policy. During an incident it would send you hunting for a blocking checkpoint that the new gates had in fact suppressed. [wal-checkpoint] off-thread checkpointer started (PASSIVE every 15000ms; blocking TRUNCATE when the WAL exceeds 16MB, or after 3 growing runs but only at >=8MB and at most once per 300s; respawn max 5/60000ms) A test now asserts the line reports every knob that governs the decision, since nothing else keeps a log string and the rule it describes in step. Writing it caught its own bug first: anchoring the slice back to `return worker;` matched the idempotence guard at the top of startWalCheckpointer(), not the log below it, so the window was empty and every assertion passed vacuously. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014skWYXJUWhF73EvNPgB2AS	2026-08-06 22:12:01 -05:00
ScreenTinker	59489b3b20	#240: stop the morning wave buying itself a blocking checkpoint ... Bold reported loop lag that grew with uptime and reset on restart. The signature they saw — mean = p50 = p99 = max, identical to two decimals — is not a fixed cost paid on every cycle. It is what an IntervalHistogram window reports when it recorded exactly ONE delay: the mean is the raw value, and every percentile returns the bucket ceiling above it. Reproduced against their exact numbers (1329.07 / 1329.59). So the loop took one long turn that swallowed the sampling second, episodically — which is what they later confirmed independently. The turn is ours, and it is now measured rather than theorised. Probing the real worker against a real WAL with one reader mid-transaction: a single main-thread write blocked for 4,936ms behind the worker's wal_checkpoint(TRUNCATE), which then reported WAL 8.8MB -> 8.8MB. TRUNCATE is the blocking form and its locks are held ACROSS connections, so moving it to a worker kept the fsync off the loop but not the lock; and it does not throw when it cannot get those locks, it returns busy=1 having sat on SQLite's 5s busy timeout and reclaimed nothing. Five seconds of stalled loop for zero benefit, and silent. It was reached far too easily. The rule was "escalate if the WAL grew across three consecutive 15s runs" — which any sustained 45-second write burst satisfies. A customer's fleet powering on in the morning does it daily. Two gates, because either alone leaves the hole open. A size FLOOR, so a WAL in the lower half of its budget can't buy a blocking checkpoint it has nothing to reclaim from. And a COOLDOWN, because the floor alone fixes nothing for Bold — their WAL already sits at 6.2MB against a 16MB high-water, above any sane floor, so every burst would still escalate. However long the pressure lasts, our own maintenance may now stall the loop at most once per window. The high-water rule bypasses both and is untouched: a runaway WAL is the one case worth blocking for, so the "WAL cannot grow forever" invariant is exactly as strong as before. A busy TRUNCATE now says so in the log instead of reading like a success. Also softened the adjacent path: when the worker is declared unrecoverable, engageFallback() re-arms inline autocheckpoint on the main connection — a state that is STICKY for the life of the process, i.e. exactly the shape of "degrades with uptime, a restart fixes it". It used to also run an unconditional main-thread TRUNCATE on the way in; that now happens only when the WAL is genuinely over high-water, and the fallback state is served on /api/status rather than being inferable only from a log line that may have rolled. Telemetry, so the next report is self-explanatory: loop_lag carries `samples` (~50 when healthy, 1 when a single turn swallowed the second), `tick_gap_ms` measured on the WALL CLOCK independently of the histogram, and `worst_tick_gap_ms`/`worst_tick_at` — monotone, so five-minute polling can no longer miss an episode. Band semantics are deliberately unchanged. A one-sample window during a real stall is the correct trigger for the shed valve; suppressing it would blind the protection at exactly the moment it is needed. Separately, device_telemetry gets the age sweep it never had. The per-heartbeat row cap only ever trims the device whose heartbeat is being handled, so a device that STOPS reporting leaves its rows behind forever. The new sweep is per-device (rides idx_telemetry_device rather than scanning), chunked and yielding like the device_status_log one, and defaults to 30 days to match the uptime report's own default window — so it cannot remove rows that report would have shown. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014skWYXJUWhF73EvNPgB2AS	2026-08-06 20:22:21 -05:00
ScreenTinker	099320af29	fix(db): WAL checkpointer worker-death handling (respawn + inline-autocheckpoint fallback) ... Close the disk-fill trap: with wal_autocheckpoint=0 a dead worker means nothing checkpoints. Controller now respawns an unexpectedly-dead worker (bounded: RespawnMax/RespawnWindowMs + backoff); on exhaustion it re-arms a conservative inline autocheckpoint (FallbackPages) on the main connection + reclaims the backlog, logging loudly. Clean stopWalCheckpointer() teardown is distinguished via a 'stopping' flag so SIGTERM never triggers respawn. Env-gated worker fault-injection (WAL_CKPT_FAIL_START) for tests. Local only — no bump/tag.	2026-07-06 23:50:18 -05:00
ScreenTinker	de7bd18bf3	fix(db): off-main-thread WAL checkpointer (worker) to kill the ~60s p99 checkpoint spike ... Disable wal_autocheckpoint on the main connection; run PASSIVE checkpoints from a worker_threads worker with its OWN better-sqlite3 handle, escalating to TRUNCATE on a size high-water or PASSIVE-starvation. Removes the synchronous fsync-heavy checkpoint from the event loop. Config: walCheckpointIntervalMs/HighWaterMB/StarvationRuns. Local only — no bump/tag.	2026-07-06 23:50:18 -05:00