Usenet Cache Fails
The way that the cache works for usenet makes it rare that the cache will ever hit, leading to wasted bandwidth and slower downloads. The problem lies in hashing the link as-is with no sanitation. I’m using
https://inhies.github.io/Newznab-API/functions/#get as reference since it is pretty commonly used as the format the links will be in. Everything I’m going to say, especially suggestions, are only really valid if that format is matched. Due to the nature of usenet I’m not sure anything can be done to solve this universally, but starting with improving the most common cases would help.
A few examples that make caching difficult:
1. Query order. It is legal for those parameters to be in any order, and any changing of it will obviously affect the hash. A deterministic order could help this (ex. sort the query parameters before hashing).
2. del may or may not be present. It is probably likely to put del on a cart RSS feed, but since it is unlikely that del would be used in other cases that want to access the file the cache will be missed due to del. Stripping del before hashing would solve this.
3. apikey obviously has a value that varies. This effectively means that even if two people are using the same indexer to access the same file they’ll always cache miss. Stripping del before hashing would solve this.
Bringing my suggestion fully together would be something like “if the link matches the standard format of a Newznab t=get URL then change the hash rules to instead just hash together the host and the id.” I don’t know how popular using private usenet trackers is with TorBox, but this would dramatically increase cache hits for them. It would also make it so usenet RSS feeds and actually cache hit in the Stremio plugin.
Comments7
Wamy
Feb 13
In our latest update, we have fixed this issue, allowing cache search to accept dozens of acceptable hashes. Please read:
https://support.torbox.app/en/articles/13681109-technical-getting-hashes-for-searches
decoupled456
Feb 16
That does seem useful. The one case that I'm unclear on though Newznab URLs. Those are likely to be something like https://example.com/api?t=get&id=foo&apikey=bar. In such a case stripping all the query parameters leaves just https://example.com/api. So it would probably be useful if there was special case for newznab-style URLs that kept at least the id parameter as part of the hash key.
ian
Oct 24, 2025
100% this is the issue I’m having with TorBox Usenet cache. Need to filter out the APIkey or use the ‘id’ parameter from the URL to create the md5 hash.
decoupled456
Aug 29, 2025
At the time I originally wrote this comment there was a bug that was causing usenet links to fail to download even though files work fine. Links that I know for a fact are fully accessible and work fine.
This does raise another interesting issue though: I’d prefer to supply files than links, but I effectively can’t with the way the cache functions. Even with the problems of link-based caching (due to including apikeys and such), it is the only thing I have pre-grab that is possible to associate with the TorBox cache. I do understand why though: you wouldn’t have a way to verify that the information provided was correct if you allowed the client to supply other information used for identification (although since hashing is done via MD5 it is mostly just assumed no one will bother to create a clash intentionally, though they could with some effort). But this adds up to that if I want to identify which results from my indexer are in the cache my only option is links.
smileslover
Aug 9, 2025
make usenet cache again!
smileslover
Aug 8, 2025
I like this idea
decoupled456
Aug 8, 2025
Sadly I don’t see a way to edit my submission, so I guess I’ll comment corrections here.
The last line of 3 should be about stripping apikey. There are also various other typos, but they're more in the realm of a bit confusing to read than incorrect. Just converting https://host.com/api?t=get&id=foo&apikey=bar&del=1 to https://host.com/api?t=get&id=foo would be quite significant as a cache improvement.
It also occurs to me that the caches not really working for carts with del tends to make del work a bit better. Arguably things with del should trigger the delete regardless of cache state, but that's maybe a separate feature request.