starred/Prowlarr

Fork 0

mirror of https://github.com/Prowlarr/Prowlarr.git synced 2026-03-02 22:57:22 -05:00

[FEAT]: Add Indexer Timeout Setting #342

New issue

Open

opened 2026-02-20 09:41:42 -05:00 by deekerman · 14 comments

deekerman commented

2026-02-20 09:41:42 -05:00

Owner

Originally created by @neo-neo1 on GitHub (Nov 8, 2021).

Is there an existing issue for this?

I have searched the existing issues

Not everyone runs Prowlarr under ideal conditions and not all indexers are healthy. Running Prowlarr on low resource hardware in addition to accessing busy indexers during peak time requires the need to adjust timeout values. If coupled with a less than desirable overburdened ISP during peak time only increases the need to adjust timeout values.

Describe the solution you'd like

A field to set rssfeed and query timeout values when adding or editing indexer options.

Describe alternatives you've considered

We can't always control our environment nor do we control unhealthy indexers. NZBHydra2 has this option and it works beautifully. This is one feature I miss since switching. The only alternative is to use NZBHydra2 which I am attempting to avoid.

Anything else?

The Feature Parity with Hydra list comments Timeout No plans to make this an option Q which I strongly urge you to reconsider the importance of this. This is a requirement for many users.

AB#1883

Originally created by @neo-neo1 on GitHub (Nov 8, 2021). ### Is there an existing issue for this? - [X] I have searched the existing issues ### Is your feature request related to a problem? Please describe Not everyone runs Prowlarr under ideal conditions and not all indexers are healthy. Running Prowlarr on low resource hardware in addition to accessing busy indexers during peak time requires the need to adjust timeout values. If coupled with a less than desirable overburdened ISP during peak time only increases the need to adjust timeout values. ### Describe the solution you'd like A field to set rssfeed and query timeout values when adding or editing indexer options. ### Describe alternatives you've considered We can't always control our environment nor do we control unhealthy indexers. NZBHydra2 has this option and it works beautifully. This is one feature I miss since switching. The only alternative is to use NZBHydra2 which I am attempting to avoid. ### Anything else? The [Feature Parity with Hydra](https://github.com/Prowlarr/Prowlarr/issues/27) list comments `Timeout No plans to make this an option Q` which I strongly urge you to reconsider the importance of this. This is a requirement for many users. [AB#1883](https://dev.azure.com/Servarr/7ab38f4e-5a57-4d70-84f4-94dd9bc5d6df/_workitems/edit/1883)

deekerman added the

Type: Feature Request

Status: Needs Triage

Status: Unlikely

labels

2026-02-20 09:41:42 -05:00

deekerman commented

2026-02-20 09:41:44 -05:00

Author

Owner

@ta264 commented on GitHub (Nov 8, 2021):

I have to say that asserting that "feature I want" is "a requirement / crucial for many users" is one of my pet peeves. If any other users do need this functionality please "thumbs up" the initial post so we can gauge demand. This is the first time I've seen anyone request this so I'm guessing demand isn't that high.

FYI the default timeout is 100secs and anything that doesn't respond in that timeframe will get disabled and so not queried next time. So I'm not totally sure what being able to adjust the timeout buys you.

@ta264 commented on GitHub (Nov 8, 2021): I have to say that asserting that "feature I want" is "a requirement / crucial for many users" is one of my pet peeves. If any other users do need this functionality please "thumbs up" the initial post so we can gauge demand. This is the first time I've seen anyone request this so I'm guessing demand isn't that high. FYI the default timeout is 100secs and anything that doesn't respond in that timeframe will get disabled and so not queried next time. So I'm not totally sure what being able to adjust the timeout buys you.

deekerman commented

2026-02-20 09:41:44 -05:00

Author

Owner

@neo-neo1 commented on GitHub (Nov 8, 2021):

I have to say that asserting that "feature I want" is "a requirement / crucial for many users" is one of my pet peeves. If any other users do need this functionality please "thumbs up" the initial post so we can gauge demand. This is the first time I've seen anyone request this so I'm guessing demand isn't that high.

Sorry that it set off your pet peeve.

