Can't use titulky provider anymore - getting error 429

[holdenger]

Describe the bug
instantly getting 429 from titulky (titulky.com)

To Reproduce
Steps to reproduce the behavior:

1. Configure titulky provider
2. search subtitles for the movie (manual or automatic)
3. no subtitles found
4. immediately provider in status HTTPError
5. see error in the log: "Throttling titulky for 10 minutes, until 26/01/30 13:51, because of: HTTPError. Exception info: "'Fetch failed with status code 429' ~ titulky.py@275""
   Expected behavior
   sucesfully downloaded subtitle(s)

Screenshots

Software (please complete the following information):

• Bazarr: 1.5.4
• Radarr version [e.g. v 0.2.0.0001]
• Sonarr version [e.g. v 2.0.0.0001]
• OS: Docker image linuxserver/bazarr:latest on Synology 920+

Additional context
My titulky account is VIP and i can browse the website titulky.com and download subtitles just fine without any problem. It was working correctly for the last three years, this problem started like two weeks ago. i tried to route my docker instance to titulky.com using various VPNs like NordVPN (in case of blacklisting my IP on the titulky.com side) but that doesn't changed anything. Also i tried to disable this provider for few days.

[diareuse]

Same issue here. Workaround to temporarily pivot to extract embedded / download EN, then manually translate to CS via Gemini. (The subtitles are often same or better quality than human translated, but at the cost of manual interaction with Bazarr)

[morpheus65535]

@sambartik still using this provider? Did you get the same result?

[sambartik]

I'm not a Bazarr user. Though I have spun up a dev version with mock data to test it out.

I left it on for a couple of hours and I can confirm that those errors pop up but it's not permanently broken. I could manual search and see a result from this provider in the UI.

The provider returns 429 Too Many Requests and the throttling action logged is the correct (and only?) response to that.

Does Bazarr handle raised TooManyRequests exception differently and would adding it (instead of the generic HTTPError) fix the issue perhaps?

[morpheus65535]

@sambartik how sorry I was under the impression you were still using Bazarr since you're one of the contributor to this provider.

Of course we can raise a different exception when a 429 is returned but it would still mean that the provider would be throttled for some time.

Having a retry routine implemented would be another option but it feels like we would be hammering the provider for nothing.

@holdenger would throttling the provider for a minute would be fine?

[morpheus65535]

This fix will be part of upcoming beta. Let me know if it helps!

[diareuse]

If I may chime in, there's no docs I can find on how often the server briefly bans you with 429, I think the 1 minute rule is good as any to try 🙂 Thanks for getting this sorted so quickly

[sambartik]

@sambartik how sorry I was under the impression you were still using Bazarr since you're one of the contributor to this provider.

Of course we can raise a different exception when a 429 is returned but it would still mean that the provider would be throttled for some time.

Having a retry routine implemented would be another option but it feels like we would be hammering the provider for nothing.

@holdenger would throttling the provider for a minute would be fine?

Great, at least the error is more descriptive to the users. But I think this change makes it 10 times worse, if anything. Previously the provider got throttled for 10 mins on HTTPError. With this change it will throttle for only 1 minute.

I guess the only solution here would be the combination of proactively preventing getting rate limited in the first place and reacting to the HTTP 429 error if that happens just by retrying with an exponential backoff.

[morpheus65535]

@sambartik 60 seconds is normally enough for a retry. I didn't want to go the exponential backoff retry to prevent blocking the search for all providers during this time. AFAIK, they do not send a Retry-After header either so it's hard to do a real good job here. I'll monitor this provider and bring it back to 10 minutes throttling is I saw and increase in number of exceptions.