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
core: allow renaming & merging of trackers with config (part 1 #8355) (#8608)
* rename site field to id in yaml indexers
* add id field in c# indexers
* use id field instead of class name in c#
and fix any yaml indexers that fail the syntax checking.
the option to ignoreUnmatchedProperties was enabled for #1549 and should have been turned off again once that task was completed.
leaving it enabled caused several unexplained behaviours in indexers where some statements were ignore by cardigann despite the intentions of the writer, and were not picked up during testing.
4 packages updated -> Jackett is now using the latest version of all packages except for AutoMapper -> Will have a go at that another day -> There is a few changes needed
-Minor code changes made to support newer version of YamlDotNet and BencodeNET
-Logic update for AssemblyName as I've been experiencing restore 'weirdness' https://stackoverflow.com/questions/208084/how-to-use-a-different-assembly-name-for-different-configurations