TWO CHANGES, together because they touch the same packager hunks.
1. THE DRIVER.
The BrightSign package used to be MANUFACTURED. scripts/build-server-zip.sh dropped
better-sqlite3 from package.json and then installed db/sqlite-compat.js into
node_modules under that name, so every require resolved to the façade. It worked —
and it shipped a database layer that no test had ever executed. That is the same
shape as the TELEMETRY_COLLECTOR TDZ crash that took production down while 1676
tests and four CI jobs were green: a build-time rewrite cannot be tested by the
build that performs it.
db/sqlite-driver.js now decides at runtime: the native driver when it loads, the
node:sqlite façade otherwise. One artifact, one code path, and — the point — both
branches reachable from a test. ST_SQLITE_DRIVER=node runs the entire suite the way
a player runs it, and a new CI job does exactly that on Node 24 with --omit=optional
so the fallback is reached the same way it is on hardware, not by an env var alone.
better-sqlite3 becomes an optionalDependency, so a host with no compiler installs
cleanly and falls back rather than failing. preflight-deps stops trying to rebuild a
native module on a host that has no toolchain and a working built-in driver — on a
player that was a five-minute node-gyp failure ending in a server that never started.
Asking for the native driver BY NAME (ST_SQLITE_DRIVER=better-sqlite3) still fails
loudly, because a production box that has lost its native module is broken and should
say so rather than quietly running something else.
⚠️ NODE 24 IN PRACTICE. node:sqlite is unflagged only from 23.4; on the 22.x line it
needs --experimental-sqlite and on 20.x it does not exist. So the code probes rather
than comparing versions, the player package pins engines >=24, and the built-in cases
skip on the Node 20 CI job rather than failing there.
Verified on Node 24, both drivers, full suite:
better-sqlite3 1762 pass / 0 fail
node:sqlite 1762 pass / 0 fail
and the built payload resolves node:sqlite with no better-sqlite3 present at all.
2. THE LICENCE.
The ffprobe/ffmpeg binaries added in the previous commit are LGPL 2.1 and statically
linked, so the licence text has to travel WITH them — a link on a website is not the
copy the licence asks to accompany the work. The packager now copies
COPYING.LGPLv2.1 and a build README into bin/, and refuses to build if the licence is
missing. legal/third-party.html gains an LGPL section with the written offer required
by section 6 for static linking, and the exact configure line.
It also drops Sharp, which that page still listed although #263 removed it, and names
what actually does the image work now (jimp, @jsquash/webp, @jsquash/avif).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014kfhrUPit5MCqxeTQyqr56
The staging code added in 4a4b9e3 reads bin/<tool>.gz from the install root, with
DATA_DIR as a fallback; until now only the fallback was populated, by hand. The
payload carries them, so an update refreshes the media tools along with the server.
PAYLOAD ONLY. The boot zip is read by the OS's own zip reader before anything else
runs, and a 73MB one failed outright with "ZipArchive error" — it is ~64KB and stays
that way.
Stored rather than compressed (the archive is -0 throughout) because they are gzipped
already: 3.2MB in the package against 6.7MB of tmpfs once unpacked.
They live in brightsign/media-tools/ and are excluded from the wholesale brightsign/
staging, or the package would carry both copies. A missing file is a hard error, not
a warning: both are tracked, so absence means someone removed them, and the symptom
would otherwise be a player that silently stops making video thumbnails.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014kfhrUPit5MCqxeTQyqr56
