fix(scan): group chapter files indexed as "N of M" into one unmatched-scan item - #845
Open
m4bard wants to merge 1 commit into
Open
fix(scan): group chapter files indexed as "N of M" into one unmatched-scan item#845m4bard wants to merge 1 commit into
m4bard wants to merge 1 commit into
Conversation
ExtractTitleStem strips a leading track number and a trailing Part/CD/Disc/Chapter/pt number, but nothing recognises an "N of M" index. A book split as "Title 001 of 498.mp3" therefore produces a distinct stem per file, and BuildStemGroups returns one group per file, so Library Import asks the operator to identify the same book once per chapter. Unlike a bare "(N)", this form is not ambiguous with the series marker the existing comment describes: it carries its own total, so it names a part of a set rather than one work among several. The strip runs before the leading-track strip. A file named "001 of 498.mp3" would otherwise lose its leading "001 " first and be left as "of 498", which is both different in every file and no longer numeric, so it would never reach the folder-name fallback that exists to group exactly this case. Titles are unaffected where the pattern does not fit: "of" needs digits on both sides, so "Jack of Shadows.mp3" keeps its stem, and a trailing plain number still separates two works in one folder.
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
1 participant
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.
Summary
A chapter-per-file book numbered
Title 001 of 006, with no album tag to fall back on, comes back from Library Import as one scan item per file. This strips a trailingN of Mindex inExtractTitleStemso those files share a stem and group into one item.Full write-up, the measurements and the case I deliberately did not touch are in #844.
Changes
Fixed
ExtractTitleStemstrips a trailing[\s\-_]*\d+\s*of\s*\d+$before the existing leading-track strip.The ordering is the part worth reviewing. A file named
001 of 498, with no title in it at all, loses its leading001first if these run the other way round. That leavesof 498, which is a different stem in every file and is no longer numeric, so the folder-name fallback at the end never gets the chance to gather them. The comment says so at the call site.(N)is deliberately untouched. The existing comment explains that plain numeric parens are kept because they distinguish separate books in a series, which is a real tradeoff rather than an oversight, so changing it is a product decision rather than a bug fix. The issue lays out the case for revisiting it, including that the frontend already disagrees with the backend about what(N)means.Testing
Three tests in
UnmatchedScanBackgroundServiceTests:Jack of Shadows 001 of 004.mp3and siblings, grouping into one001 of 003.mp3with no title in the filename, which is the one that fails if the two strips run in the wrong orderJack of Shadows.mp3andNine Princes in Amber 2.mp3apart in one author folder, since "of" between two words is not an index and a trailing number is not a totalFull suite on this branch: 3,032 passed, 0 failed, 125 skipped, against a 3,029 baseline on
03958c15.Reproduced end to end before and after against
ghcr.io/listenarrs/listenarr:canary, using a generated library of nine folders that vary only in filename convention and title tags. On canary two of the nine explode; on a build of this branchnotags-n-of-mgroups into one item,notags-paren-indexis unchanged and still explodes by design, and the other seven stay grouped. So it moves exactly the case it targets and nothing else. The check is public, in the test-data repo linked from the issue.Notes
The album-tag detail is worth knowing when judging the blast radius. Filenames are grouped first and embedded tags are only consulted when that produced more than one group, and the value compared is
albumrather thantitle. Any folder whose files share an album tag was already being rescued by the metadata pass, so this only changes what happens to files carrying no album tag at all.