Bazarr+

Seerr Requests v2.7

Bazarr+ v2.7 (Atlas) can ask your request manager for a title you do not own yet. The Discover page already shows any film or show, whether or not it is in your library; with Seerr connected, a title that is missing gets a request button beside it, and Bazarr+ reports what your request manager already knows about that title.

What it is

Discover searches subtitles for any title, including titles your library has never held. That leaves an obvious gap: you find the film, you want the film, and nothing on the page can do anything about it. This closes that gap for people who already run a request manager.

Bazarr+ does not become a request manager itself. It reads the state of a title from your server, offers the one action that state allows, and hands the request over. Everything after that, approval, quality profiles, download clients, notifications, stays exactly where it already was.

It is entirely optional. The control renders nothing at all when Seerr is not configured, and nothing at all for a title with no TMDB identity. If you do not run a request manager, Discover behaves exactly as it did before.

Which servers it talks to

Three servers in one family, all speaking the same request API:

  • Overseerr, the original, for Plex libraries.
  • Jellyseerr, the fork that adds Jellyfin and Emby.
  • Seerr, the current continuation of that line.

They are close enough to share one integration and different enough that the differences matter. Bazarr+ works out which one it is talking to from the fields the server returns on /api/v1/settings/public, not from its version string, because development images report a commit hash where a version belongs.

The difference that has to be detected is the blocklist. Overseerr uses media status 6 for deleted; Jellyseerr and Seerr use 6 for blocklisted and 7 for deleted. Reading that wrong would make a blocklisted title look like a fresh one, offer a request, and have the server refuse it. Bazarr+ re-checks the server's capabilities every few minutes, so turning a 4K lane on in Seerr, or changing its application URL, shows up here on its own.

Connecting it

In Bazarr+, go to Settings > Connections and open the Seerr tab.

  1. Turn Enabled on. The connection fields stay hidden until you do.
  2. Seerr URL: how Bazarr+ reaches the server, for example http://seerr:5055. If both run in the same Docker network, use the container name rather than an IP address.
  3. API key: from your request manager, under Settings > General > API Key. It is stored encrypted at rest and never written to a log line, the same treatment the Sonarr, Radarr and Jellyfin keys beside it get.
  4. Verify SSL certificate: only shown when your URL is https://, since there is nothing to verify over plain HTTP. Leave it on unless the server uses a self-signed certificate.
  5. Browser URL: optional, and only used for the "Open in Seerr" link. Leave it empty to use the application URL the server reports, falling back to the Seerr URL above. Fill it in when Bazarr+ reaches the server on an internal address your browser cannot open.
  6. Click Test. A working connection turns the button green and names the server, its version, and the user the API key acts as, for example Jellyseerr 2.7.3 as Owner.
  7. Save.
The key decides who requests. An API key acts as its owner, and Seerr auto-approves what its owner asks for. That is why the button says so before you press it. If the test reports a user who cannot request both movies and series, Bazarr+ warns you there and then, because every request would be refused.

Requesting a title from Discover

Open any title from Discover. Next to the library chip that says whether you already hold it, the page adds what your request manager knows and the action that goes with it:

  • Request in Seerr for a title the server has never seen. One click for a film.
  • Request seasons for a show where some seasons are already there.
  • Awaiting approval or Processing while a request is in flight, with a link into the server itself.
  • Declined or Failed: the state is stated and the action is offered again.
  • Ready in Seerr or Blocklisted in Seerr: a label, and no action, because there is nothing to ask for.

A 4K request is offered only where the server actually has a 4K lane configured and the acting user is allowed to use it. When both lanes are open, the request opens a small dialog so you can pick.

If the server is unreachable, the page says so with a Retry beside it rather than hiding the failure. If the server rejects the API key, you get one notice per browser session with a link into settings, instead of the same complaint on every title you open.

The season picker

