SKYHOUSE.dev Journal

Why: Damien's manual routine for a stuck download — grab, wait, notice it never moves, go back, interactive-search, pick something "instantly available" — is the part of the pipeline still done entirely by hand, and the judgement inside it turned out to be a single API call.

1. The capability that made it possible

TorBox's /torrents/checkcached answers for arbitrary infohashes, not merely ones in the account. Verified 2026-08-10: the account held 5 torrents while 13 of 46 candidate releases for one film reported cached — which incidentally proves the cache is global rather than per-account, and therefore that clearing finished torrents out of the account costs nothing in future availability.

So "is this instantly available?" is knowable before committing to a grab. Damien's instinct had been to grab several candidates in parallel and cancel the losers. The arrs cannot express that — Radarr tracks one grab per movie, so N grabs means N queue entries racing to import, which is exactly how this library accumulated its duplicates. But the race only exists to discover availability. Ask instead, and one grab is always enough.

2. Seeders are the wrong signal here

Worth stating plainly because it inverts normal torrent intuition. The best cached candidate for Don't Worry Darling was a WEBDL-2160p with one seeder; a cached Bluray-1080p had thirty. On debrid, a 1-seeder cached release imports in seconds while a 30-seeder uncached one waits on TorBox fetching from the swarm. Cachedness dominates; seeders are a last-resort tiebreak.

3. arr-cached-search.py — the picker

Fetches candidate releases, drops what the profile refuses, batch-checks the hashes against TorBox, and picks the best cached one by quality rank with an efficiency bonus. Report-only by default; --apply grabs via the same endpoint the interactive-search button uses. Two safety properties: it fails closed if the cache check errors (an unreachable provider must not read as "nothing is cached", which would silently degrade "prefer cached" into "grab anything"), and it refuses to grab anything uncached, printing why rather than quietly taking the patient path.

It found the target shape unprompted: for Harry Potter and the Goblet of Fire it picked 2160p BRRip 10Bit x265 at 7.8 GB with 99 seeders. Cache hit rates across sampled titles ran 27–33 of 43–53 candidates, which is the premise the whole design rests on.

4. arr-upgrade-scan.py — and the two bugs that nearly shipped

The second tool looks the other way: which files already on disk could a cached, smaller copy replace? Its first run was confident and wrong.

74.9G  80.2G -> 5.3G  Harry Potter and the Prisoner of Azkaban
19.6G  21.3G -> 1.7G  Finding Nemo (2003)
21.1G  22.2G -> 1.1G  Nick of Time (1995)
                        7 titles, ~220 GB "reclaimable"

Most of those were downgrades. Finding Nemo's existing file is UHD BluRay 2160p HDR10 DV HEVC x265; replacing it with 1.7 GB of 1080p is not a saving, it is a loss recorded as a win.

• Radarr classifies a lot of this library as quality=Unknown — Finding Nemo among them — and the resolution helper defaulted Unknown to 1080. A 2160p HDR file therefore looked like 1080p, and a 1080p replacement passed the no-downgrade check. Resolution now falls back to parsing the filename, and an undeterminable one skips the title rather than defaulting to something convenient.
• Comparing resolution alone is insufficient. WEBDL-2160p → WEBRip-2160p holds the resolution while dropping the source; Remux-1080p → HDTV-1080p is a collapse. Both were in that first list. There is now a source ranking (HDTV < WEBRip < WEBDL < Bluray < Remux) with the same no-regression rule.

A third correction was needed before any of it worked at all: for a movie that already has a file, Radarr rejects every release — 92 of 92 on the probed title — but overwhelmingly for policy reasons (existing file meets cutoff, profile does not allow upgrades) rather than quality ones. Filtering on the boolean rejected returned nothing. The tool now inspects the rejection reason and fails closed on anything unrecognised, so the new size caps, seeder minimums and language rules all still bite.

5. The honest negative result

With the corrections in place the replacement scanner returns zero, and the funnel shows that is correct rather than broken:

Samsara — current WEBDL-2160p, 24.5 GB
  106 releases -> 46 with infohash -> 22 pass caps/seeders/language
              ->  1 at 2160p or better ->  0 at WEBDL source or better

The oversized files are oversized because they are genuinely good. A 24.5 GB 2160p WEB-DL x265 10bit HDR DTS-HD has no smaller equal-or-better twin; the cheap alternatives are cheap because they are WEBRips or 1080p. The goldilocks opportunity is real for acquisition and largely absent for replacement. Better to learn that from a funnel than from a week of swaps.

One class does still qualify, and the first version was silently skipping it: 35 files Radarr cannot classify at all, of which one is over 10 GB — Harry Potter and the Prisoner of Azkaban as an 80.2 GB 00002.m2ts, a raw disc rip. Those are now listed separately for human judgement instead of being dropped for lack of a parseable resolution.

6. Spending the space instead of saving it

--upgrade inverts the scan: titles still below 1080p where a cached better copy exists, reporting the disk cost. This is where the yield is:

  +3.3G  Bluray-480p  1.5G -> Bluray-1080p  4.7G  Maggie's Plan (2016)
  +0.5G  Bluray-480p  1.4G -> Bluray-1080p  1.9G  The Vanishing (1988)
  -1.5G  WEBDL-720p   3.5G -> Bluray-1080p  2.0G  Big Night (1996)

8 upgradeable now from cache; ~3 GB of disk needed   (95 files still below 1080p)

Eight upgrades for three gigabytes total, two of them negative cost — a better copy that is also smaller, because 480p-era files are small and modern 1080p x265 is efficient. Nearly free quality.

7. Why both stay report-only

Neither tool gets an --apply for replacement, and that is structural rather than timidity: profile Any has upgradeAllowed=false, and a smaller file is not an "upgrade" regardless — the same rule that made Radarr refuse the 1080p Freeway while holding 2160p. Replacement is inherently two steps: remove the file, then let the picker choose. --script emits exactly that worklist.

But the better argument is Damien's. Baraka is ninety minutes of photography with no dialogue and no plot; visual fidelity is the entire artifact. A schlocky horror title kept for completeness could be capped at 3.5 GB without anyone noticing. No rule expresses that, because it is a judgement about what the film is for. A list a human scans is not a weaker version of automation here — it is the correct instrument.

The first scanner run offered 220 GB of savings and would have quietly degraded a dozen films. The catch came from checking its recommendations against the actual files, not from anything the tool reported about itself.