Fixed: Scene title replacement eating codec tokens from simpleReleaseTitle - #327
Merged
plz12345 merged 1 commit intoJul 16, 2026
Merged
Conversation
…Title The title capture is matched against simpleTitle, which has already had the quality and codec tokens deleted, but the replacement is applied to simpleReleaseTitle, which keeps them. The two strings do not address the same characters, so the replacement span overran the title and cut into the quality block, leaving exactly as many trailing characters as SimpleTitleRegex had deleted -- x265 became 265. Release Title custom formats matching on codec tokens then silently failed to score, seemingly at random. Scene regexes capture the title through to the end of the string, so the capture spans the quality block as well and bounding it by the capture alone would drop the codec entirely. Replace ReleaseTokens by value instead: it is cut from releaseTitle at the title boundary, so the quality block survives for custom formats to match against. Fixes Whisparr/Whisparr#1111
|
sampulsar
approved these changes
Jul 16, 2026
This was referenced Jul 20, 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
3 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.
Database Migration
NO
Description
Release Title custom formats matching on codec tokens (x265/HEVC, x264, ...) silently failed to score on scene releases, seemingly at random.
ParseMovieTitlematches the report regexes againstsimpleTitle, which has already had the quality and codec tokens deleted bySimpleTitleRegex. It then applies the title replacement tosimpleReleaseTitle, which keeps them. The two strings don't address the same characters, so the replacement span overran the title and cut into the quality block, leaving exactly as many trailing characters asSimpleTitleRegexhad deleted:x265ROUP1080pGROUP1080p+x265265-GROUPSo
x265became265, the codec token no longer existed in the string the custom format is evaluated against, and the CF couldn't match. Whether the codec survived was pure arithmetic coincidence — the issue's "working" example only worked because the 9 surviving characters happened to be.x265.PRT. The apostrophe correlation reported in the issue is a red herring; titles with no punctuation at all reproduce it just as reliably.This block came from Radarr, where the title capture is bounded by the year and so never crosses the stripped region. Whisparr's scene regexes capture the title through to the end of the string, so the capture spans the quality block as well — meaning simply realigning the offsets would drop the codec entirely rather than partially.
Fixed by replacing
ReleaseTokensby value instead of splicing on the stale offsets.ReleaseTokensis cut fromreleaseTitleat the title boundary, so the quality block survives for custom formats to match against:Movie parsing is unaffected — the movie branch never sets
ReleaseTokensand falls through to the existing path.Verified against the issue's repro through
/api/v3/parsewith the reporter's exact custom format regex, which now matches. Also removes the// TODO: Add tests for this!that sat above this block.Known remaining gap, pre-existing and not a regression:
SpecialEpisodeTitleRegexbounds on resolutions andWEB/HDTVbut not codec tokens, so a release carrying a codec but no resolution (Studio.26.07.09.Performer.Title.XXX.x265-GROUP) still loses it. Those releases already parse as qualityUnknown. Worth a follow-up rather than widening this change, since that regex also drives title matching.Screenshot(s) (if UI related)
N/A — not UI related.
Todos
Issues Fixed or Closed by this PR