bitmagnet-io / bitmagnet

A self-hosted BitTorrent indexer, DHT crawler, content classifier and torrent search engine with web UI, GraphQL API and Servarr stack integration.
https://bitmagnet.io/
MIT License
2.35k stars 92 forks source link

Allow the end user to define more than 100 results returned when hitting torznab api #306

Closed binhex closed 6 days ago

binhex commented 6 days ago

Is your feature request related to a problem? Yes

The current problem is that bitmagnet is limited to only return 100 results, this is a problem when attempting to process newly added magnets, as there could be more than 100 magnets added between queries.

An example showing the limit is to go to the following URL on a running system and note that the limit is set to 100 even though the limit is defined as 200:- http://<your ip>:3333/torznab/api?t=search&q=1080p&limit=200

Describe the solution you'd like

I would like to ideally have the ability to define the maximum number of results returned for the torznab api, this could be visible in the bitmagnet web ui.

Describe alternatives you've considered

If that cannot be done then to increase the maximum limit within bitmagnet (say to 1000) and the end user could then control the limit using downstream tooling, such as Prowlarr/Jackett.

Another alternative that would also help (although i may still hit the 100 limit) is to add in pre-processing filtering to bitmagnet, this should then at least allow me to reduce the number of magnets that I'm not interested in, a simple index title regex filter would suffice, for example for me I'm not interested in movies that contain non English audio, so I could filter to only permit index titles that only contain ascii characters.

I have tried using 'offset' which whilst this does work for bitmagnet it does not currently work for jackett or prowlarr, neither of which currently support pagination.

Additional context

I am connecting to bitmagnet via jackett, i then configure a Python script to query jackett via the api and do further processing.

So my last comment here is that the problem really is that bitmagnet is too damn good at finding magnets :-), its a victim of it's own success here, i really need a way to increase the limit to ensure I'm not missing a lot of magnets (which I currently am).

mgdigital commented 6 days ago

There needs to be some max limit - this is part of the Torznab spec and also a practical requirement to avoid queries having an unbounded result size. You can use the offset parameter to paginate through the results while keeping the limit at 100.

binhex commented 6 days ago

There needs to be some max limit - this is part of the Torznab spec and also a practical requirement to avoid queries having an unbounded result size.

Sure that's fine, I'm asking that we can define it in the Web UI, is this not possible?.

You can use the offset parameter to paginate through the results while keeping the limit at 100.

As mentioned above I'm using Jackett and/or Prowlarr, neither of which support pagination via the offset (see links to open issues), if you have another workaround then I'm all ears.

mgdigital commented 6 days ago

Any theoretical max limit you could set will not solve the problem here, as the number of new results might still be higher. You are right that Jackett etc is where this would need to be fixed. Another solution is to use the bitmagnet API directly without proxying through Jackett...

binhex commented 6 days ago

Another solution is to use the bitmagnet API directly without proxying through Jackett...

So really the only solution i have right now is to talk directly to bitmagnet torznab api and use offset correct?.

mgdigital commented 6 days ago

So really the only solution i have right now is to talk directly to bitmagnet torznab api and use offset correct?.

Yes, or the GraphQL API. It seems the Jackett proxy is not adding much here and only limiting the capabilities the Bitmagnet APIs already have...