A show opens a picker with nothing preselected, so an accidental confirm cannot request a whole series. Seasons are sorted into three groups:

  • Already in Seerr: seasons the server holds or has already been asked for. These are plain text, not greyed-out checkboxes, so the reason is readable with a keyboard or a screen reader instead of being implied by a disabled control.
  • In your Bazarr+ library: seasons you already have a copy of. Selectable, because there are good reasons to want them again, but grouped apart so you see what you are doing.
  • Available to request: everything else.

The button counts what you picked, so it reads Request 3 seasons rather than a bare Confirm. Where the server forbids partial series requests, or does not report seasons for the 4K lane, or the season list is simply unavailable, the picker collapses to a single Request all seasons action and says which of those it is.

Specials. Season 0 appears only when the server has special episodes enabled. With that off, a show whose only listed season is 0 has nothing to request, and the picker says so rather than offering a request the server would answer with a no-op.

What the states mean

Four words carry most of the meaning on this page, and two of them are easy to misread.

  • Available: the server has the title and it is ready to watch. For a show, a season is available only at that exact state; a season that is pending, approved or partially available is still in flight, not ready.
  • Requested: someone has already asked for it and the request is open, whether it is waiting for approval, approved and downloading, or failed and retryable. Bazarr+ reads the newest non-4K request for the title, so a finished request that the server left sitting at "approved" does not hide a newer state.
  • Requestable: this is the one worth reading twice. For a show, requestable means not blocklisted, and nothing more. It does not mean any season is actually free to ask for. A completed series that the server already holds in full is still requestable in that narrow sense, because TMDB can list a season the server has never heard of. Bazarr+ therefore works the seasons out separately and hides the button when the grouping comes back with nothing selectable, so you are never sent into a dialog whose confirm is already disabled. For a film the word behaves the way you would expect: requestable means the server does not know it yet, or knows it as deleted, and no request is open.
  • Blocklisted: someone has deliberately excluded the title on the server. It is reported as a label and no action is offered, because the server would refuse anyway. Note that this state only exists on Jellyseerr and Seerr; Overseerr has no blocklist, which is exactly why the flavour has to be detected first.

What it never does

The boundary is deliberate and worth stating plainly.

  • It never approves anything. Bazarr+ creates a request and stops. Approval, and the policy around it, stay in your request manager. If the API key belongs to the owner, the server auto-approves on its own side, which is the server's behaviour and not Bazarr+ acting on your behalf.
  • It never declines, deletes or blocklists. There is no path from here to removing a request or a title.
  • It never touches quality profiles, root folders or download clients. Those are the server's, and the request carries none of them.
  • It never requests on its own. Nothing here is scheduled or automatic. Every request is one you clicked.
  • It does not change subtitles. A request has no effect on searching, scoring or downloading subtitles. Once the title arrives in Sonarr or Radarr, Bazarr+ picks it up the way it picks up anything else.

Troubleshooting

No request control appears on a title. Three ordinary reasons: the integration is off, the title has no TMDB identity Bazarr+ can resolve, or it is a film you already own that the server has never seen. The last one is deliberate: offering to request a film sitting on your own disk is noise.

"Seerr rejected the API key." The key is wrong, or it was regenerated on the server. Copy it again from Settings > General > API Key there and press Test here. The notice appears once per browser session, so reload after fixing it.

"Seerr blocked the request. Disable CSRF protection in Seerr's network settings." The server is set to reject API calls that arrive without a browser's CSRF token, which an API key integration cannot send. Turn that option off in the server's network settings.

"Seerr refused the request: quota exceeded." The acting user has a request quota and has spent it. Raise or clear the quota for that user on the server.

"Seerr refused the request: the owner lacks permission." The user behind the API key cannot request this media type. The connection test reports this before you hit it, so run the test and read the user it names.

A show says its season details are unavailable. The season list comes from TMDB, not from the request manager. When it cannot be read, the picker offers a whole-series request instead of guessing.

"Your library check is incomplete." Discover could not read your whole library for this title, so the "In your Bazarr+ library" group is a floor rather than a complete answer. The request still works; just check the groups before confirming.

Next steps