Don't count recent MAM snatches twice when finding free slots; source links on Queued

[mikaeltarquin]

Summary

Downloads waiting for an unsatisfied slot when slots were free

• MAM's unsatisfied count lags its snatches, so Shelfmark adds the torrents it handed off in the last 15 minutes to it. Once MAM's count had caught up, they were counted twice.
• A run that filled the free slots then saw the account as full for the rest of the 15 minutes. At 132 of 150 with 5 kept free: 150 − 5 − 132 − 13 = 0. With a 5-minute re-check, the queue moved in bursts with long stalls.
• Shelfmark now keeps its readings of MAM's unsatisfied count. However far the count has risen since the reading just before the recent snatches, that many are already in it; only the rest are added.
  • With no earlier reading (after a restart), all recent snatches still count.
  • Torrents leaving the count only make it count more. The kept-free slots cover snatches made outside Shelfmark.
• Downloads waiting for a slot are re-checked every 2 minutes (was 5), and their status says so.

Source links on the Queued page

• Downloads up next get the "Open on MyAnonamouse" button beside Remove.
• Saved picks get one beside each release line, on Queued and Wanted.
• The button is now a shared SourcePageLink, used by History too.

Testing

• New tests:
  • Snatches MAM already counts free no extra slots.
  • A partial catch-up counts only the rest.
  • No earlier reading counts them all.
• Python (-m "not integration and not e2e"): only the same 5 environment failures as before.
• Frontend: typecheck, oxlint, oxfmt, vitest (348).
• Loaded the Queued page with test data and checked every row links to its MAM page.

🤖 Generated with Claude Code

https://claude.ai/code/session_01V88DbAixT45r3AJsyFJchY

---

Generated by Claude Code