Cross-Seed: exact-size fallback compares total size, so local extras (nfo/poster/screens) block it for a byte-identical video file

[illutr0n]

Description

The exact-size fallback compares the candidate's reported size with the local torrent's total size. When the local torrent carries extras (.nfo, poster, screenshots, a few MB), a candidate that is the byte-identical video file can never reach the fallback, so any label difference the fallback would normally relax becomes a hard rejection.

Example (same encode, the .mkv is byte-identical):

	Name	Size
Local torrent	Example.Film.2020.UHD.BluRay.1080p.DD+Atmos.5.1.DoVi.HDR.x265-Kyo	total 5,402,515,934 = .mkv 5,400,000,000 + .nfo + poster.jpg + screens.png
Tracker A	Example.Film.2020.UHD.BluRay.1080p.DD+Atmos.5.1.DoVi.HDR.x265-Kyo.mkv	5,400,000,000 → strict match
Tracker B	Example Film (2020) 1080p UHD BluRay x265 DV HDR10+ DDP Atmos 5.1 English-Kyo	5,400,000,000 → hdr mismatch

Tracker B labels the HDR more precisely than the group's own name (HDR10+ vs generic HDR). Treating generic HDR as HDR10+ in strict matching would be wrong, since several tests use DV HDR vs DV HDR10+ as a real mismatch, and some groups do release both. But with byte-identical content this is exactly the kind of label difference the exact-size fallback exists for. It never runs because 5,400,000,000 ≠ 5,402,515,934.

The same thing blocked the first example in #3244: the source had a few MB of extras, so the fallback couldn't relax HDR there either.

Suggestion: also count it as exact size evidence when the candidate's reported size equals, byte for byte, the size of the local torrent's main content: the total minus files that shouldIgnoreFile drops, or the single largest content file when the torrent holds one. That is at least as strong as total equality, because the candidate can't be the same payload plus our extras. The downstream per-file checks (hasContentFileSizeMismatch, alignFilesForCrossSeed) still run before anything is added, and the piece-boundary check still guards extras that share pieces with the content.

I haven't patched this locally. The source size feeds the search classifier, the stored search decision and the re-validation at apply (validateExactSizeFallback / searchCandidateMetadataConsistent), so it seemed like a design call rather than a one-line change.

Steps to reproduce

1. Seed a torrent whose main .mkv is accompanied by small extras (.nfo, poster.jpg, screens.png).
2. Run a manual cross-seed search where a tracker lists only the .mkv (same byte size as the local .mkv) under a name with a different label, e.g. HDR10+ instead of HDR.
3. The candidate is rejected with the strict reason (hdr mismatch); the exact-size fallback isn't attempted.

Environment

- qui: v1.32.0 (ghcr.io/autobrr/qui:latest, Docker) + backports of PRs #3248 and #3283
- qBittorrent: 5.2.4 (linuxserver/qbittorrent, Docker)
- Ubuntu 24.04 (qui host), Synology DSM 7.3 (qBittorrent host)

Checklist

• I have searched existing discussions and issues
• I have checked the documentation

[github-actions[bot]]

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Let the exact-size fallback accept a candidate whose reported size equals the local torrent's main content size, not only its total size.

Current behavior:
The search classifier takes exact size evidence only when the candidate's reported size equals searchSourceSize() of the local torrent, which is TotalSize (or Size). When the local torrent holds small extras next to the video (.nfo, poster, screenshots), a candidate that lists only the byte-identical video never gets exact size evidence. A label difference that the fallback would relax (for example generic HDR against HDR10+) then stays a hard rejection. This matches the code and the glossary: Title rescue is defined on the "reported total size". So this is a change to the matching rule, not a defect.

Desired behavior:
Exact size evidence also holds when the candidate's reported size equals, byte for byte, the local torrent's main content size: the total minus files that shouldIgnoreFile drops, or the largest content file. The same source size is used by the classifier, the stored search decision, and the re-validation at apply, so the three cannot disagree. The per-file checks (hasContentFileSizeMismatch, alignFilesForCrossSeed) and the piece-boundary check still run before injection. A candidate that matches neither the total nor the content size keeps today's verdict.

Key interfaces:

• searchSourceSize() / positiveExactSize() / classifySearchSizeEvidence(): today one source size; must accept the content-size form too.
• classifySearchCandidate(): exact-size fallback branch (searchCandidateClassExactSizeFallback).
• validateExactSizeFallback() / searchCandidateMetadataConsistent(): replay at apply must use the same size rule as the search.
• announcement_match.go also calls positiveExactSize(searchSourceSize(...)); decide whether webhook/announce matching gets the same rule.

Acceptance criteria:

• A local torrent with a video plus small ignored extras, and a candidate whose size equals the video size, reaches the exact-size fallback and is accepted when the only difference is one the fallback relaxes.
• The same pair passes re-validation at apply.
• A candidate whose size equals neither the total nor the content size is rejected as today.
• Hard identity attributes that validateExactSizeSearchIdentity enforces stay strict under the new size rule.
• Match corpus rows cover the new case; no existing row changes verdict.

Out of scope:

• Size tolerance for the fallback (Feature request: Allow tolerance-backed title rescue instead of exact reported-size only #2742).
• Changing which label differences the fallback relaxes.

Domain:

• Glossary terms: Title rescue (its definition says "reported total size" and would need an update).
• ADRs: 0008 (rules read releases and file lists only; the local file list is already an input, so this fits).
• Owner: the matcher search classifier in crossseed.

Logs:

• None

Why a human: Design: should exact size evidence widen from "total size" to "total size or main content size", and should webhook/announce matching follow? This changes the glossary meaning of Title rescue. Related: #3244, #2742.