@neo-neo1 commented on GitHub (Nov 8, 2021): > I have to say that asserting that "feature I want" is "a requirement / crucial for many users" is one of my pet peeves. If any other users do need this functionality please "thumbs up" the initial post so we can gauge demand. This is the first time I've seen anyone request this so I'm guessing demand isn't that high. Sorry that it set off your pet peeve.

deekerman commented

2026-02-20 09:41:44 -05:00

Author

Owner

@ta264 commented on GitHub (Nov 8, 2021):

Sorry, grumpy after a bad nights sleep. Happy to leave it open for a little while to gauge demand - I could easily be judging it wrong.

@ta264 commented on GitHub (Nov 8, 2021): Sorry, grumpy after a bad nights sleep. Happy to leave it open for a little while to gauge demand - I could easily be judging it wrong.

deekerman commented

2026-02-20 09:41:44 -05:00

Author

Owner

@ta264 commented on GitHub (Nov 8, 2021):

PS elaborating on what you want to achieve by adjusting the timeout would help us decide whether or not to implement this (or an alternative solution)

@ta264 commented on GitHub (Nov 8, 2021): PS elaborating on what you want to achieve by adjusting the timeout would help us decide whether or not to implement this (or an alternative solution)

deekerman commented

2026-02-20 09:41:44 -05:00

Author

Owner

@netty0 commented on GitHub (Nov 8, 2021):

I’ve used indexers which have frequented in 120+ second response times.

Personally I see no reason why convincing is required for an intrinsic option.

Adjusting timeout is a valuable tool when troubleshooting.
You could lower timeout for when manually (interactive) searching to set a cut off.
Or even organize/group indexers per timeout values using tags/profiles or whichever.
Tunneling indexers over TOR needs a high timeout. Or some proxies. Or tunneling over a distant VPN server.
Satellite internet, cellular internet, overburdened indexers, free NZB Indexers, and older SBCs all stand to require higher timeouts.

A basic setting to have in my opinion.

@netty0 commented on GitHub (Nov 8, 2021): I’ve used indexers which have frequented in 120+ second response times. Personally I see no reason why convincing is required for an intrinsic option. - Adjusting timeout is a valuable tool when troubleshooting. - You could lower timeout for when manually (interactive) searching to set a cut off. - Or even organize/group indexers per timeout values using tags/profiles or whichever. - Tunneling indexers over TOR needs a high timeout. Or some proxies. Or tunneling over a distant VPN server. - Satellite internet, cellular internet, overburdened indexers, free NZB Indexers, and older SBCs all stand to require higher timeouts. A basic setting to have in my opinion.

deekerman commented

2026-02-20 09:41:44 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Nov 8, 2021):

Tunneling indexers over TOR needs a high timeout.

This should not be done and goes against the principals and requests of TOR.

Or some proxies.

Has not been an issue to date

Or tunneling over a distant VPN server.

has not been an issue to date

perhaps we bump the timeout from 100 to 120 and call it a day. This hasn't been an issue for thousands of users for 5+ months.

@bakerboy448 commented on GitHub (Nov 8, 2021): > Tunneling indexers over TOR needs a high timeout. This should not be done and goes against the principals and requests of TOR. > Or some proxies. Has not been an issue to date > Or tunneling over a distant VPN server. has not been an issue to date perhaps we bump the timeout from 100 to 120 and call it a day. This hasn't been an issue for thousands of users for 5+ months.

deekerman commented

2026-02-20 09:41:45 -05:00

Author

Owner

@neo-neo1 commented on GitHub (Nov 8, 2021):

Tunneling indexers over TOR needs a high timeout.

This should not be done and goes against the principals and requests of TOR.

Next you’re going to lecture us against using *arr apps for content they don't own.

Or some proxies.

Has not been an issue to date

Or tunneling over a distant VPN server.

has not been an issue to date

Have you taken a survey of all users past, present, and future?
Why not include a basic option as preventative maintenance for those that require it.

perhaps we bump the timeout from 100 to 120 and call it a day. This hasn't been an issue for thousands of users for 5+ months.

Hiding a timeout field underneath “Show Advanced” options would be preferable. I side on users choice for those who require it.

