SKYHOUSE.dev Journal

Why: Refusing BR-DISK on 2026-08-09 promoted Remux-2160p to the top of the profile — an 82 GB median — so the fix for one bad default handed us a worse one. Damien also asked whether standardising on x265 would doom the box to permanent realtime transcoding.

1. The transcoding question, answered by the hardware

The fear was reasonable and the answer is mostly no. The box carries an i5-11600KF — the F means no integrated graphics, so no Quick Sync — but a discrete GTX 1050 Ti (GP107, Pascal) is present with the nvidia driver loaded, and Plex's own log proves it is being used rather than merely configured:

hardware transcoding   8
nvdec                  6      HEVC decode on the GPU
nvenc                  5      H.264 encode on the GPU

Transcode scratch already lives at /media/scratch/transcode on the Kingston SSD with 85 GB free — not the root disk, so heavy transcoding cannot re-run the 2026-08-03 full-root incident. Nothing to fix there.

The real exposure was a setting nobody had looked at. Plex stores only non-default values, and there were exactly two: the scratch path, and TranscodeCountLimit="0" — unlimited simultaneous transcodes. Past the GPU's session or VRAM ceiling Plex does not refuse a stream; it silently falls back to CPU software encoding, and three concurrent 4K software transcodes on a six-core with no Quick Sync would flatten the box and everything else on it. Set to 3, which converts whole-server degradation into an explicit "no capacity" for the one stream that cannot be served.

A correction made the same session. Seeing 886 MiB of VRAM consumed at idle, the first read was that shutting down the desktop session would buy back a whole 4K transcode slot. Measuring it properly: Xorg 261 MiB, gnome-shell 53, the remote-desktop daemon only 47, plus ~230 MiB of accumulated browser/editor/file-manager clutter. Reclaiming all of it moves 3,145 MiB free to ~3,700 — still 2 comfortable 4K HDR tone-mapped transcodes at ~1.25 GB each, not 3. The desktop is not the bottleneck, and Damien runs sessions locally for good reason (SSH has been unreliable for long unattended runs). The effective lever is fewer enormous HDR files, not fewer browser tabs.

2. What the external research got right, and wrong

Damien ran a client-compatibility research prompt in parallel. Its useful contributions: the audio/subtitle death spiral (an unsupported audio track forces audio transcoding, and subtitles on top escalate that to a full video transcode), and the confirmation that Chromecast gen 1–3, Fire TV gen 1 and the 2013 Xbox One lack HEVC decode hardware permanently — no software update will ever fix those.

Three claims did not survive checking. "Firefox 134 (January 2026)" is internally inconsistent — Firefox 134 shipped January 2025. "Apple TV HD: Direct Play (software)" is doubtful; that is an A8 with no hardware HEVC decoder. And the headline "12 concurrent NVENC sessions" could not be verified locally at all — there is no way to query the cap from the driver. It also did not matter, because the same answer contained the binding constraint: VRAM caps you at 2–3 simultaneous 4K HDR tone-mapped transcodes regardless of the session limit. The number to size against was in the answer, just not in the headline.

3. The tier is not the thing being selected

Damien's instinct was to rank WEBDL above Bluray. Measured against his own library he is right — WEBDL-2160p median 5.9 GB vs Bluray-2160p 8.1 GB — but the reason is not what the tiers suggest:

WEBDL-2160p has the smaller median but the wider spread, because the tier contains two unrelated things: YTS x265 encodes at ~5 GB and untouched Amazon/Netflix pulls at 25 GB. The quality tier cannot express the preference; the encode can. YTS/YIFY files are 505 of 1,548 in this library — a third — and the same taste shows up under both Bluray and WEBDL labels.

4. What was actually set

Two native Radarr controls, both entirely unused before today: every 2160p tier was maxSize unlimited, and there were zero custom formats defined.

Capping Remux is a de facto ban and is recorded as such: an 82 GB median against a 13.2 GB ceiling means no Remux will ever qualify again. That was Damien's explicit call, but the profile still displays Remux as allowed, so the ban is real and invisible — worth knowing before someone wonders why Remux never appears.

Also set: Provider:Default:FinishedAction from 3 to 1 (Remove From Client And Provider) on both rdt-client instances, so finished torrents stop accumulating in the TorBox dashboard. Safe because FinishedAction fires only once files are already local — the arr imports from staging, not from TorBox — and it additionally prevents the DIFF_ISSUE duplicate-add. Evidence the cache is global, not per-account: the account held 5 torrents while 13 of 46 candidate releases for one film reported cached, so clearing the account costs nothing in instant availability.

5. The trade-off the caps introduce

Caps do not only trim fat; sometimes they drop resolution. Verified on a real title: before the caps, Harry Potter and the Chamber of Secrets would have taken a 19.1 GB Bluray-2160p. After, every cached 2160p option exceeds 13.2 GB, so the pick falls to a 6.0 GB WEBDL-1080p H265. A third of the size, and no longer 4K. On a box being reclaimed for photos that is the right trade, but it is a trade and the knob is one number.

6. Two API gotchas

• The bulk PUT /api/v3/qualitydefinition/update silently no-ops while returning 202. Only per-item PUT /api/v3/qualitydefinition/{id} actually applies. Caught only by reading the values back — the same discipline that caught rdt-client's unconditional 200 on 2026-08-04.
• The quality-definition fields are minSize / preferredSize / maxSize, not min/preferred/max. Reading with the wrong names returns None for everything and looks exactly like "no caps configured".

Refusing raw disc rips promoted an 82 GB tier to the top. The fix was not another ban but telling Radarr, for the first time, what size a good file actually is.