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>
