7.6 KiB
Upgrades
Source: src/lib/server/upgrades/ (processor, cooldown, normalize, logger)
Shared: src/lib/shared/upgrades/ (filters, selectors)
The upgrade system is a scheduled job that proactively searches Arr for better releases. It fills the gap that RSS alone can't cover: new quality profiles, profile score updates, and indexer downtime all leave existing library items with suboptimal files that RSS will never revisit. Upgrades work through the library methodically, one filter at a time, searching for improvements and letting Arr's own upgrade logic decide whether to grab them.
Table of Contents
Pipeline
Each run processes a single filter from the config's filter list. The
processor normalizes Radarr/Sonarr responses into a unified UpgradeItem
so all downstream logic is app-agnostic.
flowchart TD
FETCH[Fetch library + normalize] --> PICK[Pick filter]
PICK --> EVAL[Evaluate filter rules]
EVAL --> COOL[Exclude cooldown-tagged items]
COOL --> DRY{Dry run?}
DRY -->|Yes| EXCL[Exclude previous dry-run picks]
DRY -->|No| SEL
EXCL --> SEL[Apply selector]
SEL --> SEARCH{Dry run?}
SEARCH -->|Yes| RELEASES[Fetch releases + compare scores]
SEARCH -->|No| BATCH[Batch search + apply cooldown tag]
RELEASES --> LOG[Log + notify]
BATCH --> LOG
Status
| Status | Meaning |
|---|---|
success |
Searches triggered, no errors |
partial |
Some searches succeeded, some failed |
failed |
All searches failed or a fatal error occurred |
skipped |
No items to search (filtered to zero) |
Filters
Filters use a nested group/rule structure with AND/OR logic. A config can have multiple filters; each run processes exactly one (see Scheduling).
A rule is a field + operator + value triple:
monitored is true
year gte 2020
status gte released
A group wraps rules (or nested groups) with a match mode:
all-- every child must match (AND)any-- at least one child must match (OR)
Fields are typed by category:
| Category | Operators | Examples |
|---|---|---|
| Boolean | is, is_not | monitored, cutoff_met |
| Text | contains, not_contains, starts/ends_with, eq | title, quality_profile, genres, tags |
| Number | eq, neq, gt, gte, lt, lte | year, rating, size_on_disk, popularity |
| Date | before, after, in_last, not_in_last | date_added, digital_release, first_aired |
| Ordinal | eq, neq, gte, lte, gt, lt | status, minimum_availability |
Ordinal fields have a defined progression (e.g. tba -> announced -> inCinemas -> released for Radarr) so operators like gte mean "has reached
this stage or later." Radarr and Sonarr each have app-specific fields; the
full list is in src/lib/shared/upgrades/filters.ts.
Each filter also carries a cutoff (0-100%), a percentage of the quality profile's cutoff score. Items whose current score meets or exceeds the threshold are considered "cutoff met" and can be filtered out.
Selectors
After filtering, a selector picks which items to search. Each filter specifies a selector strategy and a count (items per run).
| Selector | Strategy |
|---|---|
random |
Shuffle, take N |
oldest |
Oldest by date added |
newest |
Newest by date added |
lowest_score |
Lowest custom format score first |
most_popular |
Highest popularity first |
least_popular |
Lowest popularity first |
alphabetical_asc |
A-Z by title |
alphabetical_desc |
Z-A by title |
Selector definitions live in src/lib/shared/upgrades/selectors.ts.
Scheduling
Each Arr instance has a single upgrade config with a global cron schedule. Each run picks one filter from the enabled list:
- Round robin -- cycles through filters in order.
currentFilterIndexincrements after each non-failed run and wraps around. - Random -- shuffles the enabled filters and cycles through all of them before reshuffling.
The job system manages dispatch via nextRunAt / lastRunAt.
After each run, the handler calculates the next cron occurrence and updates
nextRunAt.
Cooldown
The cooldown system prevents the same item from being searched repeatedly across runs. It works through Arr tags:
- When items are searched in a live run, the processor tags them in Arr
with
profilarr-{filter-name}(slugified, max 50 chars). Filters can also specify a custom tag to override the auto-generated one. - On the next run,
filterByFilterTag()excludes items that already carry the filter's tag. - When every matched item has been tagged (the filter is "exhausted"),
resetFilterCooldown()removes the tag from all items and a new cycle begins.
This means the system works through the entire filtered pool before revisiting any item. Multiple filters can share a tag to enforce a shared cooldown across them.
Dry Run
Dry-run mode fetches available releases for each selected item and compares scores without triggering actual searches. This lets users preview what the system would do.
An in-memory exclusion cache (1-hour TTL, keyed by instance ID) tracks items selected in previous dry runs so the same items aren't re-picked on repeated manual runs. The cache can be cleared from the UI.
In dry-run mode, cooldown tags are not applied to items.
Logging
Every run produces an UpgradeJobLog that captures the full funnel:
- Config snapshot -- cron, filterMode, selected filter name, dryRun flag
- Library stats -- total items, fetch duration
- Filter stats -- matched count, after cooldown, dry-run excluded
- Selection stats -- method, requested count, actual count, per-item details (title, current score/formats, upgrade releases with scores)
- Results -- searches triggered, successful, failed, errors
Three logging functions in logger.ts:
logUpgradeRun(log)-- persists the full log to theupgrade_runstable and writes a summary to the logger with sourceUpgradeJob. Log level is INFO for success, WARN for partial, ERROR for failed.logUpgradeSkipped(instanceId, name, reason)-- DEBUG-level.logUpgradeError(instanceId, name, error)-- ERROR-level.
Notifications
Upgrade runs emit one of four notification types via the notification system:
| Type | Severity | When |
|---|---|---|
upgrade.success |
success | Searches completed, no errors |
upgrade.partial |
warning | Some searches, some errors |
upgrade.failed |
error | All searches failed |
upgrade.skipped |
success | Nothing to search |
Notifications are not sent for dry runs. Each notification includes the filter name, selector method, funnel breakdown (total -> filtered -> cooldown -> selected), and per-item score/format comparisons with poster images. Sonarr items are flattened by season.