mirror of
https://github.com/Radarr/Radarr.git
synced 2026-03-02 22:57:34 -05:00
Delay between searches for less hammering on indexer #9247
Labels
No labels
Area: API
Area: Database
Area: Db-migration
Area: Download Clients
Area: Extras
Area: Import Lists
Area: Indexer
Area: Metadata API
Area: Notifications
Area: Organizer
Area: Parser
Area: Scanning
Area: Tooling
Area: UI
Area: Unit Tests
On Hold: MetadataAPI Blocking
On Hold: MetadataAPI Blocking
Priority: High
Priority: Low
Priority: Medium
Status: Accepted
Status: Cannot Reproduce
Status: Confirmed
Status: Help Wanted
Status: In Progress
Status: Indexer - need invite
Status: Info Needed
Status: Investigating
Status: Logs Needed
Status: Maybe One Day
Status: Needs Triage
Status: On Hold
Status: Ready for Review
Status: Unlikely
Status: Waiting for OP
Status: Won't Fix
Type: Bug
Type: Documentation
Type: Duplicate
Type: Enhancement
Type: External Bug
Type: Feature Request
Type: Regression
Type: Support
Type: Support.
conflict
lidarr-pull
no-conflict
not-pulled
readarr-pull
readarr-pull
sonarr upstream
sonarr-pull
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Radarr#9247
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @blixten85 on GitHub (Aug 10, 2025).
Is there an existing issue for this?
Is your feature request related to a problem? Please describe
A default delay between searches would be very handy so the indexers doesn’t temporarily ban the ip from searches.
30 seconds as a default and the option to choose whatever we want but with a hardcoded minimum that works well with the trackers.
Describe the solution you'd like
Read above
Describe alternatives you've considered
Read above
Anything else?
Read above
@bakerboy448 commented on GitHub (Aug 10, 2025):
Given that Radarr generally doesn’t perform auto-searching, there’s no need for a feature that’s entirely user-caused and, therefore, entirely user-avoidable. You - the user are yourself or configuring a software to trigger searches. No plans for this.
Prowlarr/Jackett captures the 429 retry times from various sites and provides that information back to Radarr. Sites should respond to search request limits with appropriate 429 + retry after times.
For support and inquiries, please use our Discord channel. GitHub is designated solely for bug reports and feature requests. It seems that this issue may fall under a support request, so we kindly ask you to visit our Discord for assistance. Thank you.
@blixten85 commented on GitHub (Aug 11, 2025):
What? I’m responsible? If I search for all under missing or cutoff, it will search for all of the things in there and there is nothing I can do to affect this timespan between searches for each items in this queue.
Unless you think it’s my fault for using the ”search all” function in missing and cutoff sections when I clearly could have searched for one item at a time manually?
Your answer is very provocative and ignorant bakerboy.
@bakerboy448 commented on GitHub (Aug 11, 2025):
Correct - covered in the documentation. Use upgradinatorr or similar to sanely do sane batch searching. There is just about never any reason to do a search all - see FAQ 1
For support and inquiries, please use our Discord channel. GitHub is designated solely for bug reports and feature requests. It seems that this issue may fall under a support request, so we kindly ask you to visit our Discord for assistance. Thank you.
@blixten85 commented on GitHub (Aug 11, 2025):
So I have to use a whole other program just because you don’t want to add a 30 seconds delay between searches?
Where is the sanity in that?