Prowlarr-backed cross-seed searches still require duplicate indexers for filtered trackers

[tomerh2001]

Problem

When QUI uses Prowlarr-backed Torznab indexers for cross-seed searches, the selected Prowlarr indexer's own search-time filters remain fully authoritative.

In practice that means trackers configured in Prowlarr as freeleech only can still return 0 results for cross-seed searches even when valid non-freeleech cross-seed candidates exist.

What I confirmed

After tracing the current QUI and Prowlarr code paths:

1. QUI resolves the configured cross-seed Torznab indexer IDs.
2. For Prowlarr backends, QUI searches the exact selected Prowlarr indexer ID.
3. Prowlarr's current search APIs do not expose a per-search override for indexer config like freeleech only.
4. Tracker definitions often bake those settings directly into the generated request or result filtering.

So this is not really a hidden QUI option or a small QUI-only logic gap. With the current upstream contracts, QUI is inheriting Prowlarr's configured indexer behavior.

Why this matters in QUI

QUI cross-seed is a search-only/discovery flow for data I already have, so operators often expect it not to be constrained by the same search-time filters they use for normal grabbing automation.

Right now the operational workaround is still to duplicate affected Prowlarr trackers, for example:

• Tracker = freeleech-only for normal automation
• Tracker (cross-seed) = same tracker without the freeleech restriction for QUI searches

What is actually needed

The underlying behavior change appears to belong in Prowlarr, not QUI.

Useful outcomes on the QUI side would be:

1. Document clearly that Prowlarr indexer-side filters like freeleech only still apply to QUI cross-seed/searches today.
2. If Prowlarr later gains a per-search override or search mode for this, QUI could adopt it.
3. Optionally detect or warn when a selected Prowlarr indexer is likely filtered in a way that makes cross-seed searches incomplete.

Reproduction

1. In Prowlarr, configure a private tracker indexer with a search-time filter such as freeleech only enabled.
2. Import/sync that indexer into QUI.
3. Use it for cross-seed seeded/completion searches.
4. Compare results against the same tracker duplicated in Prowlarr with the filter disabled.

Related

Issue #816 is adjacent because it mentions duplicated manual/freeleech indexers in seeded-search UX, but the underlying limitation here appears to be upstream Prowlarr search/indexer behavior.

The corresponding upstream Prowlarr requests already exist:

• Toggle for Cross-Seed on torznab entries Prowlarr/Prowlarr#1987 Toggle for Cross-Seed on torznab entries (closed as not planned / won't fix)
• Ignore settings for cross-seed API calls Prowlarr/Prowlarr#2251 Ignore settings for cross-seed API calls (closed as duplicate of test(sse): warm up subscription before coalescing burst #1987)

From the maintainer comments there, the recommended workaround remains duplicated/cloned indexers without the freeleech/token settings enabled for cross-seed usage.

[tomerh2001]

Opened a new upstream Prowlarr issue that reframes this as a generic API search-mode / constraint-bypass capability, not a cross-seed-specific toggle:

• Allow API search calls to ignore saved indexer search filters Prowlarr/Prowlarr#2621 Add a generic API search mode to bypass indexer-side search constraints

The older Prowlarr tickets (#1987 / #2251) were both framed around cross-seed-specific handling and were closed. This new issue argues for an explicit, opt-in API contract that any discovery/search-only client could use.

[tomerh2001]

Upstream Prowlarr work is now in PR Prowlarr/Prowlarr#2622
If they accept it, QUI can rely on a generic Prowlarr-side raw search mode instead of duplicated filtered indexers.