@neo-neo1 commented on GitHub (Nov 8, 2021): > > Tunneling indexers over TOR needs a high timeout. > > This should not be done and goes against the principals and requests of TOR. Next you’re going to lecture us against using *arr apps for content they don't own. > > > Or some proxies. > > Has not been an issue to date > > > Or tunneling over a distant VPN server. > > has not been an issue to date Have you taken a survey of all users past, present, and future? Why not include a basic option as preventative maintenance for those that require it. > perhaps we bump the timeout from 100 to 120 and call it a day. This hasn't been an issue for thousands of users for 5+ months. Hiding a timeout field underneath “Show Advanced” options would be preferable. I side on users choice for those who require it.

deekerman commented

2026-02-20 09:41:45 -05:00

Author

Owner

@Thundereye90 commented on GitHub (Nov 17, 2022):

is there any update on this issue?

@Thundereye90 commented on GitHub (Nov 17, 2022): is there any update on this issue?

deekerman commented

2026-02-20 09:41:45 -05:00

Author

Owner

@AnshulJ999 commented on GitHub (Aug 19, 2024):

Is there any update on this? I'm facing issues with indexers needing 60+ seconds to respond to a query which slows down the whole process, so a custom timeout would really be very valuable. Thanks.

@AnshulJ999 commented on GitHub (Aug 19, 2024): Is there any update on this? I'm facing issues with indexers needing 60+ seconds to respond to a query which slows down the whole process, so a custom timeout would really be very valuable. Thanks.

deekerman commented

2026-02-20 09:41:45 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Aug 19, 2024):

Is there any update on this? I'm facing issues with indexers needing 60+ seconds to respond to a query which slows down the whole process, so a custom timeout would really be very valuable. Thanks.

the timeout is 100s
there are ~0ish active developers and no one from the community as thought this to be needed for the last 3 years / taken it upon themselves to implement.

@bakerboy448 commented on GitHub (Aug 19, 2024): > Is there any update on this? I'm facing issues with indexers needing 60+ seconds to respond to a query which slows down the whole process, so a custom timeout would really be very valuable. Thanks. - the timeout is 100s - there are ~0ish active developers and no one from the community as thought this to be needed for the last 3 years / taken it upon themselves to implement.

deekerman commented

2026-02-20 09:41:45 -05:00

Author

Owner

@gitthangbaby commented on GitHub (Jun 8, 2025):

For me the situation is horrible as i'm doing interactive search from Prowlarr or other GUIs and it looks like this. At any time, 10 out of 100 indexers are down.

Search for something -> no results (no partial results, just nothing ❌) because some indexer was just marked failed (only one however ❌)
Repeat search (have to go to another tab because the Search button disappears, return back, type the query again, hit Search ❌) -> no results (indexer 2 is marked failed)
..
Repeat search -> no results -> indexer 10 is marked failed
Repeat search -> results appear
..
(wait 10 minutes)
Go to step 1, indexer status was reset, so need to mark the indexers as failed one by one again

It takes 17 minutes net, 20 min with typing the same query, and around 30min if not laser focused, to perform one search.

@gitthangbaby commented on GitHub (Jun 8, 2025): For me the situation is horrible as i'm doing interactive search from Prowlarr or other GUIs and it looks like this. At any time, 10 out of 100 indexers are down. 1. Search for something -> no results (no partial results, just nothing ❌) because some indexer was just marked failed (only one however ❌) 2. Repeat search (have to go to another tab because the Search button disappears, return back, type the query again, hit Search ❌) -> no results (indexer 2 is marked failed) .. 10. Repeat search -> no results -> indexer 10 is marked failed 11. Repeat search -> results appear .. (wait 10 minutes) 12. Go to step 1, indexer status was reset, so need to mark the indexers as failed one by one again It takes 17 minutes net, 20 min with typing the same query, and around 30min if not laser focused, to perform one search.

deekerman commented

2026-02-20 09:41:45 -05:00

Author

Owner

@bolach commented on GitHub (Sep 1, 2025):

This would be so usefull. Or a log with the time that each indexer took for the search.

@bolach commented on GitHub (Sep 1, 2025): This would be so usefull. Or a log with the time that each indexer took for the search.

deekerman commented

2026-02-20 09:41:45 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Sep 1, 2025):