[Bug] tvsubtitles, subf2m and subsource search requests use stale URLs or methods

[Svnow132]

Summary

On v1.14.0 (and on master as of 2026-09-11), tvsubtitles and subsource send their search requests to URLs that return 404, and subf2m sends a POST that its search page answers with 405. Each of the three has returned 0 results in more than 300 searches on my install. Bazarr's implementations of the same three providers send a different request at exactly the step that fails.

What actually happened?

Provider stats from GET /api/v1/providers:

tvsubtitles   342 searches, 0 results, 0 downloads
subf2m        332 searches, 0 results, 0 downloads
subsource     366 searches, 0 results, 0 downloads

I probed the search requests from inside the Sublarr container, so same egress and same resolver:

• tvsubtitles: providers/tvsubtitles.py:141-142 POSTs to https://www.tvsubtitles.net/search.php, which returns 404 Not Found. The site itself is up; / returns 200.
• subf2m: providers/subf2m.py:120 POSTs to https://subf2m.co/subtitles/searchbytitle, which returns 405 Method Not Allowed. A GET to the same URL with ?query=doctor+who&l= returns 200 with results.
• subsource: providers/subsource.py:27 sets _API_BASE = "https://subsource.net/api", and both the GET and the POST to {_API_BASE}/search return 404. https://api.subsource.net/ does answer, and a GET to https://api.subsource.net/api/v1/movies/search?searchType=text&q=doctor+who without a key returns 401 with an API key required error.

The bundled tvsubtitles_subliminal adapter fails on the same URL from a different angle: the last 24 hours of my log hold 98 of 403 Client Error: Forbidden for url: https://www.tvsubtitles.net/search.php.

What made this easy to miss is that all three report as no_results ("342 searches, no results, no downloads"), which reads like a provider that has nothing for my library rather than one whose search request is failing.

What should have happened?

Each provider should reach the site's current search endpoint. For reference, this is what Bazarr's subliminal_patch providers send instead. I reproduced the tvsubtitles and subf2m request shapes from inside the Sublarr container; for subsource I could only test an unkeyed request.

• tvsubtitles: POST {server_url}search1.php with form data {"qs": series}. From here that returns 200 and the tvsubtitles search page.
• subf2m: GET {_BASE_URL}/subtitles/searchbytitle?query={query}&l=. From here that returns 200 with results.
• subsource: Bazarr sets server_hostname = 'api.subsource.net', uses the base https://api.subsource.net/api/v1/, calls GET movies/search with searchType of imdb or text, and passes the key as an api_key parameter. My unkeyed request to that endpoint returned 401, and I did not test a keyed one. Bazarr wrote 18 subsource subtitles on my install in the last 10 days through this provider, so it looks like Sublarr needs the new URL plus a way to supply the API key, not just a URL change.

A smaller suggestion, in the spirit of the #201 work on naming why a provider is unhealthy: a 404 or 405 from a provider's own search endpoint could count as a failure rather than as "no results", so a search request that no longer works shows up as broken instead of as empty.

Steps to reproduce

From the Docker host, outside the container:

1. curl -s -o /dev/null -w '%{http_code}' -X POST https://www.tvsubtitles.net/search.php -d 'qs=doctor who' returns 404
2. curl -s -o /dev/null -w '%{http_code}' -X POST https://subf2m.co/subtitles/searchbytitle -d 'query=doctor who' returns 405
3. curl -s -o /dev/null -w '%{http_code}' https://subsource.net/api/search returns 404

Sublarr version

v1.14.0

Deployment

docker compose (with Postgres / Redis)

Database

SQLite (default)

Logs / Support Export

GET /api/v1/providers (excerpt):
  tvsubtitles             status_reason=no_results  342 searches, no results, no downloads
  subf2m                  status_reason=no_results  332 searches, no results, no downloads
  subsource               status_reason=no_results  366 searches, no results, no downloads
  tvsubtitles_subliminal  status_reason=no_results  381 searches, no results, no downloads

Probes from inside the container, 2026-09-11:
  POST https://www.tvsubtitles.net/search.php  q=doctor who                               404
  POST https://www.tvsubtitles.net/search1.php  qs=doctor who                             200
  POST https://subf2m.co/subtitles/searchbytitle  query=doctor who&l=                     405
  GET  https://subf2m.co/subtitles/searchbytitle?query=doctor+who&l=                      200
  GET  https://subsource.net/api/search                                                   404
  GET  https://api.subsource.net/api/v1/movies/search?searchType=text&q=doctor+who (no key)  401 API key required

Adapter log, last 24 h:
  providers.subliminal_adapter: Subliminal provider tvsubtitles_subliminal failed search: 403 Client Error: Forbidden for url: https://www.tvsubtitles.net/search.php   (98x)

Additional context

I have turned tvsubtitles, tvsubtitles_subliminal and subf2m off on my install for now, and left subsource on so I can confirm a fix against it. Happy to test a fix against a live library.

[Abrechen2]

Two of the three are fixed and released in 1.14.1, now on production. Leaving this open for subsource — details at the end.

Every probe in your report reproduced exactly, so thank you for the shape of it: the request, the status code, and what Bazarr sends instead was enough to work from directly.

The reporting fix first

