mirror
/
Jackett
mirror of https://github.com/Jackett/Jackett
1
0
Fork 0
Code Issues Releases Wiki Activity
Page: General guidelines for what an Indexer should aim to provide
Pages
Definition format Finding cookies General guidelines for what an Indexer should aim to provide Home How to remove Indexers from jackett How to request a new tracker Installation on Alpine Linux Installation on FreeBSD Installation on OpenWrt Jackett Categories Libcurl on Synology Linux upstart script Remote access via proxy Renaming Indexers Reverse Proxy Sites that may update cats after a new year Synology installation Systemd service Troubleshooting Yearly updates for test code
5 General guidelines for what an Indexer should aim to provide
ilike2burnthing edited this page 2022-05-18 04:07:06 +01:00

Whether you are coding an Indexer in yaml or in C#, these are some general guidelines that may help you to provide the expected torznab results.

  • The indexer should be able to return results for torznab apps that will make queries by movie titles or TV episodes, etc. If the site cannot deliver search results from across their whole database, then there is little point proceeding.
  • The secondary function of an indexer is to respond to a keywordless query, by providing the most recent torrents added to the site (up to the first 100).
  • Only direct .torrent download links or magnet URI should be provided. Sites that use 3rd party filesharing services, or direct play links, or anything that provides intermediate pages (with timers or click me to proceed, or other manual interventions) before returning the download link should not be supported. This excludes requests for thank you before downloads, which are catered for by the standard indexer support modules.
  • Generally, we aim to provide a max of 100 torrents per query as most torznab apps ignore additional torrents above this max anyway.
  • If possible, the query to the web site should include a sort request, the default being sorted by the added date, with optional sorting available for title/name, seeders, and size. But it's not a problem if there is no sorting available.
  • Poster links are a great addition to the response, and if no poster is available a null value is usual.
  • The description field is usually only needed to display extra data that is not already available on the displayed torrent row, typically things like the language and subs or sub-categories, or basically anything that is not already in the title or one of the standard fields. Don't bother showing the torrent id or other such internal data.
  • If possible, an option to query for freeleech, or failing that, an option to filter for freeleech after the results are fetched from the web site is ideal, but if not available then so be it.
  • You don't need to provide the comments, no one pays attention to those numbers anyway.
  • If this is a private site you should check if there are seeding ratios that are needed to be met to avoid hit & run penalties. These usually include a minimumratio such as 1.0 indicating a share of 1:1, and/or a minimumseedtime in seconds which would release the MR
  • Finally, the download and upload volume factors are useful if available. Provide default values if none are returned by the API.

If you have any questions about the content of this page, or anything related to this topic not covered here, feel free to raise a question ticket or a comment on the PR you are building. ;-)