Lemonfiber
← The specification

Quality presets in plain language

Rendered from spec at76d46f3 (2026-10-25) · its source · Edit this page

Status: Accepted · Audience: Operator · Area: D — Content & household

Purpose

Let someone choose what quality they want without learning what a custom format is.

Quality configuration is the deepest rabbit hole in this ecosystem. The TRaSH guides — excellent, and the community standard — run to dozens of pages covering custom formats, scoring, release groups, and repack handling. Configuring it properly by hand takes an evening and real domain knowledge.

The operator’s actual question is much simpler: how good should this look, and how much disk am I willing to spend? Everything else is implementation.

Behaviour

The question is asked in the operator’s terms

Preset Means Roughly
Space-saving Good enough on a laptop or tablet 720p–1080p, smaller encodes
Balanced (default) Looks right on a TV, sensible file sizes 1080p, good encodes
High quality Best 1080p available, size secondary 1080p, high-bitrate
Maximum 4K where it exists, HDR preserved 2160p, very large files

Each preset states its practical consequence — approximate size per hour and whether a typical client will need to transcode — because that’s what the choice actually costs.

What may be chosen is the stack’s vocabulary, so the quality reading carries it: the presets on offer, the formats music may take, and the kinds of media a preset may be chosen for. A surface offers those and nothing of its own, and a list kept anywhere else goes stale the day the stack’s own list changes (D2-R13).

Presets map to community-maintained profiles

Presets are a friendly surface over Recyclarr’s TRaSH-guide profiles, not a parallel quality system. The community maintains the hard part; lemonfiber translates the question.

This matters for durability: when release-group scoring shifts, the upstream guides update and Recyclarr syncs it. A bespoke scoring system would rot.

Transcoding consequences are stated up front

Choosing Maximum on a machine that cannot hardware-transcode means every household member watching on a device that can’t direct-play 4K HDR will hit CPU-bound transcoding — which on Docker for macOS or Windows means it will not work well.

lemonfiber knows the platform and the Jellyfin mode (ADR-0007), so it can say this before the choice rather than after the complaints.

Per-type overrides, without leaving plain language

Different presets per media type are supported — Maximum for film, Balanced for television is a common and sensible split, since a series is many times the volume of a film.

The full depth remains reachable

Presets are a starting point, not a ceiling. An operator who wants to hand-tune custom formats does so directly in the *arr, and C9 protects that work from being reverted.

Changes are forward-looking

Changing a preset affects future acquisitions. It does not retroactively upgrade an existing library unless the operator explicitly asks for that — which is a large, bandwidth-expensive operation and must never be a side effect.

Both halves are said by the stack in its machine-readable answers. A choice says that it shapes what is fetched next and changes nothing already here (D2-R14), and an upgrade says what it costs in total for each kind of media, worked out from what the library holds, or that it could not be worked out. A rate per hour is not a cost, and a surface that multiplied one by a guess at the library’s length would be estimating what the stack can read (D2-R15).

On the companion

Transcoding is a property of the machine, not of the preset, and N8-R2 requires the app to keep the two apart (N8). Maximum is not a preset that transcodes; it is a preset that will transcode here, on this hardware in this Jellyfin mode. Rendered as a property of the preset, it becomes a caution that follows the operator to a machine where it is untrue — and the app is the surface most likely to be read somewhere other than in front of the machine it describes.

The operator’s question — how good should this look, and how much disk am I willing to spend? — is only half answered by a name and a resolution, so N8-R1 requires a choice shown with what an hour of it costs in space. On a phone that figure is the choice, and the name is a label on it.

Per-type overrides mean there is rarely a single answer to show, and a set of choices that could not be read is told apart from there being none (N8-R9).

States

State Meaning
unset No preset chosen; *arr defaults in force
applied Preset synced and active
overridden Per-type presets differ from the global choice
customised Operator has hand-edited profiles; preset no longer authoritative
sync-failed Preset could not be applied

Edge cases

Situation Behaviour
Maximum chosen without hardware transcoding State the consequence for household playback before confirming.
Preset chosen with limited disk Project storage need against free space and warn if implausible.
Operator hand-edited profiles Report customised; do not overwrite. Applying a preset then requires explicit consent.
Upstream guides changed Sync on schedule; report meaningful changes rather than applying silently.
Upstream unreachable Keep the current profiles; report that sync is stale. Never fall back to unconfigured.
Preset lowered after building a library Affects future grabs only. State this explicitly — the expectation is often the opposite.
Operator wants existing content upgraded Supported as an explicit, separate action with its bandwidth and time cost stated.
Media type has no meaningful preset Books and audiobooks have different quality axes; present format preferences instead of resolution.
Preset conflicts with an indexer’s available releases Report that few or no releases match, distinguishing it from an indexer failure.
Two presets produce identical profiles for a type Collapse them rather than presenting a distinction without a difference.

Acceptance criteria

ID Requirement
D2-R1 Quality MUST be selectable in plain language without reference to custom formats or scoring.
D2-R2 Each preset MUST state its practical consequence — approximate size and transcoding implications.
D2-R3 Presets MUST map to community-maintained profiles rather than a bespoke scoring system.
D2-R4 Where the platform cannot hardware-transcode, selecting a preset requiring transcoding MUST warn before confirmation.
D2-R5 Per-media-type presets MUST be supported.
D2-R6 Changing a preset MUST state that it affects future acquisitions only.
D2-R7 Upgrading existing content MUST be a separate explicit action with its cost stated.
D2-R8 Hand-edited profiles MUST be detected and MUST NOT be overwritten without explicit consent.
D2-R9 An unreachable upstream guide source MUST leave existing profiles intact and MUST report staleness.
D2-R10 Projected storage requirement MUST be compared against available space, with a warning where implausible.
D2-R11 Media types without a resolution axis MUST present appropriate alternative options.
D2-R12 A preset yielding no matching releases MUST be reported distinctly from an indexer failure.
D2-R13 The quality envelope MUST carry the presets a choice may be made from, the formats music may take and the kinds of media a preset may be chosen for, each in the plain terms the command takes it in, so that no surface keeps its own list (D2-R1, D2-R5, N24-R1).
D2-R14 The quality envelope answering a choice MUST state, in the stack’s words, that the choice shapes future acquisitions only and changes nothing already in the library (D2-R6, N24-R4).
D2-R15 The upgrade envelope MUST state, for each kind of media, what upgrading it costs in total, worked out by the stack from what the library holds, or MUST say that the cost could not be worked out; it MUST NOT leave a surface to derive a total from a rate per hour (D2-R7, N24-R4).