You filed this as a smaller suggestion and it turned out to be the important half, so it went in first. An HTTP error from a provider's own search endpoint was recorded as no_results. That is why 342 searches read as "this library has nothing here" rather than "this provider is broken" — the distinction you drew. Both providers now raise on a non-200, so a dead endpoint surfaces as a failure.

tvsubtitles

The URL was the first of four stale steps. Fixing only the one you found would have produced a provider that searched successfully and still returned nothing:

1. search.php → search1.php, and the field is qs, not q — as you reported
2. results left their <ul id="r"> wrapper, so the selector matched nothing on the new page
3. episodes are no longer addressable as episode-{show}-{s}x{e}.html (404). They carry an opaque internal id now, and the season page is the only thing that maps 1x01 onto it
4. download-{id}.html is not the archive. It is a wait page that assembles the real path from JS fragments and navigates there — following it literally yields 859 bytes of HTML

End to end it now returns results and downloads valid SRT.

subf2m

GET instead of POST, as you reported. Two more behind it: the result container changed from ul.title to div.title, and the download 302s to a signed CDN on isubcdn.com, which our download guard was correctly refusing. The CDN is allowlisted for subf2m alone.

tvsubtitles_subliminal

Retired. The bundled adapter queried the same dead search.php, and it had never returned a result. The native provider now covers the site end to end, so keeping both meant one working provider and one that could only fail.

subsource — still open, and this issue stays open for it

Not fixed. I reproduced the 401 from api.subsource.net/api/v1/movies/search and that is as far as I could get: without a key I cannot see the response shape or the download flow, and guessing at a JSON schema I have never observed would produce something that looks like a fix and is not. It also needs a new configuration field for the key, which is more than a URL change.

You mentioned you left subsource enabled to test a fix against. If you are willing, the useful thing would be the shape of a keyed movies/search response — or say so and I will obtain a key here instead.

[Abrechen2]

Status for 1.14.2

TVSubtitles and Subf2m were fixed in 1.14.1 (e043842a) and are live. This issue now tracks SubSource only.

SubSource moved to the documented authenticated API v1 in 1.14.2. Verified against the live service from inside the shipped image, without a key: requests reach api.subsource.net/api/v1/movies/search and return HTTP 401 rather than 404, the X-API-Key header is accepted as the auth mechanism, and a rejected key raises an auth error that reaches provider health tracking instead of being recorded as an empty search — which was the core of this report.

What is still unverified: parsing a successful response — subtitle listing, ZIP download, and episode selection inside a season pack. We do not currently have a SubSource API key.

If you have a key: enable SubSource in Settings > Providers (note SubScene is a different provider), save the key, and report whether a search and download work. That would close this issue.

[Svnow132]

Testing against 1.14.2 with a live SubSource key.

Symptom: the connectivity Test button passes and provider init succeeds, but real searches never reach SubSource. Logs show:

subsource: no usable key in pool (all exhausted, 429-cooling, or pool row deleted). Add a pool row via Settings -> Providers, or turn off Settings -> Automation -> Provider budget to bypass the gate for this provider.

Root cause: the documented path (Settings → Providers → SubSource → "API Key" field) writes subsource_api_key to config_entries. That's what Test reads, and it's all it does. The real gate, providers.search_coordinator, only checks provider_account_pools, and nothing in the documented flow ever puts a row there. So a correctly entered key passes the connectivity test and then silently never gets used for a real search, surfacing to the user as an ordinary empty result rather than a broken provider.

The fix does exist, it's just not discoverable. POST /api/v1/providers/<name>/keys (routes/providers_keys.py) creates a properly encrypted pool row through the repository:

POST /api/v1/providers/subsource/keys {"label":"primary","api_key":"..."} -> 201
GET /api/v1/providers/subsource/keys -> {"keys":[{"id":6,"label":"primary","tier":"free","enabled":true,...}]}

It also invalidates the key-selector cache on write (_invalidate_cache -> KeySelector.invalidate()), so no restart is needed — I ran a search immediately after the POST and it reached SubSource cleanly. But this endpoint isn't referenced anywhere in Settings, isn't mentioned in the 1.14.2 release notes, and doesn't appear in the app's own served /api/v1/openapi.json despite being live. There's no way to find it short of reading the source.

Full confirmation, search and download both work: with a key added through /keys, I ran a real interactive search + download against a library item (The Substance, 2024):

providers.search_coordinator.retry: Provider subsource returned 4 results in 392ms
providers.download_manager: Saved subtitle: .../The Substance (2024).../....en.srt (subsource, en, score=70)

Real subtitle landed on disk. The provider works end to end once a key is actually in the pool.

Suggested fix: either wire the Settings UI's API Key field to call POST /api/v1/providers/<name>/keys instead of (or in addition to) config_entries, or have search_coordinator fall back to the plain config value when no pool row exists for a provider. Either would make the documented instructions in the 1.14.2 notes actually work.

One coverage note, not a bug: I also tested against a classic Doctor Who (1963) episode and got 0 results. Checked whether that was a title-mismatch (there's also a 2005 revival with the same plain title) — it isn't. Sonarr's series record carries imdbId: tt0056751 (the classic series), that gets threaded through to the query, and your provider's searchType=imdb path matches on it exactly, so it can't cross-resolve to the revival. SubSource genuinely just has almost no English subs for that season. Not something to fix.