Report Transmission's live state for arr's own grabs #263
Notifications
Due Date
No due date set.
Blocks
Depends on
Reference: yolo/arr#263
Reference in New Issue
Block a user
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?
Nothing in the HTTP API reports a download.
grabsrecordssent,downloaded,imported,failedandvanishedwith no progress column —correctly, per §8, where progress is transient state rebuilt from Transmission
— but no endpoint exposes even the existence of an in-flight grab. The UI
therefore cannot tell "this season pack is at 40%" from "nothing was ever
grabbed".
GET /api/downloads: one entry per grab whose infohash Transmission stillknows about, carrying
target_kindandtarget_id, so a caller can join it onto the row thatowns the item
infohashand the torrent's namearr_dl::Torrenttoday carriesprogress,state,is_finishedandlabels; rate, ETA and Transmission's error string are new fields on theRPC call.
AppStatehas no Transmission client —Synceris the precedentfor putting one there (
with_syncer/state.rs).A torrent arr did not grab is never reported (§2, and the design amendment
in this milestone). The join is from
grabs, not from Transmission's list.Cache the snapshot with a short TTL. Every open page polls this on the UI's
existing cadence, and one RPC round trip per poll per client is the thing to
avoid — not the RPC itself, which the reconcile loop already makes every tick.
Non-goals: persisting any of it (no migration, no progress column), and any
control action — pause, resume, remove are Transmission's own UI.
Depends on: #262