Keep remote watchlists working when Plex refuses the RSS feed URL

[Brandon-Haney]

What's happening

Plex serves watchlist RSS from rss.plex.tv/<uuid>. On 28 Jul 2026 that host started rejecting requests. My own instance went from clean fetches to failures inside a four hour window:

Run	Result
Jul 25 00:30 → Jul 28 08:30	RSS feed contains 50 items, no errors
Jul 28 12:30 onward	3× 401, then cached data

What it returns now:

no token     -> 401  <Error error="Unauthorized" message="You must provide a token!" .../>
with token   -> 404  <Error error="Not Found" .../>

The 404 applies to every feed id, including invented ones, so it isn't specific to one account's feed. Everything else on the same token keeps working in the same run: user tokens load, OnDeck runs, and API based watchlists fetch normally.

The same feed is still reachable at discover.provider.plex.tv/rss/<uuid>, which redirects to a presigned copy of the identical document. I confirmed it is the same feed rather than a coincidence:

• changing one character of the feed id returns 404, as does an invented id, so it is a keyed lookup and not a generic route
• the redirect target is plex-rss-feeds.s3.../e/<feed-id>.xml
• the response diffed against a locally cached copy taken from rss.plex.tv earlier the same morning: 50 items, 50 identical titles, no differences

What this PR does

Plex's settings page still generates rss.plex.tv URLs, so the configured URL stays primary and the other endpoint is only tried when Plex refuses it. If the primary host starts working again, runs go back to it with no config change and nothing to undo. The cache entry is keyed to the configured URL for the same reason.

Also in _fetch_rss_titles:

• Sends X-Plex-Token, scoped to Plex hosts. remote_watchlist_rss_url is user supplied, so this keeps the token from being attached to an arbitrary domain. The redirect to storage is followed as a separate request without it, since the presigned URL carries its own credentials.
• Stops retrying 401/403/404. Those answers are deterministic, so three attempts with backoff only delayed the fallback. Transient network errors still retry as before.
• Logs the fallback at INFO and per attempt detail at DEBUG, so a fetch that recovers no longer reports as an error.

_load_rss_cache() returned cached items at any age. It still returns them, since losing every remote watchlist item would be worse, but past RSS_CACHE_STALE_HOURS (24h) it now warns that the feed has been unreachable and remote changes are not being picked up. This is what makes a prolonged outage visible rather than quietly serving old data.

At normal verbosity the whole thing is one line:

INFO - RSS: primary feed URL unavailable, served from Plex's discover endpoint instead

Scope

Affects any install with remote_watchlist_rss_url set. Installs that don't use remote watchlists are unaffected. No settings changes are required and no template or UI changes are included, since the URL Plex hands out is still the one to paste in.

Testing

28 new tests in tests/test_plex_rss_fallback.py covering URL derivation, token scoping, primary first ordering, no retry on auth failures, retained retries for transient errors, redirect handling, and the cache paths. Full suite passes.

To verify manually:

1. With a remote watchlist RSS URL configured, run a cache operation and check the log. Remote watchlist items should be found, with the single INFO line above and no ERROR lines.
2. Run with --verbose to see the ordering: primary attempted first, one 404, no retry, then the fallback.
3. Point remote_watchlist_rss_url at a non Plex URL that 404s and confirm no fallback is attempted and no token is sent.
4. Set the feed URL to something unreachable and confirm cached data is still used, with the staleness warning once the cache is over 24h old.