1 Commits

Author SHA1 Message Date
shaunrd0 b258e7e41b Per-track monitoring for Lidarr — track-level Monitored flag + UI + stats fixes
Squashes 8 fork commits onto upstream/develop as a single diff for cleaner
cross-fork comparison. Original history preserved on pre-squash-backup tag
locally.

Motivation
──────────
Upstream Lidarr only supports per-album monitoring. This fork adds a
per-track Monitored bit, exposed via the API, so a companion tool
(musicseerr fork: shaunrd0/musicseerr) can selectively grab a single
track from an album without flipping the whole album's monitor state.

Changes
───────

• Track POCO + persistence
  src/NzbDrone.Core/Music/Model/Track.cs gains a Monitored property
  (default true — new tracks start monitored, matching the historical
  behavior where every track on a monitored album was implicitly
  in-scope). AlbumRepository / TrackRepository / TrackService updated
  to read, write, and bulk-update the field.

• UI: per-track monitor toggle on album details page
  Adds a checkbox column in the Album Details track list so users can
  flip individual tracks Monitored/Unmonitored without using the API.

• UI: Tracks column on Wanted/Missing and Wanted/CutoffUnmet
  Adds an explicit "Tracks" column to those views so the row shows
  monitored-tracks / total-tracks for each album, making partial-album
  state visible at a glance.

• Stats correctness
  TrackCount on album-level stats is now gated by Tracks.Monitored
  (an album where every track is unmonitored should not be counted as
  having wanted/missing tracks). Wanted Tracks denominator switched
  from monitored-track-count to total trackCount, matching the
  semantics of the new column.

• Build: custom Dockerfile.fork for local image
  Multi-stage build producing a hotio-compatible runtime image,
  targeting linux-musl-x64 (hotio's base is Alpine). Used by the
  lidarr-personal and lidarr-shared instances; lidarr (the public
  stock instance on gnat:8686) continues running upstream hotio.

Compatibility
─────────────
The schema migration is purely additive (one new BOOLEAN column with a
true default), so a fork → upstream rollback works without data loss —
the column simply becomes dead weight on disk.
2026-05-30 00:01:33 +00:00