feat(library): remove tracks from the library without touching the file
"Remove from library" deletes the audio_files row and records the path as excluded, so the next scan does not import it again. Without the exclusion the operation undoes itself on the next scan, which is worse than not having it at all; the file on disk is never touched, which is the promise the confirmation copy will make. The soft scan compares the number of audio files on disk against the number of rows, so both walks now skip excluded paths — otherwise the two counts disagree forever and every launch queues a full scan of the whole library. A full rescan clears the exclusions, which is the only way back for a path removed by mistake until there is a UI for it.
This commit is contained in:
@@ -66,6 +66,17 @@ export const Events = {
|
||||
TrackMetadataChanged: "TrackMetadataChanged",
|
||||
BatchWriteProgress: "BatchWriteProgress",
|
||||
|
||||
// Track removal events.
|
||||
//
|
||||
// TracksRemovedFromLibrary means "these rows are gone and these paths
|
||||
// will not be imported again", and like TrackPlayCountChanged it
|
||||
// carries everything a consumer needs to patch rather than invalidate:
|
||||
// {filePaths: []string, count: int}. The library store splices those
|
||||
// paths out of its tracks array — which is the expensive collection —
|
||||
// and refetches only the album/artist/genre summaries, whose counts
|
||||
// really did change
|
||||
TracksRemovedFromLibrary: "TracksRemovedFromLibrary",
|
||||
|
||||
// Play statistics events.
|
||||
//
|
||||
// TrackPlayCountChanged carries everything needed to patch the one
|
||||
|
||||
Reference in New Issue
Block a user