fix(search): read Indexer.MinimumAge and Indexer.MaximumSize, and measure age in UTC - #921
Open
m4bard wants to merge 1 commit into
Open
fix(search): read Indexer.MinimumAge and Indexer.MaximumSize, and measure age in UTC#921m4bard wants to merge 1 commit into
m4bard wants to merge 1 commit into
Conversation
…sure age in UTC Indexer.MinimumAge and Indexer.MaximumSize save and reload and were read by nothing. Both are now applied in SearchResultScorer, beside Retention, which was already read there. MaximumSize rejects a result larger than the indexer's own ceiling. It is deliberately outside the existing size block, which is skipped for Usenet and reads QualityProfile.MaximumSize. That is a different setting with the same name, which is worth saying out loud because grepping MaximumSize finds the profile one and makes the indexer field look wired. MinimumAge rejects a Usenet post that has not been up long enough. The reason is propagation rather than preference: grabbing too early produces an incomplete or failed download. It does not apply to torrents, where a fresh post is complete. Two things fell out of doing this. The indexer lookup moved above the size gate, because all three settings need it. That also fixes an ordering bug: the lookup is what corrects isNzb from the indexer's own type, and it used to run after the size gate, so a Usenet result recognised only by its indexer type was size-checked despite the exemption immediately below it. Age was measured in the wrong timezone. The published date went through a bare DateTime.TryParse, which converts a trailing Z to the host's local time and returns Kind=Local, and the result was then subtracted from DateTime.UtcNow. Every age was out by the server's UTC offset, so results looked older west of UTC and newer east of it. At day granularity that usually only matters at a boundary; at the minute granularity MinimumAge needs, it decides the answer. It is parsed to UTC explicitly now, with AssumeUniversal for indexer dates that carry no offset. There is a test for it that does not depend on where it runs. Indexer.EnableRss is the third field in the report and is untouched. It advertises RSS sync, and there is no RSS sync anywhere in the codebase to enable, so wiring it would mean building the feature and removing it would presume you do not intend to. That one is a question rather than a fix, and I would rather ask it separately. Controls: reverting the UTC parse, the size gate or the age gate each fails its own test and leaves the others green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 1, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 1, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 1, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 1, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 2, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 2, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 2, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 2, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 2, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 2, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 2, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 2, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 2, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 3, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 3, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 3, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 4, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
m4bard
added a commit
to m4bard/Listenarr
that referenced
this pull request
Sep 4, 2026
LOCAL ONLY. Not part of Listenarrs#863 or Listenarrs#921 and deliberately not offered to either. Both PRs grow SearchResultScorer.cs. Listenarrs#863 adds the batch-resolved indexer dictionary, Listenarrs#921 hoists the indexer lookup above the size gate and reads two more fields from it. Canary is 457 lines, Listenarrs#863 alone 476, Listenarrs#921 alone 498, and the two together 517. ActiveProductionSourceFiles_RemainFocused caps production files at 500, so each passes alone and only the combination fails. This moves the indexer lookup and IsNzbResult into a partial, which takes the main file to 473. It is a stack commit rather than a change to either pull request because the reason it exists is how our local stack combines them, which is not visible from either PR and not the maintainer's problem to review. Putting it in Listenarrs#921 would also mean hand-porting Listenarrs#863's resolved-indexer logic into a file Listenarrs#863 knows nothing about on every rebuild, since rerere can only replay a resolution for a conflicted hunk, not an edit to a new file. If both PRs merge upstream, canary itself crosses the cap and this becomes a real follow-up rather than a local patch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YEVQ7qDJLk5196MFeggWuA (cherry picked from commit f58964137bfb6a44650de793d541e17f87e87a7c)
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.
Fixes two of the three fields in #899, and leaves the third alone on purpose.
Indexer.MinimumAgeandIndexer.MaximumSizesave and reload and were read by nothing. Both are now applied inSearchResultScorer, besideRetention, which was already read there.MaximumSizerejects a result larger than the indexer's own ceiling. It sits outside the existing size block, which is skipped for Usenet and readsQualityProfile.MaximumSize. That is a different setting with the same name, which is worth saying out loud: grepping forMaximumSizefinds the profile one and makes the indexer field look wired.MinimumAgerejects a Usenet post that has not been up long enough. The reason is propagation rather than preference, since grabbing too early produces an incomplete or failed download. It does not apply to torrents, where a fresh post is complete.Two things fell out of doing this
The indexer lookup had to move above the size gate, because all three settings need it. That also fixes an ordering bug: the lookup is what corrects
isNzbfrom the indexer's own type, and it used to run after the size gate, so a Usenet result recognised only by its indexer type was size-checked despite the exemption immediately below it.Age was measured in the wrong timezone. The published date went through a bare
DateTime.TryParse, which converts a trailingZto the host's local time and returnsKind=Local, and the result was then subtracted fromDateTime.UtcNow. Every age was out by the server's UTC offset, so results looked older west of UTC and newer east of it. At day granularity that usually only matters at a boundary. At the minute granularityMinimumAgeneeds, it decides the answer, which is how I noticed: a post ten minutes old measured as five hours old on a UTC-5 host.It is parsed to UTC explicitly now, with
AssumeUniversalfor indexer dates that carry no offset. The test for it uses a timestamp written with a+09:00offset, so it does not depend on where it runs.EnableRss is untouched
It advertises RSS sync, and there is no RSS sync anywhere in the codebase to enable. Wiring it would mean building the feature; removing it would presume you do not intend to. That one is a question rather than a fix and I would rather ask it separately.
An expected conflict
This conflicts with my own #863 in
SearchResultScorer.cs, which changes how the indexer is obtained so a batch resolves it once. Same lines, different concerns. Whichever of the two lands first, I will rebase the other. I tried stacking this on #863 instead and it dragged five commits already in canary into the diff, so a plain note seemed better than a confusing PR.Tests
Six added, each with its opposite case so none of them can pass against an implementation that always rejects.
Reverting the UTC parse, the size gate or the age gate each fails its own test and leaves the others green.
Worked through with Claude Code at my direction. The claims above were checked by running them rather than by reading, and I reviewed this before posting.