yolo/arr
3
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Wiki Activity

Amend DESIGN.md: a size band describes one episode #179

New Issue
Closed
opened 2026-08-24 19:30:29 +01:00 by naps62-yolo · 1 comment
naps62-yolo commented 2026-08-24 19:30:29 +01:00
Owner
Copy Link
Copy Source

size_bands is documented as "per resolution: floor, target, penalty curve"
without saying per what quantity of video. For movies the question never
arose — one release is one film. For TV a release may be one episode, several,
or a whole season, and the same band is applied to all of them.

The values in the shipped TV policies answer the question implicitly: TV — main
sets a 1080p target of 2 GiB and a 2160p target of 6 GiB. Those are episode
numbers. Against a ten-episode season pack they are not.

State the rule in §5: a size band describes one episode. A release covering
more than one episode is measured by its size divided by the number of episodes
it covers, and that per-episode figure is what the floor and the target are
compared against.

Say what happens when the count is not known — a release matched before its
season's episodes have been revealed by a metadata refresh has nothing to divide
by. The rule must not silently guess: treat an unknown count as one episode, the
behaviour today, and note that this makes a pack look oversized rather than
undersized, which fails toward rejecting rather than grabbing.

Also note the consequence for §5.4's floor filter: the floor is a hard reject, so
it must be applied to the per-episode figure too. Applying a per-episode floor to
a pack's total makes every pack pass trivially, which is the current behaviour
and is wrong in the opposite direction from the target penalty.

Non-goals: this issue does not retune any band values. The numbers in the
shipped policies are a separate question and get their own issue once the
normalisation is in and real candidates can be compared.

`size_bands` is documented as "per resolution: floor, target, penalty curve" without saying per *what quantity of video*. For movies the question never arose — one release is one film. For TV a release may be one episode, several, or a whole season, and the same band is applied to all of them. The values in the shipped TV policies answer the question implicitly: `TV — main` sets a 1080p target of 2 GiB and a 2160p target of 6 GiB. Those are episode numbers. Against a ten-episode season pack they are not. State the rule in §5: **a size band describes one episode.** A release covering more than one episode is measured by its size divided by the number of episodes it covers, and that per-episode figure is what the floor and the target are compared against. Say what happens when the count is not known — a release matched before its season's episodes have been revealed by a metadata refresh has nothing to divide by. The rule must not silently guess: treat an unknown count as one episode, the behaviour today, and note that this makes a pack look oversized rather than undersized, which fails toward rejecting rather than grabbing. Also note the consequence for §5.4's floor filter: the floor is a hard reject, so it must be applied to the per-episode figure too. Applying a per-episode floor to a pack's total makes every pack pass trivially, which is the current behaviour and is wrong in the opposite direction from the target penalty. Non-goals: this issue does not retune any band values. The numbers in the shipped policies are a separate question and get their own issue once the normalisation is in and real candidates can be compared.
naps62-yolo added this to the Season packs milestone 2026-08-24 19:30:29 +01:00
naps62-yolo added the area/infratype/choredifficulty/moderate labels 2026-08-24 19:30:29 +01:00
naps62-yolo added a new dependency 2026-08-24 19:30:29 +01:00
#180 Normalise season pack size by episode count when scoring
naps62-yolo commented 2026-08-24 19:42:10 +01:00
Author
Owner
Copy Link
Copy Source

Out of scope, noted rather than changed: the issue points at "§5.4's floor filter", but §5.4 is "Quality, and why there is no upgrade loop" and says nothing about a floor. The floor is only described in §5.5, so both the per-episode rule and the floor consequence went there.

Out of scope, noted rather than changed: the issue points at "§5.4's floor filter", but §5.4 is "Quality, and why there is no upgrade loop" and says nothing about a floor. The floor is only described in §5.5, so both the per-episode rule and the floor consequence went there.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
arr-api
 area/ci
CI and test harness
 area/compat
arr-compat
 area/core
arr-core
 area/daemon
arr-daemon
 area/db
arr-db
 area/dl
arr-dl
 area/indexer
arr-indexer
 area/infra
workspace and tooling
 area/meta
arr-meta
 area/parse
arr-parse
 area/probe
arr-probe
 area/subs
arr-subs crate: providers, extraction, translation, sync
 area/web
web/
 difficulty/easy
bounded, obvious approach, few files
 difficulty/hard
subtle correctness or cross-cutting
 difficulty/moderate
multiple files, judgement, an interface to design
 difficulty/trivial
one file, mechanical, no design decisions
 phase/1-skeleton
workspace, CI, config, database, empty API and SPA
 phase/2-logic
parsing and policy engine, pure, no network
 phase/3-sourcing
TMDB and Prowlarr, read-only
 phase/4-movies
movies end to end
 phase/5-ui
search, buckets, library views, queues
 phase/6-tv
seasons, episodes, tracking, derived status
 phase/7-people
owner tags and notifications
 phase/8-compat
Jellyseerr shim
 phase/9-subtitles
build order: subtitles, DESIGN.md §15
 type/bug
type/chore
type/feature
type/test
No labels area/infra difficulty/moderate type/chore
Milestone
No items
No Milestone Season packs
Projects
Clear projects
No projects
Assignees
Clear assignees
hermes (Hermes (agent)) naps62 (Miguel Palhas) naps62-yolo (naps62-yolo (agent))
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Blocks
#180 Normalise season pack size by episode count when scoring
yolo/arr
Reference: yolo/arr#179