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

Document the download surface in DESIGN.md #262

New Issue
Closed
opened 2026-08-26 10:59:53 +01:00 by naps62-yolo · 2 comments
naps62-yolo commented 2026-08-26 10:59:53 +01:00
Owner
Copy Link
Copy Source

§8 already rules that download progress is transient state, held in memory and
rebuilt from Transmission on startup. What it does not say is where that state
is ever seen: §9 describes search, the release deck, the library and the
attention queues, and nothing about a download in flight. The result is that a
season pack downloading and a season pack that never started look identical in
the UI.

Write the surface into the document before it is built:

  • Progress is shown inline, on the row that owns the item — a movie row,
    a season row for its pack, an episode row. There is no downloads page and no
    count in the rail; a download is an attribute of the thing being downloaded,
    not a place to visit.
  • Alongside progress the same row carries the other states a torrent can be
    in: seeding under §7.3's obligation, stalled, errored.
  • A torrent arr did not grab is never shown. §2 already says the service
    knows only what it put on disk, and Transmission's own UI lists the rest.
  • Nothing is persisted. No progress column, no new table — the snapshot comes
    from Transmission and dies with the process, exactly as §8 says.
  • At phone width only active-grab progress survives; seeding and stalled shed
    with the other chips §9.3 already sheds.

Operator decisions this records, from the planning session: inline rather than
a queue view, foreign torrents dropped, ~15s polling reusing the UI's existing
cadence rather than SSE.

Non-goals: any change to what the reconcile loop does, and any new state
machine — §7.3's two lifecycles stay as they are.

§8 already rules that download progress is transient state, held in memory and rebuilt from Transmission on startup. What it does not say is where that state is ever seen: §9 describes search, the release deck, the library and the attention queues, and nothing about a download in flight. The result is that a season pack downloading and a season pack that never started look identical in the UI. Write the surface into the document before it is built: - Progress is shown **inline, on the row that owns the item** — a movie row, a season row for its pack, an episode row. There is no downloads page and no count in the rail; a download is an attribute of the thing being downloaded, not a place to visit. - Alongside progress the same row carries the other states a torrent can be in: seeding under §7.3's obligation, stalled, errored. - **A torrent arr did not grab is never shown.** §2 already says the service knows only what it put on disk, and Transmission's own UI lists the rest. - Nothing is persisted. No progress column, no new table — the snapshot comes from Transmission and dies with the process, exactly as §8 says. - At phone width only active-grab progress survives; seeding and stalled shed with the other chips §9.3 already sheds. Operator decisions this records, from the planning session: inline rather than a queue view, foreign torrents dropped, ~15s polling reusing the UI's existing cadence rather than SSE. Non-goals: any change to what the reconcile loop does, and any new state machine — §7.3's two lifecycles stay as they are.
naps62-yolo added this to the Download visibility milestone 2026-08-26 10:59:53 +01:00
naps62-yolo added the area/infradifficulty/trivialphase/5-uitype/chore labels 2026-08-26 10:59:53 +01:00
naps62-yolo added a new dependency 2026-08-26 11:00:35 +01:00
#263 Report Transmission's live state for arr's own grabs
naps62-yolo commented 2026-08-26 12:12:33 +01:00
Author
Owner
Copy Link
Copy Source

Note for the record while writing this into DESIGN.md (commit on issue/262-download-surface): the issue says seeding/stalled shed at phone width "with the other chips §9.3 already sheds", but §9.3 nowhere mentions phone-width shedding. The amendment states the rule without that cross-reference; if §9.3 is meant to shed its own chips on phones, that rule needs adding there too.

Note for the record while writing this into DESIGN.md (commit on `issue/262-download-surface`): the issue says seeding/stalled shed at phone width "with the other chips §9.3 already sheds", but §9.3 nowhere mentions phone-width shedding. The amendment states the rule without that cross-reference; if §9.3 is meant to shed its own chips on phones, that rule needs adding there too.
naps62-yolo commented 2026-08-26 12:18:06 +01:00
Author
Owner
Copy Link
Copy Source

Landed on blitz/download-visibility as 54438bb — §9.8 "Downloads on the row", plus the §8 cross-reference. Gate green on the integration branch.

Landed on `blitz/download-visibility` as 54438bb — §9.8 "Downloads on the row", plus the §8 cross-reference. Gate green on the integration branch. <!-- agent-meta: {"model":"claude-opus-5","session":"ca32abe7"} -->
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 Label area/infra difficulty/trivial phase/5-ui type/chore
Milestone
No items
No Milestone Download visibility
Projects
Clear projects
No project
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
#263 Report Transmission's live state for arr's own grabs
yolo/arr
Reference: yolo/arr#262
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?