Archive/screentinker

Fork 0

mirror of https://github.com/screentinker/screentinker.git synced 2026-08-15 06:43:27 -06:00

Commit graph

Author	SHA1	Message	Date
ScreenTinker	95b8d1b293	Export shared modules to the browser even when Node is in the page Transitions have never run on BrightSign, and it was never a GPU problem. `transitionRuntimeReady()` is a presence check on three globals and touches no WebGL at all. A BrightSign roHtmlWidget is created with `nodejs_enabled: true`, which puts Node's `module` into classic-script scope — so every shared module that exported with an `else` took the CommonJS branch and never assigned its browser global. The runtime was absent before WebGL was ever asked a question. This is deducible from the fleet without touching the hardware: the player pushes system.reboot / display.power / display.resolution / system.self_update only behind BS.hasHost(), which needs require('@brightsign/messageport') to resolve. Our XT245's stored capability row carries all four, so Node integration was live in that page, so the CommonJS branch was taken. Transitions are the least of it. schedule-eval.js had the same shape, and the player falls back to "always active" when ScheduleEval is missing — so per-item DAYPARTING silently stopped applying on that platform and scheduled content played outside its window with nothing in any log. player-media-health.js the same. Four files, all fixed by exporting to BOTH targets rather than either/or. media-mute.js, orientation-style.js and wall-geometry.js already assigned their globals in a separate unconditional block and were never affected; the audit that reached me claimed all seven, and reading them is what separated the four from the three. THE GUARD, WITHOUT WHICH THE ABOVE IS A REGRESSION. Restore the globals alone and BrightSign starts attempting video wipes it cannot supply. On a hardware video plane drawImage(video) succeeds, throws nothing, and paints a fully TRANSPARENT frame — so the wipe fades from nothing, behind a video plane that is still lit. Worse than the hard cut it replaces. The discriminator already existed: videoFrameIsCapturable() probes ALPHA, so a genuine fade-to-black still reads as captured. It was wired into the screenshot path and not this one, which asked isMediaReadable() — a CORS question, "am I allowed to read this", not "did any pixels arrive". Both the outgoing frame and the incoming warm-play snapshot now consult it, cached per platform, defaulting to available while undetermined so a cold start is not crippled. Net effect on BrightSign: image-to-image transitions light up, anything involving video hard-cuts honestly, and dayparting starts working. Full video transitions are reachable later — BrightSign documents that video "captured as a canvas for WebGL processing must be routed to the GPU" via a per-element hwz="off", which keeps hardware decode at an 8-bit/1080p ceiling. That needs the hardware to validate and is not in this change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014skWYXJUWhF73EvNPgB2AS	2026-08-07 10:36:50 -05:00
ScreenTinker	b57e7eec7f	fix(#146 ): web player — reconnect drops video to "Waiting for content" (idle reset over live playback) CONFIRMED from a live console capture (restore cache -> video plays -> reconnect -> "Playlist unchanged" -> screen falls to "Waiting for content..."). Audio survived because only the "showing content" VIEW was covered, not the audio path. ROOT CAUSE: the server re-emits device:paired on EVERY re-register of an already-paired device (ws/deviceSocket.js:510) — i.e. on every reconnect, while content is already playing. The player's device:paired handler called showStatus('Waiting for content...') UNCONDITIONALLY (the "falls through to idle" sibling), putting the idle overlay OVER the live video. The following device:playlist-update -> "Playlist unchanged" branch returned early and never cleared it, so the idle screen stuck on top of playing content. FIX (idle screen only when genuinely idle; unchanged is a strict no-op that keeps playback): - lib/player-media-health.js: new shouldShowIdle(state) — idle ONLY when nothing is playing AND there's genuinely no content. Already-playing (or content-present-about-to-render) is never idle. - device:paired handler: gate showStatus on shouldShowIdle({isPlaying, hasContent}) instead of showing it unconditionally. On a reconnect while playing -> no-op. - "Playlist unchanged" branch: when healthy playback is confirmed, hideStatus() to clear any stale idle overlay a reconnect's device:paired may have put up — so the confirmation can never leave "Waiting for content..." over live content. Still leaves the actual media element exactly as-is (no teardown, no flicker). - sw.js cache v10 -> v11. SIBLING SCAN: device:paired was the only unconditional idle reset. The connect() idle prompts (connecting / connecting_muted) were already guarded by !isPlaying; empty-playlist and no-renderable idles are genuine. Tests: player-media-health.test.js +2 (shouldShowIdle: playing never idle; idle only when empty+not-playing). Inline player JS syntax-checked; module served + guard referenced on a booted server. Suite 318/318. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-01 22:03:44 -05:00
ScreenTinker	26c72d62bf	fix(#146 ): web player — no-change refresh loses video (keeps audio); re-attach idempotently ROOT CAUSE (hypothesis A, pre-existing — NOT a beta7 regression; server/player/index.html is untouched since v1.9.2-beta6): handlePlaylistUpdate's "Playlist unchanged" branch blindly returned. The media re-attach (renderContent) lives ONLY in the content-changed branch, so if the <video> surface was lost (element detached from the DOM while still decoding — video gone, audio still playing) a no-new-content refresh never re-attached it. New-content refreshes were fine because they re-render. FIX (make the refresh idempotent for the media surface, no flicker on the healthy path): - server/lib/player-media-health.js (new, UMD + unit-testable, mirrors schedule-eval.js): needsReattach(state) — re-attach ONLY when playback should be happening but the current item's surface is actually lost (video null / detached / ended / errored; non-video: no mounted surface). A healthy attached+live video returns false, so a routine poll stays a no-op (no re-render, no flicker). Served at /player/player-media-health.js from the single source; loaded by the player. - index.html no-change branch: extract the current item's DOM facts and, iff PlayerMediaHealth.needsReattach, call playCurrentItem() to re-render the current item. Wrapped so the health check can never break a refresh. - teardownCurrentMedia: also release currentVideoEl even when it was DETACHED from the container — a detached-but-playing <video> keeps emitting audio and the container-scoped querySelectorAll can't find it. This kills the "ghost audio" on re-attach. - sw.js cache bumped v9 -> v10 so players pick up the new index.html + module. Tests: test/player-media-health.test.js (6) exercises the branch selection — healthy video -> no re-attach; detached/null/ended/errored -> re-attach; idle -> never; non-video by surface presence. Inline player JS syntax-checked; module served + referenced verified on a booted server. Suite 316/316. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-01 21:51:52 -05:00

Author

SHA1

Message

Date

ScreenTinker

95b8d1b293

Export shared modules to the browser even when Node is in the page

Transitions have never run on BrightSign, and it was never a GPU problem.

`transitionRuntimeReady()` is a presence check on three globals and touches no
WebGL at all. A BrightSign roHtmlWidget is created with `nodejs_enabled: true`,
which puts Node's `module` into classic-script scope — so every shared module
that exported with an `else` took the CommonJS branch and never assigned its
browser global. The runtime was absent before WebGL was ever asked a question.

This is deducible from the fleet without touching the hardware: the player
pushes system.reboot / display.power / display.resolution / system.self_update
only behind BS.hasHost(), which needs require('@brightsign/messageport') to
resolve. Our XT245's stored capability row carries all four, so Node
integration was live in that page, so the CommonJS branch was taken.

Transitions are the least of it. schedule-eval.js had the same shape, and the
player falls back to "always active" when ScheduleEval is missing — so per-item
DAYPARTING silently stopped applying on that platform and scheduled content
played outside its window with nothing in any log. player-media-health.js the
same. Four files, all fixed by exporting to BOTH targets rather than either/or.

media-mute.js, orientation-style.js and wall-geometry.js already assigned their
globals in a separate unconditional block and were never affected; the audit
that reached me claimed all seven, and reading them is what separated the four
from the three.

THE GUARD, WITHOUT WHICH THE ABOVE IS A REGRESSION.

Restore the globals alone and BrightSign starts attempting video wipes it
cannot supply. On a hardware video plane drawImage(video) succeeds, throws
nothing, and paints a fully TRANSPARENT frame — so the wipe fades from nothing,
behind a video plane that is still lit. Worse than the hard cut it replaces.

The discriminator already existed: videoFrameIsCapturable() probes ALPHA, so a
genuine fade-to-black still reads as captured. It was wired into the screenshot
path and not this one, which asked isMediaReadable() — a CORS question, "am I
allowed to read this", not "did any pixels arrive". Both the outgoing frame and
the incoming warm-play snapshot now consult it, cached per platform, defaulting
to available while undetermined so a cold start is not crippled.

Net effect on BrightSign: image-to-image transitions light up, anything
involving video hard-cuts honestly, and dayparting starts working.

Full video transitions are reachable later — BrightSign documents that video
"captured as a canvas for WebGL processing must be routed to the GPU" via a
per-element hwz="off", which keeps hardware decode at an 8-bit/1080p ceiling.
That needs the hardware to validate and is not in this change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014skWYXJUWhF73EvNPgB2AS

2026-08-07 10:36:50 -05:00

ScreenTinker

b57e7eec7f

fix(#146 ): web player — reconnect drops video to "Waiting for content" (idle reset over live playback)

CONFIRMED from a live console capture (restore cache -> video plays -> reconnect ->
"Playlist unchanged" -> screen falls to "Waiting for content..."). Audio survived because
only the "showing content" VIEW was covered, not the audio path.

ROOT CAUSE: the server re-emits device:paired on EVERY re-register of an already-paired
device (ws/deviceSocket.js:510) — i.e. on every reconnect, while content is already playing.
The player's device:paired handler called showStatus('Waiting for content...') UNCONDITIONALLY
(the "falls through to idle" sibling), putting the idle overlay OVER the live video. The
following device:playlist-update -> "Playlist unchanged" branch returned early and never
cleared it, so the idle screen stuck on top of playing content.

FIX (idle screen only when genuinely idle; unchanged is a strict no-op that keeps playback):
- lib/player-media-health.js: new shouldShowIdle(state) — idle ONLY when nothing is playing
  AND there's genuinely no content. Already-playing (or content-present-about-to-render) is
  never idle.
- device:paired handler: gate showStatus on shouldShowIdle({isPlaying, hasContent}) instead
  of showing it unconditionally. On a reconnect while playing -> no-op.
- "Playlist unchanged" branch: when healthy playback is confirmed, hideStatus() to clear any
  stale idle overlay a reconnect's device:paired may have put up — so the confirmation can
  never leave "Waiting for content..." over live content. Still leaves the actual media
  element exactly as-is (no teardown, no flicker).
- sw.js cache v10 -> v11.

SIBLING SCAN: device:paired was the only unconditional idle reset. The connect() idle
prompts (connecting / connecting_muted) were already guarded by !isPlaying; empty-playlist
and no-renderable idles are genuine.

Tests: player-media-health.test.js +2 (shouldShowIdle: playing never idle; idle only when
empty+not-playing). Inline player JS syntax-checked; module served + guard referenced on a
booted server. Suite 318/318.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-01 22:03:44 -05:00

ScreenTinker

26c72d62bf

fix(#146 ): web player — no-change refresh loses video (keeps audio); re-attach idempotently

ROOT CAUSE (hypothesis A, pre-existing — NOT a beta7 regression; server/player/index.html
is untouched since v1.9.2-beta6): handlePlaylistUpdate's "Playlist unchanged" branch blindly
returned. The media re-attach (renderContent) lives ONLY in the content-changed branch, so
if the <video> surface was lost (element detached from the DOM while still decoding — video
gone, audio still playing) a no-new-content refresh never re-attached it. New-content
refreshes were fine because they re-render.

FIX (make the refresh idempotent for the media surface, no flicker on the healthy path):
- server/lib/player-media-health.js (new, UMD + unit-testable, mirrors schedule-eval.js):
  needsReattach(state) — re-attach ONLY when playback should be happening but the current
  item's surface is actually lost (video null / detached / ended / errored; non-video: no
  mounted surface). A healthy attached+live video returns false, so a routine poll stays a
  no-op (no re-render, no flicker). Served at /player/player-media-health.js from the single
  source; loaded by the player.
- index.html no-change branch: extract the current item's DOM facts and, iff
  PlayerMediaHealth.needsReattach, call playCurrentItem() to re-render the current item.
  Wrapped so the health check can never break a refresh.
- teardownCurrentMedia: also release currentVideoEl even when it was DETACHED from the
  container — a detached-but-playing <video> keeps emitting audio and the container-scoped
  querySelectorAll can't find it. This kills the "ghost audio" on re-attach.
- sw.js cache bumped v9 -> v10 so players pick up the new index.html + module.

Tests: test/player-media-health.test.js (6) exercises the branch selection — healthy video
-> no re-attach; detached/null/ended/errored -> re-attach; idle -> never; non-video by
surface presence. Inline player JS syntax-checked; module served + referenced verified on a
booted server. Suite 316/316.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-01 21:51:52 -05:00

3 commits