The aspect floor is really an ALBUM-ART guard -- its own comment says so: a
square sleeve passes every other gate, and Camping in Alaska's square "lost and
found" artwork once reached a live hero slot that way. But it was written as a
blanket "wide only" rule, so it also discarded portrait press photography one
crate before the machinery built to handle it.
The app already crops tall sources to 16:9 around detected faces: hero_crop.rs
keeps full source width, slides the window vertically, and applies headroom
rules above the topmost face (recipe vertical-yoloxnano-...-faces-first).
maximal_hero_rect exists specifically for sources taller than 16:9. Meanwhile
the selection gate in the metadata crate rejected everything below 1.15, so
those images never arrived.
Sleeves are square; press portraits are not. Admitting ratio <= 0.92 with at
least 1000px of width keeps the guard exactly where release artwork lives while
opening the one route to a hero for artists whose entire press corpus is
portrait. Posters and flyers cannot enter this way either: the text, flat and
collage gates all run before this one.
Hana Vu goes from BANNER NONE to 2 -- the LA Times 2000x2500 portrait and an
Our Culture press shot -- and renders correctly, face placed with headroom.
Camping in Alaska is unchanged, same three banners. Square 1:1 press crops
(Nikki Nair's Rinse FM and Corsica shots) stay rejected, which is the guard
still doing its job.
Two follow-ups to reading both Bing buckets.
The multi-artist guard treated " x " as a co-bill between two acts. In practice
it far more often joins a venue and a festival: "Nikki Nair | Boiler Room x
Bass Coast 2022". Because every YouTube thumbnail is named maxresdefault.jpg,
image_names_artist is structurally false for that whole class, so the rule was
rejecting Boiler Room and festival set photography -- the richest source of
hero-shaped images that exists for DJs. Genuine collaboration graphics are
still caught by named_collaboration, which requires the image itself to name
the other subject, so nothing is lost. Nikki Nair's multi= counter drops from 1
to 0 with his identity accepts intact.
And explicit results are now rejected before the identity gate. Reading the
unfiltered bucket is necessary for coverage but it puts pornography in the
candidate pool: one artist's unfiltered wave returned 24 hardcore cards. An
audit found zero of ~67 such cards could clear bing_identity_confidence,
because porn pages do not name obscure musicians -- but that is an empirical
accident rather than a guarantee, and reading only the strict bucket used to
provide an independent second layer. This restores one. The vocabulary is
deliberately narrow so "adult contemporary", XXX as a roman numeral, and band
names like Nude Beach or Pornography stay eligible.
Canary unchanged: Fishmans still accepted=12 with the same three banners.
Bing's safesearch preference selects which cached result set answers a query,
and either bucket can be serving a DIFFERENT query's results. Measured on one
machine minutes apart:
Fishmans strict 32/35 relevant | unsignalled 0/35 (porn, a chord page,
a printable calendar)
Nikki Nair strict 0/35 | unsignalled 35/35 (Resident Advisor,
Rinse FM, Boiler Room)
So there is no correct global setting. Shipping strict alone in ee25095 fixed
Fishmans, Partiboi69 and Camping in Alaska while silently hiding artists Bing
can see perfectly well. Every wave now reads both buckets and pools the cards,
deduped by media url, and the identity gate picks the winner -- it rejected
~3,000 cards in the audit behind this with no observed false rejects.
The query ladder also gains the bare artist name. Decorated queries collapse a
rare artist onto a popular entity sharing a word: every "Hana Vu ... photo"
phrasing returns the Japanese group HANA, quoting included, while the bare name
returns her real NME and LA Times press shots. Every accept on the three newly
fixed artists came from this query.
A 1-2 card page now counts as a degraded answer rather than only an empty one
-- a single junk card was enough to blank an artist for CATALOG_TTL, and that
was 15 of 30 waves for MSPAINT and Billy Cobb in one audit. The richer of the
two reads wins so a thin retry cannot lose a good first answer.
And fanart.tv publishes newer uploads under artist4kbackground, not the legacy
artistbackground the code asked for. MSPAINT's ONLY background is a 3840x2160
band photo under the new key -- fetched and discarded on every page load while
the artist showed no hero at all.
Measured across 21 artists, every winning image inspected: 8 -> 10 with a
correct hero, no wrong-artist hero anywhere, canaries (Fishmans, Partiboi69,
Camping in Alaska) unchanged. Newly working: Jane Remover, They Are Gutting a
Body of Water, MSPAINT.
An artist's hero was re-discovered every 24 hours through a tier that fails
per-name, and the stale manifest was deleted on the way in -- before the
replacement lookup had run. So one bad discovery day did not merely fail to
refresh a hero, it destroyed the good one first and left the artist blank.
On this machine that took the persisted store from 26 artists down to 3;
Crazy P, MSPAINT, Sword II, Hermeth, Billy Cobb, Pond, Weezer, Daft Punk and
King Krule all had correct banners on disk that nothing would ever read again.
Three changes:
- The manifest TTL goes from 24 hours to 30 days, matching the cover
resolution horizon. A press photo is still the artist's press photo a month
later; it does not go stale the way metadata does.
- Reading a manifest no longer destroys it. Stale and older-recipe manifests
are retained as a floor and only replaced once a lookup returns something
better, which also migrates them forward to the current recipe. Only files
that are unusable -- oversized, unparseable, or belonging to another artist
-- are removed.
- A failed hero discovery is detected by an EMPTY BANNER LIST, not a None:
catalog_artist_art returns Some as soon as the Deezer profile resolves, so
the previous None check could never fire, and an empty result would also
overwrite good banners whenever logos were present.
Also widens discovery so fewer artists need the floor at all. The query ladder
gains the bare artist name: decorated queries can collapse a rare artist onto a
popular entity sharing a word -- every "Hana Vu ... photo" phrasing returns the
Japanese group HANA (525 of 525 cards, quoting included), while the bare name
returns her real press photos with 16 of 17 passing the identity gate as
Strong. The gate, not the query, is what filters.
And a near-empty Bing page now counts as degraded. The retry test was
is_empty(), which let the commonest degraded shape through: a one-card page of
something unrelated, cached as that artist's verdict for a quarter hour.
Measured 15 of 30 waves for MSPAINT and Billy Cobb. The richer of the two
reads is kept so a thin retry cannot lose a good first answer.
Verified live: Crazy P, MSPAINT, Sword II and Hermeth all render heroes again.
Our client keeps no cookie jar, so every Bing read arrived with the
adult-content preference undefined -- and in that state Bing answers with
wholly unrelated cached result sets. Four identical back-to-back reads of
"Fishmans band photo" returned porn, an Indonesian guitar-chord page, porn
again, and a printable 2026 calendar, each internally coherent with honest
titles and page urls.
Measured 27/27 reads with zero relevant cards without the flag and 27/27
correct with it, across three artists, three waves and three repeats. Only
strict works; moderate and off behave exactly like sending nothing. Strict
costs no relevance (Partiboi69 scores 34/35) and it also keeps explicit
imagery out of the candidate pool, which until now only the identity gate
was stopping.
This failure was misdiagnosed twice -- first as a poisoned IP, then as Bing
rate limiting -- because with no cookie our requests are byte-identical
every time, so all the variability lived in Bing's cache. That is why it
appeared to break and heal on its own with no code change.
Camping in Alaska, Fishmans and Partiboi69 now resolve real heroes again.
The Bing hero tier currently returns no banner for artists it used to cover.
Every gate in the candidate loop is a silent `continue`, so a tier that throws
away all 525 parsed results looks identical to Bing returning nothing at all —
which is why this has now read as a fresh regression four times without anything
being able to confirm or deny it.
Emit HERO_GATES alongside HERO_WAVE: what was parsed, what was accepted, and the
count discarded by each gate, plus the first few identity rejections in full.
That immediately separates "our filter broke" from "Bing sent us junk".
It says the second one. For Camping in Alaska: parsed=525, accepted=0,
identity=510 — and the rejected cards are campground photos from recreation.gov
and thedyrt.com. Partiboi69 returns Bruce Lee wallpapers, Fishmans returns Tommy
Fury boxing coverage, Hermeth returns aesthetic quote wallpapers. The results are
unrelated to the query and to each other, so the identity gate is doing exactly
its job: refusing to hang another person's face on the artist.
Confirmed outside the app, straight from curl. Zero query-relevant result cards
on any variant — with and without qft/form/first/cc/setlang/tsc, with full
browser client-hint and sec-fetch headers, and against the /images/async grid
endpoint the page itself uses. The async endpoint answers "Fishmans band photo"
with AI-course ads and "Partiboi69 band photo" with celebrity photoshoots. Our
url is well formed and the parser is fine: `q` is properly encoded, and cards
still parse (252-525 of them). Bing is simply no longer honouring the query for
this client.
Also stop one bad answer from sticking. Bing serves the SAME url a card-less
page on one read and 25-80 cards on the next, and browser_html caches whatever
came back for CATALOG_TTL — so a single degraded response left an artist
heroless for fifteen minutes. A wave that parses to nothing now drops the cached
page and asks once more. This does not address the wrong-results failure above;
it removes a compounding one found while chasing it.
No hero behaviour is changed by this commit.
Clicking a track could play silently: the store showed status=playing with
the position advancing and no error, but the sink was at volume 0. The
open/close crossfade ramped the main player's USER VOLUME as its fade
channel and left it at 0 on an ack timeout (or when a track change
suppressed the close resume). User volume persists across tracks and a new
Play doesn't reset it, so every later click played at 0 while the slider
still read 0.7.
Give the main player a separate fade_gain channel (Cmd::SetFadeGain, sink =
volume * norm * fade_gain), reset to 1 by every Play/Stop. The open/close
fades ramp fade_gain instead of set_volume (their volume arg is gone, JS
callers too), so the user volume is never touched -- store and backend can't
desync -- and a clicked track always resets fade_gain to 1, so it can never
be stranded silent. fade_resume lands exactly at 1. Player::fade_gain()
mirrors it into a report atomic; debug overlay shows main fade + this proved
the fix live (open 1->0, close 0->1, new track 1.0, volume steady at 0.7).
39 app + 12 player + 85 JS tests pass.
Preview modal audio, five rounds:
- True track-change crossfade: scheduleSettle no longer silences the
outgoing clip at t=0; preview_load's equal-power fade owns both ramps,
gated on the incoming voice's first Playing event (audible_marks), with
failure/overstay fallbacks. CROSSFADE_MS = 340 — locked to the reel's
card-slide so audio and visuals land together.
- Two-neighbour lease prefetch + a 15-min on-disk clip byte-cache
(recent_clips): steps in BOTH directions crossfade in ~15 ms; revisits
never re-download.
- Adaptive settle (isolated steps fire immediately, bursts coalesce) and
anticipatory auto-advance (step at clip end minus 400 ms) so auto-play
crossfades over the tail instead of gapping.
- Session resume memory: revisited tracks continue where they left off
(decoder-level start offset via play_local_from/resume_at); finished
tracks restart from the top.
- Open/close crossfades with the MAIN player: fade-pause with the
desired-paused latch landing at ramp end, fade-resume from the paused
position; MAIN_FADE_GEN guards; focus handshake relaxation documented
in focusBridge.
Volume normalization (Settings > Playback, default on):
- Dependency-free BS.1770/EBU R128 meter in the player crate (K-weighting,
400 ms gated blocks, incremental) + analyzer that reads the same growing
file playback streams from — first plays are measured at download speed.
- Gain layered under user volume; audible start GATED on a preliminary
measurement (10 s of audio or 800 ms budget) so the level is right from
the first sample and never changes mid-track; prelim boosts capped 3 dB,
peak-aware clipping guard, persistent loudness-cache.json.
- Gapless boundaries get their own sample-accurate gain via
SetNextNormGainDb, fed by preload analysis.
Debug overlay (Ctrl+Shift+D): process-tree CPU / PDH GPU / working-set +
private-commit RAM / network rates / FPS / current-track download progress
read from the backend's own StreamProgress / live normalization state /
preview session phase. Polls only while visible.
131 JS + player + app tests green; every path verified live over CDP.
Rust (2A):
- metadata: deezer_track_uncached (fresh mint, cache-updating, paced) and
fetch_preview_media — dedicated client whose custom redirect policy
re-validates every hop against the media allowlist; bounded body read
(cap enforced on received bytes, not Content-Length's promise); Date
header captured for provider-clock lease math. httpdate dep added.
- src-tauri/preview.rs: second Player instance + soulstream:preview event
channel; preview_resolve (fresh mint → host gate → MIME gate → ID3v2
shell strip → MPEG sync check → clip file + opaque lease id → safe_for_ms
mirroring lease.js); preview_load with start_paused via the
desired-paused latch; preview_control/dispose; player_pause_acked
exposing the Phase 0.4 ack on the MAIN player. 9 unit tests.
JS (2B):
- api.js: preview command surface (opaque lease ids only).
- nativeTransport.js: stamps {sessionId, generation, sessionKey} onto
backend events; cleared context makes stragglers dispatch nothing.
- productionResolver.js: DTO → MediaLease, failure classes preserved.
- focusBridge.js: production coordinator binding with the documented
renderer-side generation invariant (buffering counter + gateway).
- service.js: the orchestrator — settle window, resolve→load→play under
focus, single capped retry, one forward lease prefetch with safe-window
expiry, stale re-checks before every transport command, close/handoff.
The service constructs its transport around its own dispatch — the
factory signature exists because a pre-built transport silently loses
the event wiring (caught by test).
70 JS tests passing (npm test); metadata 46 + app preview 9 in cargo.
Player::pause_acked() returns a generation-bound PauseAck applied on the
audio thread; a desired-paused latch makes an in-flight decoder come up
paused instead of auto-starting, closing the window where a pause lands
during decode setup. Proven live by examples/focus_ack_probe.rs:
ack-while-playing freezes position; ack-while-buffering never becomes
audible; resume clears the latch; plain pause() during buffering is
demonstrated to auto-start (pre-existing hazard, filed separately).
Transport ADR recorded (native), Phase 0 marked complete in the plan.
The previous .git directory was found gutted (only info/ remained), so
history is unrecoverable locally. This commit restores version control
with the tree exactly as it stands: the working app, the preview-tracks
launcher on the artist hero, the scrollable-track-previews design bundle
(docs + approved mockups), and the Phase 0 validation artifacts.
KeelrLeek