In simple words, when you make a request in Jackett, the results are saved in memory (cache). The next request will return results form the cache improving response time and making fewer requests to the sites.
* We assume all indexers/sites are stateless, the same request return the same response. If you change the search term, categories or something in the query Jackett has to make a live request to the indexer.
* There are some situations when we don't want to use the cache:
** When we are testing the indexers => if query.IsTest results are not cached
** When the user updates the configuration of one indexer => We call CleanIndexerCache to remove cached results before testing the configuration
** When there is some error/exception in the indexer => The results are not cached so we can retry in the next request
* We want to limit the memory usage, so we try to remove elements from cache ASAP:
** Each indexer can have a maximum number of results in memory. If the limit is exceeded we remove old results
** Cached results expire after some time
* Users can configure the cache or even disable it
* Update to .NET 5
.NET 5 brings many performance (especially regex) improvements
https://devblogs.microsoft.com/dotnet/announcing-net-5-0/
Can look at bringing the packages upto date and using a single file executable in a future PR if the maintainers are interested
* Dotnet restore before building
* Restore on Windows only
* Out of ideas
* Update framework for windows specific apps
* Don't upgrade Microsoft.Extensions.Configuration
* drop mono from the dotnet linux build instructions
* Fix logic to get app runtime
* readme: add windows .net prereq link
* Update README.md
* azure-pipeline: bump minorversion to 17
Co-authored-by: garfield69 <garfieldsixtynine@gmail.com>
Co-authored-by: Diego Heras <ngosang@hotmail.es>
Co-authored-by: ilike2burnthing <59480337+ilike2burnthing@users.noreply.github.com>
Some magnets are using ; instead of & between trackers, e.g.:
...&dn=title&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce;tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce;tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce;tr=...
This results in them being added to the torrent client as a single, long, broken tracker.
"By re-assigning a downloaded quantity of 1:1"
MST ranges between 24-48hrs depending on how much you upload.
Can't find any mention of a global MR.
https://mycarpathians.net/wiki.php
0.3 is their global MR, "Scenetime is a ratio-based tracker which means you need to seed back whatever you grab from the site, either to a 1:1 ratio or 72 hours. So, this means if you grab a 1 gig file, you need to keep it seeding/running in your client until either you have seeded to someone else 1.0 gigs or for 72 hours total."
https://www.scenetime.com/forums.php?action=viewtopic&subforum=12&topicid=11043
Seeding requirements are balanced between time and ratio (e.g. <0.5=72hrs, 1.0=3hrs)
Global MR is 1.0 to not be deemed a leech
https://hqsource.org/faqpl.php
Diego Heras