Skip to main content

OPS/RED (Gazelle)

qui cross-seeds between Orpheus (OPS) and Redacted (RED) using the trackers' Gazelle JSON APIs. For the general flow, start with the cross-seed overview.

TL;DR
  • For the best OPS/RED cross-seed coverage, enable Gazelle and set both API keys.
  • If you set only one key, Gazelle matching still works, but coverage is partial:
    • OPS-sourced torrents need the RED key because qui queries the opposite site
    • RED-sourced torrents need the OPS key because qui queries the opposite site
  • Library Scan (Seeded Torrent Search) can run in Gazelle-only mode without Torznab. Use an interval of 10+ seconds.

What it does​

If you enable Gazelle matching:

  • If a torrent comes from OPS or RED, qui queries only the opposite site (RED -> OPS, OPS -> RED).
  • If a torrent comes from another source, qui checks it against the Gazelle sites you configured.
  • Torznab can run in parallel. If you configure both Gazelle keys, qui excludes OPS/RED Torznab indexers from per-torrent searches (manual, completion, library scan). If you configure only one key, qui keeps Torznab as a fallback.
  • Completion searches are the exception. If a completed torrent comes from OPS or RED, qui searches only the opposite site when you configured its key. It skips Torznab for that torrent.
  • If Torznab is unavailable, qui still returns a successful empty result for a torrent that Gazelle handled. If a local prefilter proves the target tracker content is already present, qui sends no remote Gazelle request.

Gazelle support gives qui music-specific handling for OPS/RED. The tracker-native APIs search by Gazelle release metadata and source-specific infohashes. Direct Gazelle API use lets Gazelle-only scans run without a Torznab backend. qui paces API requests and tracks key coverage separately from Torznab indexer rules.

Content gate for non-OPS/RED torrents​

Before qui spends an API call on a non-OPS/RED torrent, it reads the torrent's file extensions. If most of the torrent's bytes are not audio, e-book, or comic files, qui skips the Gazelle query for that torrent. If a torrent is already on OPS or RED, it skips this gate because the source tracker proves that the content fits.

When it applies​

qui detects OPS and RED sources by reading the announce URL:

  • RED announce host: flacsfor.me
  • OPS announce host: home.opsfet.ch

These map to the Gazelle API sites:

  • RED API host: redacted.sh
  • OPS API host: orpheus.network

Keys and coverage​

You can configure one key or both. What qui queries depends on what you seed.

  • If a torrent is sourced from OPS, qui searches for it on RED. That requires a RED key.
  • If a torrent is sourced from RED, qui searches for it on OPS. That requires an OPS key.

If you set only one key, expect this behavior:

  • Mixed OPS+RED libraries: some torrents return "no match" because qui cannot query the needed opposite site.
  • Non-OPS/RED torrents: qui queries whichever Gazelle sites you configured, one or both.

What happens if Gazelle is not configured​

If you disable Gazelle or set no API keys:

  • qui falls back to Torznab (Jackett/Prowlarr) where available
  • Gazelle-only modes (Torznab disabled) cannot run

How it matches​

In order:

  1. Infohash match with the Gazelle-style info["source"] swap logic (see nemorosa). qui tries the current source flag first (RED or OPS), then the flag the site used before its rename (PTH or APL). Uploads from before a rename still carry the old flag.
  2. Filename search plus exact total size
  3. Filename search plus filelist verification

If the target tracker is down or returns an error, qui logs a warning, does not stamp the torrent's Gazelle cooldown, and continues the run. The torrent stays eligible for the next run.

Configuration​

UI: Settings > Indexers > Gazelle (OPS/RED), below the Torznab indexers

  • Enable Gazelle matching
  • Set one or both API keys
  • qui encrypts the keys at rest and redacts them in API and UI responses

Common issues​

"torznab disabled but gazelle not configured"​

You tried to run in Gazelle-only mode with Torznab disabled, but qui has no usable Gazelle client.

Fix:

  • Enable Gazelle
  • Set at least one API key
  • If you changed sessionSecret (or QUI__SESSION_SECRET), qui cannot decrypt the stored keys, and the key fields show as empty. Put the old sessionSecret back to use the stored keys again, or enter the keys again.
  • For the best OPS/RED coverage, set both keys

"OPS rejected the API key or this IP" or "RED rejected the API key or this IP"​

The tracker refused a request. The API key is wrong, or the tracker banned the IP address of qui. The text after the colon comes from the tracker.

qui checks a new key when you save it. It sends one request to the tracker. If the tracker refuses the key, qui does not save the settings and shows this message. If the check fails for another reason, for example the tracker does not answer or is rate limiting, qui saves the key and shows a warning that it could not check the key. qui does not check a key while Gazelle matching is off.

A ban can also start after you saved the key. When the tracker refuses a request during a search, qui sends no more requests to that tracker for the rest of the search. It keeps searching the other Gazelle site and Torznab. It does not stamp the Gazelle cooldown for the torrents it could not check, so they stay eligible for the next run. The run history shows the message. If that tracker was the only source of the run, the run ends as failed.

Fix:

  • Check the API key for that tracker, and enter it again if necessary.
  • If the tracker banned your IP, contact the tracker staff. qui does not retry.

Only one key set​

This configuration works, but coverage is partial.

For example, if you set only the RED key:

  • qui can check OPS-sourced torrents against RED
  • qui cannot check RED-sourced torrents against OPS

Rate limiting​

qui rate-limits requests to OPS/RED and shares the limit across the whole qui process. Multiple qBittorrent instances do not multiply API pressure.

Gazelle and Torznab also differ in how qui applies time-based search constraints:

  • If you enable Torznab, Library Scan keeps the per-torrent interval floor of 60 seconds used for indexer searches.
  • If you disable Torznab and configure Gazelle, Library Scan can use a lower interval floor because requests go directly to the tracker APIs instead of through Torznab indexers.
  • qui stamps the Gazelle cooldown for a torrent when a Gazelle lookup completes, with or without a match. It also stamps it when Gazelle was enabled for the run but had nothing to look up for that torrent. Causes: the content gate, the local prefilter, or the target hash already present. A lookup that fails (tracker down, rate limited) does not stamp it, so the torrent stays eligible next run.
  • qui stamps Torznab cooldowns per indexer, and only for indexers that completed the search. An indexer that was rate limited or failed stays eligible on the next run.
  • After each search attempt, qui copies the representative torrent's Gazelle and per-indexer cooldown stamps to its duplicate torrents.

Library Scan without Torznab​

If you configure Gazelle, Seeded Torrent Search (Library Scan) can run with no enabled Torznab indexers.

In that mode:

  • qui still processes all source torrents
  • Matches come only from the configured Gazelle sites (RED/OPS)
  • You can lower the Library Scan interval below the Torznab floor, down to a minimum of 5 seconds. Actual request pacing still respects the shared OPS/RED API rate limits.
  • Use 10 seconds or more to reduce API pressure. The interval is per-torrent pacing, and each torrent can trigger multiple API calls.