The stutter has a suspect, and it is the animated collection card. (#33)
The per-phase breakdown shipped in 1.0.39 pointed somewhere neither of my two guesses had: the worst frame was swap=1198ms out of 1321 ms with bomb=0.0(0 tex, 0.0MB) — no texture uploads at all, and 1.2 seconds waiting for the browser to hand back a frame. Combined with the reporter's own observation that it only happens on collection rows, that narrows to the one thing collection rows have and catalog rows do not: the focused card animates.
The JPEG-sequence branch had no time step. Its sibling, the GIF branch, waits 67 ms between frames; this one computed the frame index from the clock but asked the texture cache for three files on every rendered frame — the current one and two prefetches. At 60 fps that is 180 cache lookups per second for the same three files, each taking the lock the decode threads also want, and each re-marking those entries as recently used, which tilts eviction against the posters actually on screen. A 90-frame folder is 46 MB against a 96 MB budget.
It now looks up only when the frame index actually changes, holds the resolved texture between steps, and prefetches one ahead instead of two.
The advisory panel now says why it opened and why it closed. (#31) One line when it opens, one if the guide data is wiped while the panel is on screen — and that second line names the culprit on its own, because the data is only cleared when the requested title changes underneath the playing one.
Also fixed on the way: the two functions that read the advisory rows did so without the lock the fetching thread holds while writing them, so the drawing code could see a new row count against an old row.