fix(import): treat equal-quality automatic imports as duplicates instead of replacing files - #215
Open
jordanfelle wants to merge 4 commits into
Open
jordanfelle wants to merge 4 commits into
jordanfelle wants to merge 4 commits into
Conversation
A book group's files are imported one at a time, but the "which existing files does this replace" query is re-run from the database for every file in the group, and the old rows are not removed until the whole group is committed. When the new release writes its parts to the same destination paths as the old release (the normal case for a multi-part audiobook), the second file of the group saw the first file's freshly written destination as an old file to displace, renamed it to a .chaptarr-upgrade~ backup, and FinalizePendingFileCommits then recycled it. For a 173-part set only the last part survived. Track the destination paths written and the rows displaced by the batch in progress, exclude those from replacement selection, and never stage a path the same batch already imported into.
A file whose destination path was already tracked took one of two paths in ResolveBookFilePathConflict: queue that row for the group's atomic swap, or adopt it in place. Both lost the row when another file of the same batch had already queued it for replacement, because the group-level ReplaceMany then deleted the very row the adoption had just repointed at the new file. The file stayed on disk with no BookFiles row, and history recorded an 'Upgrade' deletion for a path the batch had just imported. Always reuse the row found at the destination, keep the batch's adopted row ids out of GetDatabaseRowsToReplace, and keep the pending commit registered so its staged backups are still recycled and are never rolled back once the row is persisted.
…ing files ImportApprovedBooks.ImportFile built filesToReplace from every existing file of the matched edition and, for an automatic import (replaceExisting: true from DownloadedBooksImportService), staged, replaced and recycled them whenever the new copy was not a strictly lower *revision* (ImportApprovedBooks.cs:1104-1109). A second copy of an already-imported release therefore churned the library: on the live host 2,525 editions were re-imported in the same format as "Upgrade". An automatic import (not IsManualImport, not DownloadForced) now only displaces existing files when the shared upgrade rule says the release is a real upgrade for the edition's quality profile: IUpgradableSpecification.IsUpgradable plus IsUpgradeAllowed, which is the same profile-preference comparison (quality rank, revision, custom-format score, UpgradeAllowed) that search, queue and history use. Equal or worse against any file it would replace is reported as "Already imported: this edition already has files of equal or better quality" and nothing is moved, deleted or recycled. Rows whose file is missing on disk are excluded, so stale/aborted-import rows and the converted-destination reuse path are unaffected. Manual imports and forced grabs keep their existing explicit-replace behaviour untouched. The rejection surfaces through the normal "nothing imported" path: the tracked download ends up importBlocked with that message. No queue-completion mechanism was added - marking it Imported would fabricate history rows, and there is no established "recognised duplicate, leave the queue" state in this codebase.
jordanfelle
added a commit
to jordanfelle/chaptarr
that referenced
this pull request
Sep 26, 2026
…ready-imported duplicate The equal-quality guard compared each incoming file with the edition's surviving files only. An edition that lost parts (its rows still declare PartCount N but fewer than N files remain, as after the same-path upgrade deletion) was therefore rejected as 'already has files of equal or better quality' when the complete set arrived, so the automatic import could no longer repair it. When the surviving rows declare more parts than are present, let the import proceed and replace the partial set. Also adds a regression test that a multi-file upgrade parses each stored file's custom formats once per batch.
This was referenced Sep 26, 2026
jordanfelle
added a commit
to jordanfelle/chaptarr
that referenced
this pull request
Sep 26, 2026
jordanfelle
added a commit
to jordanfelle/chaptarr
that referenced
this pull request
Sep 26, 2026
jordanfelle
added a commit
to jordanfelle/chaptarr
that referenced
this pull request
Sep 27, 2026
jordanfelle
added a commit
to jordanfelle/chaptarr
that referenced
this pull request
Sep 27, 2026
jordanfelle
added a commit
to jordanfelle/chaptarr
that referenced
this pull request
Sep 27, 2026
jordanfelle
added a commit
to jordanfelle/chaptarr
that referenced
this pull request
Sep 27, 2026
jordanfelle
added a commit
to jordanfelle/chaptarr
that referenced
this pull request
Sep 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depends on #200 (
fix-upgrade-deletes-new-files); stacked on that branch.Problem
ImportApprovedBooks.ImportFilebuiltfilesToReplacefrom every existing file of the matched edition and, for an automatic import (replaceExisting: truefromDownloadedBooksImportService), staged, replaced and recycled them whenever the new copy was not a strictly lower revision. A second copy of an already-imported release therefore churned the library: on a live instance 2,525 editions were re-imported in the same format as "Upgrade".Fix
An automatic import (not
IsManualImport, notDownloadForced) only displaces existing files when the shared upgrade rule says the release is a real upgrade for the edition's quality profile (IUpgradableSpecification.IsUpgradableplusIsUpgradeAllowed, the same comparison search, queue and history use). Equal or worse is reported as "Already imported: this edition already has files of equal or better quality" and nothing is moved, deleted or recycled. Rows whose file is missing on disk are excluded. Manual imports and forced grabs are unchanged. The rejection surfaces through the normal "nothing imported" path (importBlockedwith that message); no new queue state is invented.Verification
ImportApprovedBooksAdditionalCopyFixturecases (equal quality, worse, real upgrade, missing-on-disk row, manual/forced unchanged).Partial editions: if the surviving rows declare more parts than are present (for example an edition left with 2 of 4 parts by the same-path upgrade bug fixed in #200), the complete incoming set is accepted and replaces the partial set instead of being rejected as a duplicate; complete duplicates are still rejected.
Note: for a profile with
UpgradeAllowedfalse the existing code routes an equal-or-worse re-download to an additional copy before this guard runs, so the "Already imported" rejection applies to profiles that allow upgrades.