From 91ecc8a75c0e04241b77e98ae90a6bc8c7c01c0c Mon Sep 17 00:00:00 2001 From: jim kolpack Date: Sun, 11 Oct 2026 13:20:27 -0400 Subject: [PATCH] Trim glitch active window to 18s to cut worst-case payload margin Reports of some rendered segments coming out too large for the physical Gen1 device, suspected (correctly) to be complex/busy album art pushing the glitch segment's payload up. Confirmed with synthetic adversarial testing: colored noise art (sharp per-pixel detail surviving the downscale to decode resolution, not smoothed-away high-res noise) at the full 22s window + strong zoom + random position measured 354KB -- uncomfortably close to the Gen1 460KB limit. Isolating glitch from baseline on the same noisy art (216KB without glitch, 354KB with) confirmed the glitch segment itself as the primary driver, exactly as suspected: it builds many genuinely distinct frames (jitter shifts, hue-tinted bands, scanline sweep) from the live art, and busy/high- entropy art means those frames compress far worse than against typical album art. GLITCH_ACTIVE_SECONDS cut from the full STATIC_OVERLAY_END_SECONDS (22) to a flat 18 -- re-tested against the same adversarial noise art: 333KB, widening the safety margin from 106KB (23%) to 127KB (28%). Re-accepts the tradeoff this was widened past once before (jitter/bands/scanlines go static for the last few seconds of a very-long "ending" window) deliberately this time, for the payload headroom. Verified: normal live-art render still well under budget (345KB), 0 black-corner hits in isolation at worst-case settings -- the duration change doesn't touch any of the margin-safety mechanics, just how many cycles play out. --- subwave_nowplaying.star | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/subwave_nowplaying.star b/subwave_nowplaying.star index ca4bb6e..3f1240e 100644 --- a/subwave_nowplaying.star +++ b/subwave_nowplaying.star @@ -591,12 +591,25 @@ GLITCH_STATE_POOL = [ # (which can be up to STATIC_OVERLAY_END_SECONDS = 22s) because the # hue-shifted RGB-split bands this used to also drive were expensive # enough to push a real render past the 460KB device limit if sized -# against the full window (measured 481KB at the time). Those bands are -# gone now -- this only drives the base-art jitter, built on -# render.Sequence + _glitch_shift (Padding), which compresses far -# better: a real worst-case render at the *full* 22s now measures ~54KB. -# So this now covers the whole window instead of a short burst within it. -GLITCH_ACTIVE_SECONDS = STATIC_OVERLAY_END_SECONDS +# against the full window (measured 481KB at the time). Those bands were +# dropped for a while (jitter alone, measured ~54KB worst-case at the +# full 22s) and this was widened to match -- but the bands have since +# come back (see GLITCH_STATE_POOL above), and worst-case payload tracks +# the *album art's own complexity*, not just whether bands are on: a +# busy/high-entropy cover compresses far worse than typical art, since +# every jitter/band/hue-shift state built from it ends up genuinely +# distinct rather than mostly redundant. Measured against synthetic +# noise art at the full 22s + strong zoom + random position: 354KB, +# uncomfortably close to the Gen1 460KB limit for art this adversarial. +# +# Capped at 18s (not the full 22) as a deliberate safety margin against +# that -- shorter than the max show_static window, so jitter/bands (and +# the scanline sweep, which shares this duration -- see +# SCANLINE_SWEEP_DURATION below) go static for the last few seconds of +# an "ending" window on a very long remaining-time case, the same +# tradeoff this was widened past once already, just re-accepted on +# purpose this time for the payload margin. +GLITCH_ACTIVE_SECONDS = 18 _GLITCH_CYCLE_TICKS = GLITCH_STATES_PER_CYCLE * GLITCH_HOLD_TICKS + GLITCH_PAUSE_TICKS _GLITCH_TICKS_PER_SECOND = 20 # 1000ms / 50ms-per-tick GLITCH_REPEATS = int(GLITCH_ACTIVE_SECONDS * _GLITCH_TICKS_PER_SECOND / _GLITCH_CYCLE_TICKS) + 1