Two reports rolled into one pass:
1. Rail occasionally rendered nothing on Home open. Cause: the rotated
anchor sometimes had no Last.fm similar-artists or no library matches
among the sampled set, and the old code gave up after one try and
stored that dud anchor as the rotation cursor — so the next mount
started from the same dud's neighbour and could fail again.
2. Recommendations felt repetitive. Cause: pool of 12 anchors walked
round-robin made each anchor recur every 12 mounts, similar-artist
sample of 6 from 12 had heavy overlap visit-to-visit, and per-artist
single-album random pick meant artists with one library album always
surfaced the same record.
Anchor selection: random pick from pool with a per-server cooldown
buffer (last 5 anchors excluded, capped at floor(pool/2) so small
libraries don't soft-lock). Up to 4 anchors are tried in a shuffled
candidates list before giving up; the localStorage cursor only advances
on a successful anchor so duds don't poison future mounts.
Picks variety: similar-artist fetch raised from 12 to 25 (same
getArtistInfo call, larger response — Last.fm typically returns up to
~50). Per-server ring buffer of the last 30 shown album ids; per-similar
-artist album choice prefers an album not in that buffer, falling back
to any album when the artist's whole catalogue is stale so the slot is
never lost.
Pool cap raised 12 -> 20 to give the cooldown buffer room to breathe in
libraries with varied listening history.
Storage: legacy `psysonic_because_anchor:` single-id keys from the
round-robin era are stripped on module load (one-shot localStorage
sweep, the new `..._anchor_history:` prefix has a different colon
position so no false matches).
API budget unchanged in the hot path: 1 getArtistInfo + 6 getArtist
per Home mount. Worst case (3 dud anchors, 4th succeeds) is 4
getArtistInfo + 6 getArtist.
Frank Stellmacher
ba73649360