bvandeusen
f6d1cf24f0
Nothing in Minstrel ever noticed a deleted file. The walk only visits paths that exist, so a row whose file was gone was never scanned, never errored, never counted — permanently invisible. classifyEvent ignores fsnotify removals by design, and the safety-net scan is the same walk, so it covers additions only. Rows accumulated forever. Found on the operator's library: a completed scan reported skipped=24185 errored=0 while the MBID backfill (which opens files by DB path rather than walking) logged ~40 "no such file or directory" across three reorganised albums. Those rows also kept their pre-#2499 welded genre, which is how this surfaced — the version-stamped tag re-read can only reach files the walk visits. The harm is not cosmetic. tracks is the candidate universe for recommendation.sql / discover.sql / system_mixes.sql and nothing filtered on file existence, so a mix could spend a slot on a track that cannot stream. Marks rather than deletes. A missing file is a claim about the filesystem and the filesystem lies transiently — an unmounted volume, a network blip, a container that started before its media mount attached. Every sweep in internal/gc resolves a truth INSIDE the database and is safe to run blind; this one is not, so no deletion happens here. Three guards refuse to act on ambiguous evidence: every scan root must resolve to a non-empty directory, the walk must have seen at least one file, and one reconcile may newly mark at most 25% of the library. Clearing a mark is never the dangerous direction, so it runs unconditionally — otherwise a library that tripped the cap could never recover once the mount returned. Only a full Scan reconciles. The walk's set of seen paths is the evidence, and ScanFiles has no basis for concluding anything about files it did not look at. Excludes marked tracks from all 13 track-emitting queries (radio x2, system mixes x5, discover x4, most-played x2), the 6 play-history seed picks, and the genre browse axis. Deliberately NOT filtered: the shared ListPlaylistTracks read path, because it also serves user-curated playlists where hiding a track the user added would be wrong — system playlists shed orphans on their next daily rebuild instead. History and the taste profile also keep them: those record the past, and a track you played 200 times still says something about your taste. Reconcile tallies land in scan_runs so a disappearance is visible rather than discovered when a mix comes up short.
26 lines
1.3 KiB
SQL
26 lines
1.3 KiB
SQL
-- Marks a track whose file the scanner could no longer find (#2523).
|
|
--
|
|
-- NULL means present. A timestamp means the file was absent as of that scan,
|
|
-- and is the point from which "how long has this been gone" is measured — which
|
|
-- is what a later cleanup pass needs in order to require a grace period rather
|
|
-- than deleting on a single missed stat.
|
|
--
|
|
-- Deliberately a nullable timestamp rather than a boolean: "missing" is not a
|
|
-- state we want to act on immediately, and the age is the only thing that makes
|
|
-- an automated deletion safe to reason about.
|
|
--
|
|
-- No default and no backfill. Existing rows start NULL (present) and the next
|
|
-- full scan sets the mark where it belongs — a migration cannot check the
|
|
-- filesystem, and guessing here would mark the whole library on a server whose
|
|
-- media volume happens to be detached at upgrade time.
|
|
ALTER TABLE tracks
|
|
ADD COLUMN missing_since timestamptz;
|
|
|
|
-- Partial index: the only query that filters on this column positively is the
|
|
-- admin "what's missing" list, which is a small set. Playback and browse
|
|
-- queries filter `missing_since IS NULL`, which matches nearly every row and is
|
|
-- better served by a sequential scan than an index lookup.
|
|
CREATE INDEX tracks_missing_since_idx
|
|
ON tracks (missing_since)
|
|
WHERE missing_since IS NOT NULL;
|