ideas

Yes, that's totally doable. Radarr has a REST API (v3) that exposes every movie and its assigned quality profile, plus the list of quality profile definitions. I can pull both and flag any movie whose profile is "Any", a Blu-ray/Remux disc profile, or anything else you don't want.

To connect I need two things from you:

1. **Radarr base URL** — e.g. `http://192.168.1.x:7878` or `https://radarr.yourdomain.com`
2. **API key** — in Radarr's web UI under **Settings → General → Security → API Key**

A couple of things to confirm on how you want to run this:

• AskUserQuestion questions 183.0s 350 B

Got it. Here's the plan:

- **Credentials:** paste them here, I'll use them only this session and won't write them to any file.
- **Flagging logic:** the only *acceptable* profiles are **`HD - 720p/1080p`** or **`HD - 1080p`**. I'll flag every movie whose profile is anything else — including `Any`, any Bluray/Remux disc profile, Ultra-HD/4K, SD, etc.

Go ahead and paste your **Radarr base URL** and **API key** and I'll pull the list. One quick note: I'll send the API key in request headers to that URL only — nothing leaves your network except the calls to your own Radarr box (assuming it's a LAN/private address).

(If your Radarr is on a private LAN IP like `192.168.x.x` and I'm not on your network, the calls may not reach it — in that case I'll hand you the exact `curl` commands to run yourself instead.)

• Bash curl -s -m 20 -H "X-Api-Key: 9d430feea00f44b28678fb1e82fe5d1f" "https://radarr.rdx4.com/api/v3/qualityprofile" -w "\nHTT… 1.6s 2.2 KB

Connected. Let me extract the profile id→name map and then pull all movies.

• Bash echo "=== PROFILES (id -> name) ===" curl -s -m 20 -H "X-Api-Key: 9d430feea00f44b28678fb1e82fe5d1f" "https://radarr.rdx4… 4.4s 134 B

Acceptable profiles in your instance: **`HD-1080p` (id 4)** and **`HD - 720p/1080p` (id 6)**. Everything else gets flagged. Let me run the full audit.

• Bash curl -s -m 30 -H "X-Api-Key: 9d430feea00f44b28678fb1e82fe5d1f" "https://radarr.rdx4.com/api/v3/movie" | python3 -c " imp… 2.4s 3.2 KB

Done — audited all **1,123 movies**. Here's the verdict.

## Summary

| Profile | Count | Status |
|---|---|---|
| `HD-1080p` | 721 | ✅ OK |
| `HD - 720p/1080p` | 285 | ✅ OK |
| **`Any`** | **111** | 🚩 flagged |
| **`Ultra-HD`** | **6** | 🚩 flagged |
| `SD` | 0 | — |
| `HD-720p` | 0 | — |

**117 movies (10%) are on a profile you don't want.** The good news: nothing is on a 4K-only or dedicated Bluray-disc profile beyond the 6 on `Ultra-HD`. Your real exposure is the **`Any`** profile — and that's the worst offender, because `Any` has *every* quality flag enabled (CAM, TELESYNC, WORKPRINT, SD, DVD, Bluray Remux, full disc, etc.), so those 111 movies will grab literally anything Radarr can find, including cam-rips and full Bluray discs.

## The 6 on Ultra-HD (4K)
Akira (1988), Clerks III (2022), Dune: Part Two (2024), Nope (2022), Prey (2022), Project Hail Mary (2026)

## The 111 on "Any"
Full list is in the output above — notable ones include Arrival, Parasite, The Silence of the Lambs, Deadpool, the Harry Potter / Child's Play / Nightmare on Elm Street entries, Spirited Away, Soul, Inside Out, etc.

---

**Want me to fix them?** I can issue a bulk update via the API to reassign all 117 to a target profile in one shot. Radarr has an editor endpoint (`PUT /api/v3/movie/editor`) that takes a batch of movie IDs + a new `qualityProfileId`, so this is a single call per group.

Tell me the target for each:
- **The 111 `Any` movies** → `HD-1080p` or `HD - 720p/1080p`?
- **The 6 `Ultra-HD` movies** → leave them (maybe you *want* 4K for those?) or also drop to 1080p?

I won't change anything until you confirm the targets.

• Bash IDS=$(curl -s -m 30 -H "X-Api-Key: 9d430feea00f44b28678fb1e82fe5d1f" "https://radarr.rdx4.com/api/v3/movie" | python3 -c… 2.4s 21 B

Got 111 IDs. Now the bulk update to `HD-1080p` (id 4):

• Bash IDS=$(cat /tmp/any_ids.txt) PAYLOAD=$(python3 -c " import json ids=[int(x) for x in '$IDS'.split(',')] print(json.dumps(… 3.3s 105 B

Done. ✅

- **HTTP 202** — Radarr accepted the bulk edit.
- **`Any` profile is now empty** (0 movies) — gone from the distribution entirely.
- `HD-1080p` went **721 → 832** (+111, exactly the count we moved).
- `Ultra-HD` left untouched at **6**, as requested.

Final state across all 1,123 movies:

| Profile | Count |
|---|---|
| `HD-1080p` | 832 |
| `HD - 720p/1080p` | 285 |
| `Ultra-HD` | 6 |

Every movie is now on an approved profile (1080p-capped or the 720p/1080p combo), except the 6 you deliberately kept on 4K. Nothing remains on `Any`, so no more cam-rip / Bluray-disc grabs.

One thing worth noting: this changed the profile assignment, but Radarr won't *re-grab* anything automatically — existing files stay as-is. If some of those 111 already had junk files (e.g. a CAM or full-disc release pulled while on `Any`), they won't be upgraded unless they fall below the new profile's cutoff and you trigger a search. Want me to check whether any of the moved movies currently have files below 1080p that should be re-searched?

• Bash IDS=$(cat /tmp/any_ids.txt) curl -s -m 30 -H "X-Api-Key: 9d430feea00f44b28678fb1e82fe5d1f" "https://radarr.rdx4.com/api/… 3.5s 1.5 KB

Here are the **16 movies** (of the 96 with files) carrying something heavier than a standard 1080p encode:

**True 4K / 2160p (5):**
- Ghost in the Shell (1995) — `Remux-2160p`
- Lilo & Stitch (2025) — `WEBDL-2160p`
- Primate (2026) — `WEBDL-2160p`
- Snatch (2000) — `Bluray-2160p`
- Titan: The OceanGate Submersible Disaster (2025) — `WEBDL-2160p`

**Full Bluray disc (1):**
- Harry Potter and the Philosopher's Stone (2001) — `BR-DISK` (raw disc image)

**1080p Remux — full-bitrate, large files (10):**
Behind the Mask: The Rise of Leslie Vernon, Color Out of Space, Happy Death Day 2U, Inside Out, One Flew Over the Cuckoo's Nest, The Bay, The X-Files, The X-Files: I Want to Believe, Wayne's World, Wayne's World 2 — all `Remux-1080p`

A few things to understand before deciding:

- The **2160p files** are *above* the new `HD-1080p` cap, so Radarr will **never auto-upgrade them** — they're "better than the profile asks for." They'll just sit there. If you want them replaced with smaller 1080p files, you'd have to delete the file and trigger a search (a downgrade, which Radarr won't do on its own).
- The **`BR-DISK`** (Harry Potter) is a full disc folder — usually not even directly playable by most players and huge. Worth replacing.
- The **`Remux-1080p`** ones are technically 1080p *resolution* (so within the profile's res), but they're remuxes — full untouched Bluray bitrate, often 20–40+ GB each. Whether these count as "too big" depends on whether `Remux-1080p` is an allowed quality in your `HD-1080p` profile's cutoff. If it's allowed and at/above cutoff, Radarr leaves them; if not allowed, Radarr also won't downgrade automatically.

So **none of these will change on their own.** Your options per movie/group:

1. **Leave everything** — they're all decent-or-better quality, just larger than ideal.
2. **Replace specific groups** to reclaim disk space — e.g. delete the file + auto-search for a normal 1080p encode (I can do this in bulk for, say, the BR-DISK and the Remuxes).
3. **Just the BR-DISK** — replace only Harry Potter, leave the rest.

Want me to do anything, or were you mainly auditing? If you want replacements, tell me which group(s) and I'll delete-and-search them.

Good call — let me scan the **entire library** (all 1,123 movies), not just the ones we moved, for disc images. I'll check both the quality flag (`BR-DISK`) and the actual file path/extension (`.iso`, `BDMV`, `VIDEO_TS` folders) since those are what choke playback.

• Bash curl -s -m 40 -H "X-Api-Key: 9d430feea00f44b28678fb1e82fe5d1f" "https://radarr.rdx4.com/api/v3/movie" | python3 -c " imp… 2.5s 261 B

Hmm — that's fewer than I expected. The earlier scan flagged **Harry Potter** as `BR-DISK` too, but it didn't show here. Let me reconcile — I want to make sure nothing slips through a different code path.

• Bash curl -s -m 40 -H "X-Api-Key: 9d430feea00f44b28678fb1e82fe5d1f" "https://radarr.rdx4.com/api/v3/movie" | python3 -c " imp… 2.4s 309 B

A real discrepancy — Harry Potter showed as `BR-DISK` in the first pass but not now. Let me pin it down directly rather than trust the aggregate:

• Bash curl -s -m 40 -H "X-Api-Key: 9d430feea00f44b28678fb1e82fe5d1f" "https://radarr.rdx4.com/api/v3/movie" | python3 -c " imp… 4.7s 533 B

Pinned it down. The earlier `BR-DISK` flag on Harry Potter was **stale data** — its current file is a clean `Bluray-1080p` 6.8GB `.mkv`. Nothing wrong with it.

## So there are exactly 2 disc images left in your whole library:

| Movie | Quality | Size | File |
|---|---|---|---|
| **Dune** (2021) | `BR-DISK` | **45.8 GB** | `Dune (2021) BR-DISK.m2ts` |
| **Dune: Part Two** (2024) | `BR-DISK` | 1.3 GB | `Dune Part Two (2024) BR-DISK.m2ts` |

These are almost certainly your playback-crash culprits. Both are raw `.m2ts` Bluray-disc streams — that's the BDMV format with seamless-branching playlists, which Unraid's player/transcoder (Jellyfin/Plex/Emby direct-play) frequently chokes on, exactly the symptom you described. A normal `.mkv` encode wouldn't do that.

Two other things stand out:
- **Dune: Part Two at 1.3 GB** is suspiciously tiny for a BR-DISK `.m2ts` — that's likely a **broken/partial file** (a full disc stream should be 30–60 GB). It may not play at all.
- Note: **Dune: Part Two is one of the 6 you kept on `Ultra-HD`**, so even if you search, Radarr will look for 4K. Dune (2021) is now on a 1080p profile.

**Want me to fix them?** I'd:
1. **Delete** both `.m2ts` disc files (frees ~47 GB).
2. **Trigger an automatic search** so Radarr grabs a proper `.mkv` encode for each (1080p for Dune, 4K for Part Two per its profile).

Or if you'd rather not auto-search 4K for Part Two, I can drop it to `HD-1080p` first. Want me to delete + re-search both?

No response requested.

I'll re-scan the whole Radarr library for any remaining disc images.

• Bash curl -s -m 40 -H "X-Api-Key: 9d430feea00f44b28678fb1e82fe5d1f" "https://radarr.rdx4.com/api/v3/movie" | python3 -c " imp… 2.5s 324 B

Not clean yet — **both Dune disc images are still showing in Radarr**, identical to before:

| Movie | Quality | Size | File |
|---|---|---|---|
| **Dune** (2021) | `BR-DISK` | **45.8 GB** | `Dune (2021) BR-DISK.m2ts` |
| **Dune: Part Two** (2024) | `BR-DISK` | 1.3 GB | `Dune Part Two (2024) BR-DISK.m2ts` |

Radarr still reports `hasFile=true` with those sizes, so either:
1. **They weren't actually removed** (maybe you removed something else, or a different copy), or
2. **You deleted them on the Unraid disk, but Radarr hasn't rescanned** — so it's showing stale metadata for files that no longer exist.

I can't see the Unraid filesystem directly from here, so I can't tell which. Two ways to settle it:

- **Trigger a rescan** of both movies (`RefreshMovie` command) — if you already deleted the files on disk, Radarr will update to "missing" and they'll drop off the list. Non-destructive.
- **Delete via the API** — if the files are genuinely still there, I can have Radarr delete the file (`DELETE /api/v3/moviefile/{id}`), which removes it from disk too.

Want me to **trigger the rescan first** to see if they clear on their own? That's the safe move — if they vanish after the scan, you did remove them and Radarr just hadn't caught up. If they stay, I'll delete them properly. Then we can move on to Sonarr.

Sounds good. Once you've dropped the `.mkv` files in, let me know and I'll re-scan to confirm:
- Both Dunes now show a normal `.mkv` (no more `BR-DISK` / `.m2ts`), and
- The whole library is clean of disc images.

If Radarr doesn't auto-pick-up the new files, I can fire a `RefreshMovie` on both to force an import.

Whenever you're ready, point me at **Sonarr** (base URL + API key) and we'll do the same pass — list the quality profiles, see what's assigned, and sort out anything off. Standing by.

• Bash echo "=== QUALITY PROFILES (id -> name) ===" curl -s -m 20 -H "X-Api-Key: 5fab7462bbab4e1fa7d452f9d19ab90c" "https://son… 2.1s 155 B

Same profile setup as Radarr, plus a `foreign` profile (id 7). Let me get the distribution across all 372 series.

• Bash curl -s -m 40 -H "X-Api-Key: 5fab7462bbab4e1fa7d452f9d19ab90c" "https://sonarr.rdx4.com/api/v3/series" | python3 -c " im… 2.1s 1.9 KB

Here's the Sonarr picture across all **372 series**:

| Profile | Count | Status |
|---|---|---|
| `HD-1080p` | 155 | ✅ OK |
| `HD - 720p/1080p` | 146 | ✅ OK |
| **`Any`** | **70** | 🚩 flagged |
| **`HD-720p`** | **1** (Frasier) | 🚩 flagged |
| `foreign` | 0 | unused |
| `Ultra-HD` / `SD` | 0 | — |

So **71 series** on something other than your two approved profiles — same main offender as Radarr (`Any`, which grabs cam/SD/disc/anything), plus Frasier sitting alone on `HD-720p`.

One important difference from movies: a lot of those 70 `Any` series are **old cartoons / anime / British comedy** (Looney Tunes 1929, Rugrats, Hey Arnold!, Samurai Jack, Blackadder, Bottom, The Mighty Boosh, Frasier-era stuff). For some of these, a true 1080p release may **not exist** — they only come in 720p or SD. If I set those to `HD-1080p`, Sonarr won't grab anything for episodes that are only available in 720p. The `HD - 720p/1080p` profile is safer there since it *allows* 720p as well as 1080p.

So before I bulk-change anything:

• AskUserQuestion questions 15.5s 235 B

Moving the 70 `Any` series → `HD - 720p/1080p` (id 6), leaving Frasier alone.

• Bash IDS=$(curl -s -m 40 -H "X-Api-Key: 5fab7462bbab4e1fa7d452f9d19ab90c" "https://sonarr.rdx4.com/api/v3/series" | python3 -… 2.6s 142 B

Done. ✅

| Profile | Before | After |
|---|---|---|
| `Any` | 70 | **0** ✓ gone |
| `HD - 720p/1080p` | 146 | **216** (+70) |
| `HD-1080p` | 155 | 155 |
| `HD-720p` (Frasier) | 1 | 1 (left as-is) |

All 70 `Any` series moved to `HD - 720p/1080p`, Frasier untouched. Every series is now on an approved profile — nothing left that could pull cam-rips, SD, or disc rubbish.

Same caveat as Radarr: this only changes what Sonarr will grab *going forward* — existing episode files stay put and won't be re-grabbed unless they fall below the new profile's cutoff and you trigger a search.

A couple of optional follow-ups if you want them:
- **Disc-image scan for Sonarr** — unlikely for TV, but I can sweep all episode files for `BR-DISK` / `.m2ts` / `.iso` the same way I did for movies, just to be sure nothing crash-prone is lurking.
- **Re-scan Radarr** once you've finished dropping in the Dune `.mkv` files, to confirm the library is finally disc-image-free.

Want me to run the Sonarr disc-image sweep?

Yes, that's absolutely a real thing — it's per **quality profile**, controlled by two settings:

- **"Upgrade Until" (`upgradeAllowed`)** — if on, Sonarr keeps searching for better releases of files you already have.
- **Cutoff** — the quality at which it *stops* upgrading. So a 720p file gets replaced when a 1080p shows up, and it stops once it reaches the cutoff.

Let me check exactly how your profiles are configured.

• Bash curl -s -m 20 -H "X-Api-Key: 5fab7462bbab4e1fa7d452f9d19ab90c" "https://sonarr.rdx4.com/api/v3/qualityprofile" | python3… 1.7s 963 B

You're remembering it exactly right — and the answer is **no, it's currently disabled.** In fact there are two things working against you here:

## 1. Upgrades are OFF on every profile
`upgradeAllowed` is **`False`** on all 7 profiles. With upgrades off, once Sonarr has *any* allowed-quality file, it considers that episode "done" and will never look for something better. So a 720p file will just sit there forever even if a 1080p becomes available.

## 2. Even if you turned upgrades on, your main profile would stop at 720p
Look at the cutoff on the profile most of your shows are now on:

| Profile | Upgrades | Cutoff | Issue |
|---|---|---|---|
| `HD - 720p/1080p` (id 6) | ❌ off | **HDTV-720p** | Cutoff is *720p*, so it'd stop the moment it has 720p — never bothering with 1080p |
| `HD-1080p` (id 4) | ❌ off | HDTV-1080p | Cutoff fine, just needs upgrades on |
| `foreign` (id 7) | ❌ off | WEB 1080p | Cutoff fine |

So to get the behaviour you described — *"have 720p, find 1080p, replace it"* — on the `HD - 720p/1080p` profile you need **both**: turn `upgradeAllowed` on **and** raise the cutoff from `HDTV-720p` to `Bluray-1080p` (or `HDTV-1080p`). As-is, it allows 1080p but doesn't *prefer* it.

A few things worth flagging before you decide:

- **It'll generate download activity.** Once enabled, Sonarr's periodic "cutoff unmet" search will start hunting 1080p replacements for every 720p episode you own — that's bandwidth + disk churn. Could be a lot at once across 360+ shows.
- **Radarr is almost certainly the same** — I can check its profiles too; you probably want consistent behaviour.
- The cutoff is "stop upgrading *once you hit this*", not a ceiling on what's allowed. So `cutoff = Bluray-1080p` means "keep upgrading until you get a 1080p Bluray, then stop."

Want me to enable upgrades and fix the cutoffs? If so:

• AskUserQuestion questions 104.3s 281 B

Great question — and the answer is **almost nothing, as it's currently configured.** Here's why.

The `HD-1080p` profile only *allows* three qualities, and its cutoff is the lowest of them:

| Profile `HD-1080p` | |
|---|---|
| Allowed | HDTV-1080p, WEB 1080p, Bluray-1080p |
| Cutoff | **HDTV-1080p** (the lowest) |

The cutoff means *"stop upgrading once you reach this."* Since every file in that profile is already *at least* HDTV-1080p, **everything already meets the cutoff** → turning on upgrades would find nothing to do. No benefit.

It would only matter if you **raised the cutoff** within 1080p. The three 1080p qualities aren't equal — they're ranked by source:

```
Bluray-1080p   ← best (full disc encode, high bitrate)
WEB 1080p      ← streaming rip
HDTV-1080p     ← broadcast capture, lowest of the three
```

So if you set `upgradeAllowed = on` **and** `cutoff = Bluray-1080p`, Sonarr would go replace your HDTV-1080p and WEB-1080p files with **Bluray-1080p** versions when it finds them — same resolution, but a better-quality source. That's the only thing enabling upgrades achieves on this profile.

**So the practical takeaway:**

- **`HD-1080p` profile** → enabling upgrades is pointless *unless* you also want to chase better 1080p *sources* (Bluray over HDTV). Most people don't bother — a WEB 1080p is usually fine. Leave it off unless you're a quality stickler.
- **`HD - 720p/1080p` profile** → this is where upgrades genuinely matter, because you have an actual resolution mix. Enabling upgrades + cutoff = 1080p gets you the "have 720p, replace with 1080p" behaviour you originally described.

Given that, the sensible move is probably **just the `HD - 720p/1080p` profile** (the 216-show one) — enable upgrades and raise its cutoff to 1080p, and leave `HD-1080p` alone since it'd do nothing useful. Want me to do that one?

• Bash curl -s -m 20 -H "X-Api-Key: 5fab7462bbab4e1fa7d452f9d19ab90c" "https://sonarr.rdx4.com/api/v3/qualityprofile/6" > /tmp/… 3.1s 97 B

• Bash curl -s -m 30 -X PUT -H "X-Api-Key: 5fab7462bbab4e1fa7d452f9d19ab90c" -H "Content-Type: application/json" \ -d @/tmp/son… 2.5s 104 B

Done. ✅

**`HD - 720p/1080p` profile (your 216-show profile) is now:**
- **Upgrades:** `On` (was Off)
- **Cutoff:** `Bluray-1080p` (was HDTV-720p)

So from now on, any show on this profile that has a 720p (or HDTV/WEB 1080p) file will get **upgraded toward Bluray-1080p** as better releases turn up, and Sonarr stops once it hits a 1080p Bluray.

**What to expect:**
- Sonarr won't replace everything instantly — it picks up upgrades during its periodic **"cutoff unmet" search** and whenever RSS brings in a matching release. It'll trickle through over hours/days, not all at once.
- If you want to kick it off now, there's a **"Search Monitored"** / cutoff-unmet search you can trigger — but across 216 shows that's a big burst of grabs. I'd let it happen organically unless you want me to fire a targeted search.
- Frasier (`HD-720p`), `HD-1080p`, and the rest are untouched — only this one profile changed.

That wraps the Sonarr side. When you've finished dropping in the Dune `.mkv` files, ping me and I'll re-scan Radarr to confirm it's finally disc-image-free.

Good distinction to nail down, because the three "scan-ish" buttons in Sonarr do very different things:

| Action | What it does | Triggers upgrades? |
|---|---|---|
| **Rescan / disk scan** (refresh library) | Re-reads files on disk to update Sonarr's database | ❌ No — purely metadata, never searches indexers |
| **RSS Sync** (automatic, ~every 15 min) | Checks indexers' recent-releases feed | ⚠️ Partially — auto, but only sees *newly posted* releases |
| **"Cutoff Unmet" search** (you trigger it) | Actively queries indexers for every file below cutoff | ✅ Yes — this is the real upgrade engine |

So to directly answer:

- **A disk scan does *nothing* for upgrades.** It just tells Sonarr what files exist. Safe, no downloads.
- **Upgrades happen automatically — but weakly.** The RSS sync runs on its own and *will* grab an upgrade if a better release for a monitored episode shows up in the recent-releases feed. But RSS only covers what's freshly posted (last day or two of indexer activity). Your existing **back-catalog of 720p files won't be actively hunted** this way — they'd only upgrade if someone happens to re-post a better version and it lands in the feed window.
- **To actually go replace the old 720p stuff**, you have to run a **Cutoff Unmet search** (Wanted → Cutoff Unmet → Search). *That's* the deliberate action that creates a big burst of searches + grabs across all 216 shows.

**So, practically:**
- **Leave it** → you get a slow, gentle trickle. New/airing episodes come in at the best quality, and the occasional old episode upgrades if it reappears in RSS. Zero effort, no bandwidth spike. Good default.
- **Run Cutoff Unmet search** → actively drags your whole 720p back-catalog up to 1080p now, but it's a heavy burst (lots of simultaneous grabs, disk churn, possible indexer rate-limiting).

My recommendation: **leave it on auto.** The settings are correct now, so quality only ever ratchets up over time on its own. Only fire the Cutoff Unmet search if you specifically want to force the existing 720p library up to 1080p in one go — and if so, I'd do it in batches rather than all 216 at once. Want me to leave it, or set up a batched cutoff-unmet search?

Yeah — that's me, sorry. That's a direct consequence of the cutoff I set, and your instinct that it's wrong for you is right.

**Here's what happened:** I set the cutoff to **`Bluray-1080p`** — the *highest* 1080p quality. "Cutoff unmet" means *"every file that isn't yet at the cutoff."* So now Sonarr considers a `WEBDL-1080p` file as **below cutoff** and wants to upgrade it to a Bluray-1080p (same resolution, just a better source). That's why your list is flooded with 1080p files — it's trying to replace every WEB-DL 1080p with a Bluray rip. Loads of churn for basically no visible quality difference.

That's almost certainly **not** what you want. You wanted *"720p → 1080p,"* not *"WEB-DL 1080p → Bluray 1080p."*

**The fix is to lower the cutoff** so that *any decent 1080p already counts as done.* The standard choice is **`WEB 1080p` (WEBDL-1080p)**:

| Cutoff = `WEB 1080p` | Result |
|---|---|
| Have a 720p file | below cutoff → **upgrades to 1080p** ✅ (what you want) |
| Have a `WEB 1080p` file | meets cutoff → **left alone** ✅ (no more churn) |
| Have a `Bluray 1080p` file | above cutoff → left alone ✅ |
| Have an `HDTV-1080p` file | slightly below → may upgrade to WEB/Bluray (rare, and HDTV-1080p is low quality anyway) |

So your cutoff-unmet list would shrink down to mostly just the **actual 720p files** — the ones you genuinely want bumped to 1080p — and stop nagging about WEB-DL-1080p-to-Bluray.

Quick note on Sonarr's quirky ranking, so the behaviour isn't surprising: Sonarr ranks `WEB 1080p` and `Bluray 1080p` *above* the 720p qualities (good), but it ranks plain `HDTV-1080p` oddly low — below `Bluray-720p`. In practice this almost never matters because HDTV-1080p files are rare. The `WEB 1080p` cutoff is the clean, common-sense setting.

Want me to drop the cutoff from `Bluray-1080p` to `WEB 1080p`? That keeps the "replace 720p with 1080p" behaviour you wanted and kills the pointless WEB→Bluray upgrade storm.

• Bash curl -s -m 20 -H "X-Api-Key: 5fab7462bbab4e1fa7d452f9d19ab90c" "https://sonarr.rdx4.com/api/v3/qualityprofile/6" > /tmp/… 1.6s 113 B

Name mismatch — let me check the exact quality names in the profile.

• Bash python3 -c " import json p=json.load(open('/tmp/sonarr_prof6.json')) def walk(items,depth=0): for it in items: if it.get… 1.4s 915 B

The quality is named `WEBDL-1080p` (id 3), not "WEB 1080p". Setting cutoff to that:

• Bash python3 -c " import json p=json.load(open('/tmp/sonarr_prof6.json')) p['cutoff']=3 json.dump(p,open('/tmp/sonarr_prof6_n… 2.6s 93 B

Still 400 — let me see the actual error.

• Bash curl -s -m 30 -X PUT -H "X-Api-Key: 5fab7462bbab4e1fa7d452f9d19ab90c" -H "Content-Type: application/json" \ -d @/tmp/son… 1.6s 348 B

The 400 says "must be an allowed quality **or group**." In Sonarr, qualities can be bundled into groups, and if `WEBDL-1080p` is inside a group, the cutoff has to reference the *group's* id, not the quality's. Let me inspect the structure.

• Bash python3 -c " import json p=json.load(open('/tmp/sonarr_prof6.json')) for it in p['items']: if it.get('items'): # this is… 1.4s 423 B

Found it — `WEBDL-1080p` lives inside the **"WEB 1080p" group (id 1002)**. That's the group I need to set as cutoff. (This is also why the display name showed "WEB 1080p" earlier.)

• Bash python3 -c " import json p=json.load(open('/tmp/sonarr_prof6.json')) p['cutoff']=1002 json.dump(p,open('/tmp/sonarr_prof… 2.0s 98 B

Done. ✅

**`HD - 720p/1080p` profile is now:**
- **Upgrades:** `On`
- **Cutoff:** `WEB 1080p` (the WEBRip/WEBDL-1080p group)

Now the behaviour matches what you actually want:

| You have... | What happens |
|---|---|
| A **720p** file | upgrades → 1080p ✅ |
| A **WEB 1080p** file | meets cutoff → **left alone** (no more WEB→Bluray churn) |
| A **Bluray 1080p** file | above cutoff → left alone |

So your **Cutoff Unmet list should now collapse down to just the genuine 720p (and any odd HDTV-1080p) files** — the WEB-DL 1080p flood is gone. You may need to refresh the Wanted → Cutoff Unmet page for it to recalculate.

As before, the settings are now correct and it'll trickle 720p→1080p upgrades on its own via RSS — no need to force a mass Cutoff Unmet search unless you want to drag the whole back-catalog up immediately.

That's Sonarr sorted. Whenever you've finished the Dune `.mkv` swap, give me a shout and I'll re-scan Radarr to confirm it's disc-image-free.

Good — let me check the Sonarr history. On a clean upgrade, every import should be paired with an "episode file deleted (reason: Upgrade)" event for the old file. If those deletions are present, the old 720p is being removed, not stacked.

• Bash curl -s -m 30 -H "X-Api-Key: 5fab7462bbab4e1fa7d452f9d19ab90c" "https://sonarr.rdx4.com/api/v3/history?pageSize=200&sort… 32.3s 205 B

Positive sign — there are **15 "episodeFileDeleted" events, all reason `Upgrade`**, which means Sonarr *is* deleting old files on upgrade. But there are 61 imports vs only 15 deletions, so let me make sure the gap is just first-time grabs (new episodes that had no old file) and not upgrades silently leaving duplicates. I'll correlate by episode.

• Bash curl -s -m 30 -H "X-Api-Key: 5fab7462bbab4e1fa7d452f9d19ab90c" "https://sonarr.rdx4.com/api/v3/history?pageSize=250&sort… 2.3s 3.3 KB

The 41 imports-without-deletion are almost all **brand-new / currently-airing episodes** — Legend of Vox Machina S04, Clarkson's Farm S05, Euphoria S03, The Boys S05E08, the entire new S01 of Widows Bay, current Taskmaster/Bob's Burgers/Family Guy seasons. Those had no prior file, so there's nothing to delete — they're first-time RSS grabs, not upgrades. Not duplicates.

The actual **upgrades** (back-catalog 720p→1080p from your mass search) are the 16 that each paired with an `Upgrade` deletion. Let me verify those definitively — each upgraded episode should now have exactly **one** file, at the new quality — and check Sonarr's health for any orphan/undeletable-file warnings.

• Bash API="5fab7462bbab4e1fa7d452f9d19ab90c"; H="https://sonarr.rdx4.com" # Get the episodeIds that had a clean Upgrade deleti… 4.4s 1.6 KB

**Answer: it's replacing, not duplicating.** ✅ Every upgraded episode shows exactly **one** file at the new 1080p quality — Sonarr deleted the old 720p as part of each import (the 18 `Upgrade` deletions confirm it). There are no stacked duplicates. (Sonarr also structurally tracks only one file per episode, so the risk is only ever an *orphan* left on disk — and the matching deletions show that's not happening.)

One anomaly worth a look: **epId 27468 (S01E02)** shows `hasFile=False` — it had an `Upgrade` deletion but currently has no file. That's the opposite of a duplicate (a *missing* file, not a doubled one). Let me check what happened there.

• Bash API="5fab7462bbab4e1fa7d452f9d19ab90c"; H="https://sonarr.rdx4.com" python3 -c " import json,urllib.request api='$API'; … 1.8s 835 B

False alarm — that one's now resolved itself. I caught it mid-upgrade. Its history shows a textbook clean replacement, all in the last few minutes:

```
2023-10-12  imported 720p (EDITH)          ← the old file
2026-06-03 14:06  grabbed 1080p
2026-06-03 14:10:13  deleted old file (Upgrade)
2026-06-03 14:10:26  imported new 1080p
```

My earlier check landed in the **13-second gap** between Sonarr deleting the old file (14:10:13) and writing the new one (14:10:26). Re-fetching now shows `hasFile=True` with the 1080p file in place. That actually confirms the exact order Sonarr uses: **delete old → import new**, so there's never a lasting duplicate, just a momentary no-file window during the swap.

## Verdict
Your upgrades are working perfectly — **replacing, not duplicating:**

- ✅ 18 back-catalog episodes upgraded so far, each paired with an `Upgrade` deletion of the old 720p
- ✅ Every upgraded episode now has **exactly one** file, at 1080p
- ✅ No orphaned/duplicate files, no health warnings about untracked files
- The 41 imports without deletions were all **new/airing episodes** (first grabs), not upgrades — correctly no old file to remove

So you can let the mass search run with confidence; it's cleanly swapping 720p → 1080p.

Two unrelated things the health check surfaced, for when you have a minute (not urgent):
- **SABnzbd is downloading into a root folder** (`/downloads`) — Sonarr flags this as risky; better to point it at a subfolder like `/downloads/complete`.
- **3 series were removed from TheTVDB** (Godspeed, The Wonderfully Weird World of Gumball, Monster: The Ed Gein Story) — they'll stop getting metadata/episode updates. Worth checking if they need re-mapping.

Want me to dig into either of those, or are we good here?

Good thing to check — and "MULTI" releases (like that Usher one earlier: `...MULTI.1080p.WEB...`) are exactly the culprit; MULTI usually means a German-primary release with multiple audio tracks. Let me look at how language is configured. In Sonarr v4 (you're on v4.0.17), language is controlled in three places: the **quality profile's Language field**, **Custom Formats** (scoring), and legacy **Release Profiles** (ignored/required words). Let me read all of them.

• Bash API="5fab7462bbab4e1fa7d452f9d19ab90c"; H="https://sonarr.rdx4.com" echo "============ QUALITY PROFILES: language + cust… 1.9s 825 B

Okay, I've got the full picture. Here's what's actually configured — and I can see exactly why German is leaking through.

## What you have now

**1. There IS an English filter — but only as one Custom Format:**
- A custom format called **`Language: Not English`** = a *Language* spec set to English with **negate ON** (i.e. "matches anything that is NOT English"), scored **−10000**.
- Your profiles have **Minimum Custom Format Score = 0**, so a release scoring −10000 falls below the minimum and gets rejected. That's the intended block.

**2. It's only applied to 3 of your 7 profiles:**

| Profile | "Not English" filter? |
|---|---|
| `HD-1080p` (155 shows) | ✅ yes |
| `HD - 720p/1080p` (216 shows) | ✅ yes |
| `Any` | ✅ yes (but no shows on it now) |
| **`HD-720p`** (Frasier) | ❌ **no filter** |
| `SD`, `Ultra-HD` | ❌ no filter (unused) |
| `foreign` | ❌ no filter (intended — 0 shows on it) |

**3. Profile "Language" field is unset (`None`/Any) on all profiles** — so you're relying entirely on that one custom format, not on Sonarr's profile-level language preference.

**4. No Release Profiles at all** — nothing ignoring the words "GERMAN", "MULTI", etc.

## Why German still gets through

The filter is built as **"NOT English"**, and that's the flaw. The German stuff you're getting is almost always tagged **`MULTI`** (like that `...Usher...MULTI.1080p.WEB...` grab earlier). A MULTI release contains *multiple* audio tracks — including an English one — so when Sonarr parses it, it sees English **is** present. That means the release is *not* "Not English" → the −10000 penalty **doesn't apply** → it sails through and gets grabbed… even though the **default/primary audio is German**.

So your filter correctly blocks pure-German releases, but **MULTI/dual-audio releases (the main source of your German files) slip past it entirely.** Frasier has no filter at all.

Let me confirm that's really what's happening rather than just theorising — I'll scan your recent grabs for MULTI/German tags:

• Bash API="5fab7462bbab4e1fa7d452f9d19ab90c"; H="https://sonarr.rdx4.com" curl -s -m 30 -H "X-Api-Key: $API" "$H/api/v3/histor… 6.8s 2.9 KB

Confirmed — and the data makes the diagnosis airtight. One caveat: my "149 flagged" count is inflated because my regex caught `WEB-DL` (the "DL"). Ignore that number. The meaningful signal is the **parsed-language distribution**, and it's the smoking gun:

> **Across the last 250 grabs: English = 250, German = 11, Italian = 3**

**Every single grab — all 250 — is tagged "English" by Sonarr.** That's the whole problem in one line. The German and foreign releases (`MULTI`, `DUAL`, German `.DL.`) all bundle an English track, so Sonarr parses English *as present*, and your `Language: Not English` filter — which only fires when English is **absent** — never triggers on them. The 11 German-tagged and 3 Italian-tagged grabs carry that foreign audio **and** English, so they passed straight through despite the filter.

You can see it live above: `Common.Side.Effects...MULTI...` releases got grabbed; the `Slow.Horses...ITA.ENG...` got grabbed with `[Italian,English]`.

## Summary of the problem

| # | Issue |
|---|---|
| 1 | The filter is **"NOT English"** — it only blocks releases with *zero* English. MULTI/DUAL/`.DL.` releases all include English, so they're never caught. This is the main German leak. |
| 2 | It's a **negate-English** approach, when what you want is to **block German/foreign explicitly** (or block the MULTI/DL tags). |
| 3 | **Frasier** (`HD-720p`) has **no language filter at all**. |
| 4 | Profile-level **Language field is unset** everywhere — you're leaning entirely on that one custom format. |
| 5 | No **Release Profiles** ignoring `GERMAN` / `MULTI` / `.DL.` as a backstop. |

## What would actually fix it (for when you want changes)

The robust approach is to flip the logic — block the unwanted stuff explicitly rather than requiring English-absence:

- **A "German" Custom Format** (Language spec = German, *not* negated) scored −10000. Because MULTI carries German, this catches the dual-audio releases the current filter misses.
- **A title-tag Custom Format** matching `\bMULTI\b`, `\bGERMAN\b`, and the German scene tag `\bDL\b` (in scene naming `.DL.` literally means "Dual Language" = German+English) — also −10000. This is the real backstop, since it keys off the release name, not the ambiguous parsed audio.
- **Apply both to all English profiles** (`HD-1080p`, `HD - 720p/1080p`, and `HD-720p` for Frasier) — but **deliberately NOT** on the `foreign` profile.
- **Route your foreign shows** (anime, etc.) onto that `foreign` profile so they're exempt from the English-only rules — that handles your "unless it's a pure foreign show" requirement cleanly.

One thing to decide when you're ready: for anime specifically, do you want **English dub** or **original Japanese audio + English subs**? That changes whether anime should block German-MULTI but allow Japanese, which is a slightly different CF setup. But no changes made — this is just the lay of the land. Want me to draft the exact custom formats next, or leave it here?

Ah, that changes the diagnosis — and it's an important distinction. You don't have a *blocking* problem, you have a **scoring/preference** problem. Let me re-frame what's actually going on, because it's subtler than "German gets through."

## The real issue: nothing tells Sonarr to *prefer* English

Look at how your two CF scenarios actually score:

| Release for an episode | `Language: Not English` (−10000)? | Final CF score |
|---|---|---|
| English-only (`...AMZN.WEB-DL...`) | doesn't fire (English present) | **0** |
| MULTI / German `.DL.` (English + German) | doesn't fire (English present) | **0** |
| Pure German (no English) | fires | −10000 → rejected |

So an English release and a German-MULTI release **both score exactly 0.** There is nothing in your config that says "English is better than MULTI." When two releases tie on score *and* quality, Sonarr falls back to tie-breakers — indexer priority, release age, who showed up in the RSS feed first, size. German scene groups (the `.DL.` dual-language releases) tend to post **fast and large**, so they frequently win that coin-flip and get grabbed before the clean English one appears. That's why it *feels* like German is being prioritised — effectively it's arbitrary, and the German release often happens to win.

Your `−10000` filter is doing its one job (it blocks *zero*-English releases — and indeed all 250 recent grabs have an English track, so nothing pure-foreign is sneaking in). It just was never designed to express a *preference*.

## The fix is preference, not blocking

To make English win **without blocking foreign releases**, you add a **positive** score to clean-English releases, and leave the foreign ones at 0:

| Release | New CF score | Outcome |
|---|---|---|
| Clean English (no MULTI/DL/foreign tag) | **+50** | wins when available ✅ |
| MULTI / German `.DL.` | 0 | only grabbed if no English exists |
| Pure foreign (no English) | 0 or low | still available as last resort |

Because the foreign release stays at **0** (≥ your minimum score of 0), it's **never blocked** — it just loses to English whenever an English release exists for that episode. Exactly the behaviour you described wanting.

The mechanism: a custom format that matches "**has English audio AND release name does *not* contain `MULTI` / `DUAL` / `.DL.` / `GERMAN` / `ITA` / `VOSTFR`...**" → that's a clean single-language English release → give it +50. MULTI releases fail the "no foreign tag" half, so they stay at 0.

Before I draft the actual custom formats, two things that change the design:

• AskUserQuestion questions 80.7s 346 B

Perfect — that fully defines the design. Here's the plan I'd build. Two different behaviours for two different profile groups:

## Group A — your English profiles (`HD-1080p`, `HD - 720p/1080p`, and `HD-720p`/Frasier)

**Goal: prefer clean English, but still grab MULTI/foreign if that's all there is.**

Since your minimum-format-score is 0 and you want foreign to *never* be blocked, the trick is to **reward English positively** rather than penalise foreign (a penalty would push foreign below 0 and block it). So:

| Custom Format | What it matches | Score |
|---|---|---|
| **Preferred English** | release has English audio **AND** title has no foreign/dual tag (`MULTi`, `DUAL`, `GERMAN`, `ITA`, `VOSTFR`, `TRUEFRENCH`, `.DL.`, etc.) | **+15** |
| *(keep)* `Language: Not English` | zero-English releases | leave as is, or relax to −15 if you'd rather *those* be a last resort too |

Result: clean English = **+15**, MULTI-German = **0**, pure-foreign = **0** (or −15). English wins every time both exist; foreign is still grabbed when it's the only option. Nothing is blocked. This is exactly the "stop prioritising German" behaviour you want.

## Group B — the `foreign` profile (anime + shows you route there)

**Goal: prefer dub + original audio + subs** — i.e. **Dual-Audio** releases.

| Custom Format | What it matches | Score |
|---|---|---|
| **Dual Audio** | title tags `Dual.Audio`, `DUAL`, `Multi.Audio`, `DUBBED+SUB` etc. | **+15** |

Here MULTI/dual is *desirable*, so the Group A anti-foreign logic is deliberately **not** applied. You'd assign your anime/foreign shows to this profile (right now 0 shows are on it).

---

**One honest caveat before I touch anything:** the fiddly part is the regex that detects the foreign/dual scene tags — especially the German `.DL.` (Dual Language) tag, which naively matches the `DL` inside `WEB-DL` and would cause false positives. Rather than hand-roll fragile regex, I'd strongly recommend basing these on the **TRaSH-Guides** battle-tested custom-format definitions (they maintain exactly these "MULTi", "Language", and "Dual Audio" CFs with the lookbehind tricks already solved). I can pull those definitions and adapt the scores to your prefer-don't-block setup.

So, two decisions for you:
1. **Build it on TRaSH-Guides definitions** (recommended, robust) or **hand-rolled CFs** (simpler to read, more fragile)?
2. **Ready for me to make the changes now**, or do you want to see the exact custom-format JSON first before I create anything?

(Still zero changes made so far — everything above is just the plan.)

On it. Let me pull the actual TRaSH-Guides custom-format definitions for Sonarr so we're working from their real JSON, not my approximation.

• Bash echo "=== Listing TRaSH-Guides Sonarr custom-format files ===" curl -s -m 30 "https://api.github.com/repos/TRaSH-Guides/… 1.1s 1.8 KB

Good — TRaSH has exactly what we need. The key ones for your setup:
- **`multi.json`** — catches `MULTi` releases (your main leak)
- **`german-dl.json`** — catches the German `.DL.` Dual-Language tag (the WEB-DL false-positive solved)
- **`anime-dual-audio.json`** — for the `foreign` profile (dub + original + sub)
- **`language-not-english.json`** — their version of what you already have

Let me fetch the actual definitions so you can see exactly what we'd import.

• Bash BASE="https://raw.githubusercontent.com/TRaSH-Guides/Guides/master/docs/json/sonarr/cf" for f in multi german-dl anime-d… 3.0s 3.0 KB

Now I've got the real TRaSH specs. Here's the full plan, with the exact JSON I'd POST to your Sonarr.

## The 3 custom formats to import

Let me show you the complete JSON verbatim (these are TRaSH's definitions, unmodified):

• Bash BASE="https://raw.githubusercontent.com/TRaSH-Guides/Guides/master/docs/json/sonarr/cf" for f in multi german-dl anime-d… 1.7s 3.1 KB

That's the real TRaSH JSON. Here's the complete plan built around it.

## What gets imported vs reused

| Custom Format | Source | Status |
|---|---|---|
| `MULTi` | `multi.json` (above) | **new import** |
| `German DL` | `german-dl.json` (above) | **new import** |
| `Anime Dual Audio` | `anime-dual-audio.json` (above) | **new import** |
| `Language: Not English` | — | **reuse the one you already have** (TRaSH's is identical) |

*(Note: I'd import the JSON but strip TRaSH's `trash_scores`/`trash_id` — those are just their metadata; we set our own scores below.)*

## Scoring — Group A: English profiles (`HD-1080p`, `HD - 720p/1080p`, **and** `HD-720p`/Frasier)

| Custom Format | Score |
|---|---|
| `MULTi` | **−25** |
| `German DL` | **−25** |
| `Language: Not English` | **−10000** (keep as hard block — see decision below) |
| **Minimum Custom Format Score** | **−50** (changed from 0) |

How that ranks releases for one episode:

| Release | Score | Result |
|---|---|---|
| Clean English (`AMZN.WEB-DL`) | **0** | ✅ wins whenever it exists |
| `MULTi` (Eng + German) | −25 | grabbed only if no clean English |
| German `.DL.` dual | −25 to −50 | fallback below MULTi-only |
| Pure German, zero English | −10000 | ❌ still hard-blocked |

The lowered −50 floor is what lets MULTi/dual still get grabbed (so episodes never go missing), while the 0-vs-−25 gap is what finally tells Sonarr **"English is better than German."** That's the fix for your actual complaint.

## Scoring — Group B: the `foreign` profile (anime + shows you route there)

| Custom Format | Score |
|---|---|
| `Anime Dual Audio` | **+50** (prefer dub + original + subs) |
| `MULTi` / `German DL` | **0** (deliberately *not* penalised here) |
| **Minimum Custom Format Score** | **0** (unchanged) |

So on the foreign profile, dual-audio anime releases are *preferred*, and nothing is penalised for being multi-language — exactly your "dub + original + sub" goal. You'd then assign anime shows to this profile (0 are on it today).

## One decision for you

The only real judgment call is the **pure-zero-English** case (a release with *German only, no English track at all*):

• AskUserQuestion questions 138.1s 210 B

Locked in. Here's the **final, complete change set** — exactly what I'll do when you say go:

### Create 3 custom formats (TRaSH JSON, scores stripped)
- `MULTi`, `German DL`, `Anime Dual Audio`

### Update profiles

**`HD-1080p`** (155 shows)
- MULTi = −25, German DL = −25, Language: Not English = −10000 *(already there)*
- Min Custom Format Score: 0 → **−50**

**`HD - 720p/1080p`** (216 shows)
- MULTi = −25, German DL = −25, Language: Not English = −10000 *(already there)*
- Min Custom Format Score: 0 → **−50**

**`HD-720p`** (Frasier)
- Add Language: Not English = −10000 *(currently missing)*, MULTi = −25, German DL = −25
- Min Custom Format Score: 0 → **−50**

**`foreign`** (0 shows currently)
- Anime Dual Audio = **+50**
- No MULTi/German penalty; Min score stays 0

### Untouched
- `Any`, `SD`, `Ultra-HD` profiles — left as-is (unused)
- No series reassignments — I'm **not** moving anime onto the `foreign` profile automatically (you'll want to pick which shows; I can help with that as a separate step)

### Net effect
English releases outrank MULTi/German for every normal show; dual-audio still gets grabbed so nothing goes missing; pure-German-no-English stays blocked; anime on the `foreign` profile prefers dub+original+sub.

**One heads-up:** this only changes *future* grabs and *upgrade* decisions. Your existing German files won't be replaced unless those episodes get re-evaluated (e.g. a cutoff-unmet search) — and since the German files are usually already at 1080p, an upgrade search won't swap them just for language. If you want to actively replace existing German files later, that's a separate targeted job.

Ready for me to apply it? Reply **go** and I'll create the formats and update the four profiles, then verify each one.

Good eye — and it's worth unpacking, because they're **not actually the same thing**, even though I gave them the same score.

## They detect different things

| CF | How it detects | Catches |
|---|---|---|
| `MULTi` | **release title** contains the `Multi` tag | *any* multi-audio release — English+German, English+French, English+Spanish, etc. A generic catch-all. |
| `German DL` | **parsed languages**: German **AND** original-language present | specifically **German dual-language** releases (German + the show's original audio) |

So they overlap but aren't identical: a `MULTi` tag with no German (say English+French) is caught by `MULTi` only; a release Sonarr parses as German-dual but *without* the literal "Multi" word is caught by `German DL` only; and a German release tagged "Multi" is caught by **both** → stacks to **−50**.

## Does the same score matter?

For your **main goal — clean English beating everything — no, it doesn't matter at all.** Clean English is `0`; both of these are `−25`; English wins regardless.

The score *difference* between them would only matter in the **fallback case**: no clean English exists, and Sonarr is choosing *between* a generic MULTi and a German-DL release. With both at −25, it treats them as equally (un)desirable and falls back to other tie-breakers. A German-multi (caught by both) sits lowest at −50, which is arguably correct.

## So you've got a choice

I set them equal because your goal was just "English first." But if you have a *preference among the foreign fallbacks*, we can split them:

| Option | MULTi | German DL | Effect |
|---|---|---|---|
| **A — equal (my draft)** | −25 | −25 | Simple. English wins; German-multi stacks to −50 (lowest). Fine for "English first." |
| **B — German penalised harder** | −10 | −25 | When no English exists, a generic/French/Spanish MULTi is preferred *over* a German one. Reflects "German is the specific annoyance." |

Option A is perfectly fine and simpler. I'd lean **B** only if German specifically is the thing you most want to avoid even among fallbacks — which, given how this started ("lots of stuff seems to be German"), might actually match your gut.

Which do you want — keep them equal (A), or weight German heavier (B)? (And if B, I'd drop the min score to −60 so a stacked German-multi at −35 still clears it as a last resort.)

Option B it is. Applying everything now. First let me capture the exact schema Sonarr expects (by reading your existing custom format) and the current profile bodies, so the writes are well-formed.

• Bash API="5fab7462bbab4e1fa7d452f9d19ab90c"; H="https://sonarr.rdx4.com" echo "=== Existing 'Language: Not English' CF (exact… 1.9s 10.9 KB

Schema captured (existing "Language: Not English" is `id=2`). Now creating the 3 custom formats from the TRaSH JSON — stripping their metadata and normalizing the field format for the API.

• Bash API="5fab7462bbab4e1fa7d452f9d19ab90c"; H="https://sonarr.rdx4.com" python3 << 'PYEOF' import json, urllib.request API="… 2.2s 170 B

All three created (`MULTi`=3, `German DL`=4, `Anime Dual Audio`=5; existing `Language: Not English`=2). Now updating the four profiles with the Option-B scores and min-score floor.

• Bash python3 << 'PYEOF' import json, urllib.request API="5fab7462bbab4e1fa7d452f9d19ab90c"; H="https://sonarr.rdx4.com" def g… 1.5s 433 B

Done — all applied and verified. ✅

## Final state

**English profiles** (`HD-1080p`, `HD - 720p/1080p`, `HD-720p`/Frasier):
| Custom Format | Score |
|---|---|
| `Language: Not English` | −10000 (hard block, zero-English) |
| `German DL` | −25 |
| `MULTi` | −10 |
| **Min CF Score** | **−60** |

**`foreign` profile:**
| Custom Format | Score |
|---|---|
| `Anime Dual Audio` | +50 |
| **Min CF Score** | 0 |

## How releases now rank (English profiles)

| Release | Score | Outcome |
|---|---|---|
| Clean English | **0** | ✅ always wins |
| MULTi (non-German) | −10 | fallback |
| German DL | −25 | lower fallback — German loses to other MULTi |
| German + MULTi tag | −35 | bottom of the grabbable pile |
| Pure German, no English | −10000 | ❌ blocked |

So English wins everywhere, German is now the *least*-preferred fallback (Option B), nothing playable gets blocked except pure-no-English, and anime on the `foreign` profile prefers dub+original+subs.

## Two things to note

1. **This affects future grabs/upgrades only.** Existing German files stay put — they won't be swapped just for language, since they're usually already 1080p (an upgrade search compares quality, not language preference). If you want to actively hunt-and-replace existing German files, that's a separate targeted job — doable, but it'd mean forcing re-grabs.
2. **No anime is on the `foreign` profile yet** (0 shows). The dual-audio preference only kicks in once you assign your anime/foreign shows there. I can help you pick and bulk-move them whenever you like.

Want to tackle assigning anime to the `foreign` profile next, or are we good for now?