Two tester reports, one root: the gig song pool was built from only two sets —
songs played ON THIS PASSPORT'S INSTRUMENT, and songs never played AT ALL
(`filename NOT IN song_stats`).
A song played on a DIFFERENT instrument's arrangement is in neither: it has a
stats row (so the "unplayed" filler skipped it), and its played bucket is that
other instrument's, not this passport's. It could never be gigged.
- "Metalcore says 137 songs only shows 1 in the gig list" — a library of
metalcore all played on another instrument. Reproduced: a guitar passport with
137 bass-played metalcore songs got a 404, zero songs. The "1" the tester saw
was whatever handful happened to be on-instrument or truly unplayed.
- "Passport re-roll does not change songs" — a set drawn from that filler was the
library's first N in table ORDER, every call. Re-roll re-proposes, so it
returned the identical set. Reproduced: 3 proposals, byte-identical.
_unplayed_genre_songs -> _fill_genre_songs: the pool is now every library song of
the genre the set hasn't already picked (a stats row on some other instrument has
no bearing on whether a song can be in THIS gig), and it is shuffled so re-roll
actually re-rolls.
Both reproduced against the real propose logic before the fix and pinned as
regression tests (both fail on the pre-fix routes.py). Full career suite green.
byrongamatos
7fa60e5ef6