The safest reported workaround is to install the catalog through a replacement addon with a genuinely different top-level manifest id. Changing only the catalog ID, catalog contents, or manifest URL may not help if Stremio continues associating the catalog with the original addon identity.
This is a newly reported issue, not a confirmed universal Stremio bug. The evidence suggests persistent account-side or identity-based caching, but the exact caching layer has not been officially established.
Symptoms of this stale catalog problem
This issue is more specific than an addon being temporarily unavailable. It may apply when all of the following are true:
- A catalog on Home or Discover shows an old list or old ordering.
- The addon previously served that data but has since been updated or replaced.
- Fetching the exact catalog endpoint independently returns the current data.
- Uninstalling and reinstalling the addon does not update the catalog.
- The same stale results appear in Stremio Web and Stremio Desktop while using the same account.
- Clearing browser storage, service workers, and local caches has no effect.
If the endpoint itself returns stale data, this is instead an addon or upstream data problem. Community addons are independently operated, so Stremio cannot directly correct data that an addon server is still returning.
Why changing the catalog ID may not fix it
A Stremio catalog addon can have several identifiers that are easy to confuse:
| Component | What it identifies | Why it matters |
|---|---|---|
Top-level manifest id |
The addon itself | This appears to be the important identity in the reported workaround |
Catalog id |
One catalog exposed by the addon | Changing it alone did not resolve the reported case |
| Manifest or install URL | Where Stremio obtains the manifest | A new URL can still describe what Stremio considers the same addon |
| Catalog endpoint | The request returning catalog items | It can return fresh JSON while the interface still displays old items |
The cross-device behavior is an important diagnostic clue. Because the same account displayed identical stale data in the web and macOS clients, browser-only storage was unlikely to be the sole cause. That does not prove the data was cached on Stremio's servers; an identity collision, synchronized account state, or another shared layer could produce similar symptoms.
Troubleshooting steps
Work through these checks in order. Avoid repeatedly deleting local data once the problem is confirmed across independent clients.
1. Confirm that the addon endpoint is current
Open the affected catalog in Discover and identify the exact request represented by that catalog, including its content type, catalog ID, and any extra parameters. Fetch that endpoint separately with a browser or HTTP client.
Check that the response contains:
- The expected titles and metadata IDs
- The new ordering
- The correct number of items
- No unexpected pagination or
skipvalue - No redirect to an older deployment
Do not publish configured addon addresses containing private tokens or personal settings.
If the endpoint returns old data, fix the addon, its database, CDN, reverse proxy, or upstream source first. The steps below only apply when the endpoint is demonstrably current while Stremio remains stale.
2. Check for duplicate addon installations
Review the installed addons and remove obsolete copies of the same custom addon. Similar addon names can conceal separate manifests, especially after rebuilding or moving a self-hosted service.
After removing duplicates:
- Close the affected catalog view.
- Restart Stremio or reload Stremio Web.
- Open Discover and select the intended catalog again.
- Verify that its displayed catalog and content type are the expected ones.
This is a low-risk check, but it may not help when the stale state is tied to the account or addon identity.
3. Compare web and desktop behavior
Sign in to Stremio Web and the macOS desktop app with the same account, then open the same catalog on both.
- If only one client is stale, local application or browser data remains a plausible cause.
- If both show the same old items while a direct endpoint request is current, stop focusing on browser cache alone.
You can perform one normal hard reload or application restart. Clearing the web service worker, Cache Storage, and local storage did not help the reported case and will sign you out or remove local preferences. Repeating those steps is unlikely to provide additional diagnostic value.
4. Remove and reinstall the addon once
Uninstall the affected addon, restart the client, and install its current manifest again. Then check both Home and Discover.
Treat this as a diagnostic step rather than a guaranteed fix. In the reported case, a complete uninstall and reinstall, a new manifest URL, and a changed catalog id all failed to remove the stale data.
Reinstalling the macOS application is also unlikely to change state associated with the signed-in account. It may remove local files, but it does not necessarily reset synchronized addon information.
5. Replace the top-level addon identity
If you operate the addon, create a replacement manifest with a new top-level id, not merely a new catalog ID. Install the replacement as a distinct addon and verify its catalogs before removing the old installation permanently.
Use an ID that is stable and unique to the replacement. Do not rotate IDs for routine catalog updates: this step is a workaround for an apparently stuck identity, not normal addon maintenance.
If you are only an addon user, you cannot safely rewrite someone else's manifest identity. Contact the addon operator or use another legitimate catalog addon that provides the information you need.
6. Run an optional account-isolation test
For advanced diagnosis, install the same current manifest in a separate test account, provided doing so does not expose private configuration.
- Fresh data in the test account but stale data in the original account points toward account-associated state.
- Stale data in both accounts points more strongly toward addon identity, hosting, an intermediary cache, or the response itself.
This comparison narrows the problem but does not prove where the caching occurs.
What worked for affected users
In the documented report, the successful workaround was a different catalog addon with a different top-level manifest id and a separate implementation or host. It served the same underlying current data and appeared correctly immediately.
This is evidence from one reported reproduction covering several catalog rows, not a universally verified fix. It suggests that replacing the addon's top-level identity can bypass the stuck association when changing the catalog ID and install URL cannot.
What to include in a bug report
If the issue persists, provide maintainers with a compact comparison:
- The affected top-level manifest
id - The old and new catalog IDs
- Content type and relevant request parameters
- Whether Home and Discover both show stale items
- Whether web and macOS desktop match
- A timestamped example of one stale UI item and one expected endpoint item
- Whether a separate account behaves differently
- Whether a replacement top-level addon identity works
Share sensitive manifest URLs privately and redact access tokens. Avoid sending copyrighted media links; catalog metadata and reproducible request details should be sufficient to investigate the stale-state problem.
FAQ
Is this definitely a browser cache problem?
No. Identical results in Stremio Web and the macOS desktop client on the same account argue against a browser-only cache. The precise shared layer remains unconfirmed.
Will renaming the catalog fix it?
Not necessarily. A display-name change or new catalog id did not fix the reported case. The workaround used an entirely different top-level manifest id.
Should I keep reinstalling Stremio?
No. Once the issue reproduces across web and desktop and the endpoint is current, repeated reinstalls are unlikely to add useful information. Preserve the evidence and test a replacement addon identity instead.
Can Stremio fix the community addon's data?
Stremio displays data supplied by addons, while community addons are independently operated. If the endpoint is wrong, its operator must correct it. If the endpoint is right but Stremio shows old data, report the mismatch with reproducible details.
Last reviewed: September 19, 2026