Issues & AI remediation

• Unaired episode cleanup: blocklist-only approval cards say that the release will be removed without a replacement search, without assuming a library copy exists. Sonarr replacement searches are suppressed for unaired episodes, including older pending blocklist-and-search proposals; episode monitoring stays unchanged. Verified automatic cleanup displays Bad download removed; episode has not aired yet, while user-reported content problems keep their existing review flow.
• Report a problem: on any available title (admin-toggleable), bound to the exact active/detail Radarr, Sonarr, Chaptarr, or Lidarr instance and scoped to a movie, series, season, exact episode (including S00 specials: the requester picker narrows season -> episode when the season’s episode count is known), book (with a format picker when a title exists as both ebook and audiobook), or album (no format axis, so no picker); category chips plus free text. A title the caller already has an open report for shows View your report instead of a duplicate report entry.
• My reports: for non-admins the Issues route (also reachable from Settings) lists their own reports in requester words; the server rewrites admin diagnostics at the read boundary. Each report opens its thread. Admins review applied repairs, while reporters receive Ready to try again only after their own report closes successfully. The Problem resolved push choice preserves existing opt-outs. A reporter who has already checked a repair can still confirm it voluntarily in the thread, without receiving a redundant success push.
• Issue threads: a chat-style thread per issue where the reporter, admins, and the AI agent converse; agent questions flip the issue to “Needs your reply”, while inconclusive investigations surface as requester-safe Needs a closer look instead of pretending the problem was resolved. New Watching the download and Download recovery in progress states are passive: reporter-facing copy says the problem is being tracked quietly, without exposing arr/agent/admin workflow vocabulary, and the thread hides typing, replies, and completion controls until recovery is finished or truly needs attention. When a fix has actually been applied to something they reported, the reporter gets This is fixed in their own thread: the only way a subjective report closes without an admin adjudicating content they haven’t watched, and it explains that replies stop while the report is closed. Replying instead stays the obvious “no, still wrong” path. Admins can finish any actionable thread with an explicit Mark resolved or Close without fix judgment after manual verification; the completion note is always optional, and a blank one receives short attributed audit text. Reopen issue is admin-only and requires no typing: it returns the same conversation to Needs attention for manual review, preserving the prior closure and recording who reopened it. Old fixes remain historical, background recovery cannot close the reopened report, and an existing open report of the same problem is linked instead of duplicated. Older servers omit the reopen capability and show no button. Concurrent changes are reloaded instead of overwritten, and Dismiss remains separate.
• Week at a glance: the admin issue list opens with the agent scoreboard, in two clauses because there are two kinds of number. “Last 7 days” speaks outcome vocabulary: “resolved” counts every problem that ended well: which is how admins read the word: with attribution glued to the number (“41 resolved: 2 by the agent · 1 by your rules · 1 by you · 37 on their own”) so the total honors the week while automation claims only its own work. Closures that the closer’s own verb said were not fixes stay visible but outside “resolved”: “closed by you (no fix)” and “dismissed”. “Right now” is state, not history: what needs you and how many rules are paused: a rule paused in March is not something that happened this week. It sits here rather than on Agent fixes because a quiet week leaves that queue empty, and a scoreboard nobody opens during the quiet weeks cannot be what makes them legible; here the numbers also sit one tab away from the rows they count. Each stat is non-breaking, so a count never splits from the word it counts and a line may only wrap before a separator (the “·“s and the “–” both lead a wrapped line, never dangle).
• Attention vs tracking: the admin issue list separates Needs attention, Tracking, and Closed. Tracking rows are muted and never show an unread dot, while actionable new issues and non-admin status changes retain the read/unread affordance. The drawer issue count excludes passive arr recovery; admin-toggleable “mark resolved issues as read” keeps a cleanly resolved issue from re-flagging. Open issues always load complete, so a filter is never filtering a partial set; closed history is bounded server-side and the Closed tab states how many of the total it is showing rather than presenting a truncated list as the whole record.
• Agent fixes: proposed mutations render as safety-critical approval cards that prominently name the target service, instance name, and immutable instance ID alongside typed summaries, quoted parameters, and passive rationale; every execution requires confirmation showing that same target. When the server offers it, the confirmation also carries an “Always approve this fix for this problem” checkbox that arms a standing auto-approval rule for that exact problem-and-fix pair; rule-approved history reads “Approved automatically” with the rule’s label, and a rule that pauses itself after a failed fix raises an in-app notice deep-linking the evidence. The dedicated screen keeps separate Awaiting review and History tabs; when two or more fixes await review, an Approve all action confirms once and approves exactly the reviewed list in a single request; each fix still runs at most once, anything already recovering or changed server-side is skipped, and the outcome reports as applied / skipped / needs attention. Issue threads retain terminal actions, run summaries, closure provenance, and links to the full step ledger. Stale proposals and concurrent decisions are reconciled against the server, so the app never claims a denial when another admin’s approval won.
• One “Needs attention” row: the admin queues live behind a single drawer entry carrying their running total, and unfold in place when it is tapped; the group closes again when the drawer does, so the menu always opens showing the modules. The total is summed from exactly the entries it hides, so it can never claim a number the expanded list does not account for, and it stays absent while nothing is waiting rather than showing a zero. The queues scroll with the rest of the menu instead of sitting above it, which is what used to squeeze the libraries off a phone screen once five queues were listed.
• Live badges: Approvals / actionable Issues / Agent fixes counts in the drawer, kept current over WebSocket; quietly observed or actively retrying arr issues are tracked without adding alert pressure. A Plex invites entry appears (with count) only while someone shared a Plex email and holds no Plex share yet: the persistent surface behind the miss-able push: and lands on the Users screen, where those users carry an “Asked for Plex access” tag and the grant toggle is the one tap. A Setup checklist entry appears for admins with the count of items still to set up or skip. It disappears when every item is configured or skipped, or when the admin mutes it from the checklist. Its status loads when Discover opens and retries after sign-in or session validation, so the reminder does not require a visit to Settings or the checklist first.
• Focused attention menu: admins can independently keep Approvals, Issues, Agent fixes, and Profile approvals pinned or show each only while requests await approval, an issue needs attention or is being tracked, a fix awaits review, or an external settings change awaits a decision. These queues default to hidden while empty; saved visibility choices are preserved. The device-local switches appear on the queue screens and in Settings, so a hidden entry can always be restored; passive tracking keeps the Issues entry available without inflating its actionable badge. Hiding every entry hides the “Needs attention” row itself, since there is then nothing behind it.

View the maintained source for this page.