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

Amend DESIGN.md: size bands scale with episode runtime #208

New Issue
Closed
opened 2026-08-24 21:43:03 +01:00 by naps62-yolo · 0 comments
naps62-yolo commented 2026-08-24 21:43:03 +01:00
Owner
Copy Link
Copy Source

§5.5 now says a size band describes one episode (#179). It does not say how long
that episode is, and the bands behave as though every episode were the same
length.

TV — main sets a 1080p floor of 1 GiB and target of 2 GiB. Those suit a
~45-minute episode. Rick and Morty runs ~22, so the same band judges it against
roughly twice the bitrate it should. Every season 9 pack on the indexers is
rejected below floor:

Release Per episode Verdict
Rick.and.Morty.S09.Complete.1080p.WEBRip.10Bit.DDP 0.32 GiB size
Rick and Morty S09 1080p AV1 10Bit DKong 0.19 GiB size

0.32 GiB for 22 minutes is about 2 Mbps — low, but a real WEBRip, not junk. The
band is not wrong about bitrate; it is wrong about duration.

No single per-episode number serves both a 22-minute comedy and a 60-minute
drama. Set it for the drama and half-hour shows lose every pack; set it for the
comedy and hour-long junk passes.

Rule the axis: a size band describes a rate, not a fixed size per episode,
and the comparison scales by the episode's runtime. State a reference runtime so
the existing numbers keep their meaning — if a band is read as "per 45 minutes",
today's values stay correct for a drama and relax correctly for Rick and Morty
without anyone retyping them.

SeriesMetadata.runtime already carries minutes per episode from TMDB, so the
fact is available. Say what happens when it is missing or zero: fall back to the
reference runtime, which reproduces today's behaviour rather than guessing.

Say whether movies are affected. A movie has a runtime too and its bands are
tuned against feature length; the safest ruling is that this scaling applies to
episodes only and movie bands keep their current meaning, but rule it explicitly
either way rather than leaving it to the implementer.

Non-goals: no new band values. If the reference runtime is chosen well, the
shipped policies should not need editing at all — and if they do, that is a
separate issue with evidence behind it.

§5.5 now says a size band describes one episode (#179). It does not say how long that episode is, and the bands behave as though every episode were the same length. `TV — main` sets a 1080p floor of 1 GiB and target of 2 GiB. Those suit a ~45-minute episode. Rick and Morty runs ~22, so the same band judges it against roughly twice the bitrate it should. Every season 9 pack on the indexers is rejected below floor: | Release | Per episode | Verdict | |---|---|---| | `Rick.and.Morty.S09.Complete.1080p.WEBRip.10Bit.DDP` | 0.32 GiB | size | | `Rick and Morty S09 1080p AV1 10Bit DKong` | 0.19 GiB | size | 0.32 GiB for 22 minutes is about 2 Mbps — low, but a real WEBRip, not junk. The band is not wrong about bitrate; it is wrong about duration. No single per-episode number serves both a 22-minute comedy and a 60-minute drama. Set it for the drama and half-hour shows lose every pack; set it for the comedy and hour-long junk passes. Rule the axis: a size band describes **a rate**, not a fixed size per episode, and the comparison scales by the episode's runtime. State a reference runtime so the existing numbers keep their meaning — if a band is read as "per 45 minutes", today's values stay correct for a drama and relax correctly for Rick and Morty without anyone retyping them. `SeriesMetadata.runtime` already carries minutes per episode from TMDB, so the fact is available. Say what happens when it is missing or zero: fall back to the reference runtime, which reproduces today's behaviour rather than guessing. Say whether movies are affected. A movie has a runtime too and its bands are tuned against feature length; the safest ruling is that this scaling applies to episodes only and movie bands keep their current meaning, but rule it explicitly either way rather than leaving it to the implementer. Non-goals: no new band values. If the reference runtime is chosen well, the shipped policies should not need editing at all — and if they do, that is a separate issue with evidence behind it.
naps62-yolo added this to the Size bands and waivers milestone 2026-08-24 21:43:03 +01:00
naps62-yolo added the area/infradifficulty/hardtype/chore labels 2026-08-24 21:43:03 +01:00
naps62-yolo added a new dependency 2026-08-24 21:43:03 +01:00
#209 Scale the size band by episode runtime
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/hard type/chore
Milestone
No items
No Milestone Size bands and waivers
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
#209 Scale the size band by episode runtime
yolo/arr
Reference: yolo/arr#208