2 commits

Author	SHA1	Message	Date
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	684e60fc55	Offline media on every player, and a revision so the cache can still be updated ... Two halves of the same problem. A screen has to keep playing when the link is gone, and it must not keep playing the wrong thing once the link is back. CACHING FOR OFFLINE, on the players that could not: - Tizen cached nothing but the playlist, so a panel came back from a reboot knowing exactly what to show and fetched every frame of it from a server that was not there. tizen/js/media-cache.js caches the media itself to wgt-private (the store Tizen documents as surviving reboots), resumable via Range and If-Range, with the transfer async so a stalled chunk cannot freeze the player. offline.cache moves from "absent" to a runtime claim: a build with no writable private storage still says nothing. - The web player's worker stored only what a single fetch() happened to complete, which on a marginal link is nothing at all — a 200MB asset never finishes in one go and every retry starts from zero. It now accumulates in resumable chunks, driven by the player's playlist rather than by playback, so the prefetch is not competing with the video that is currently on screen for the same scarce bandwidth. BrightSign inherits this. STILL UPDATING, which caching quietly breaks: PUT /api/content/:id/replace changes an asset's bytes under a stable id. Every cache keys on that id, so before this the new bytes could not reach a panel that already held the old ones — not until the next refresh, but never. Content now carries a revision, stamped onto each item at send time like widget revs, and every player keys its cache on it. The same send-time refresh fixes a second bug: a replace writes a new randomly-named file and unlinks the old one, so the filepath in a published snapshot pointed at a deleted file and web panels 404'd on the item until somebody republished the playlist. The route now also pushes to affected devices, which it never did. Bytes are kept only where they can be built upon: no validator means no safe resume, so the partial is discarded and the attempt backs off as the failure it is rather than re-fetching the same prefix forever. Server needed no new transfer support — res.sendFile already does Range, If-Range and 416. The Tizen cache and the service worker are both driven in Node against fakes, because neither can be exercised without hardware and "the chunks assemble correctly" is not something to discover from a panel showing a corrupt video. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-05 15:27:36 -05:00