Response status code does not indicate success: 429 (Too Many Requests) #113
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sim0n00ps/OF-DL#113
Loading…
x
Reference in New Issue
Block a user
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?
Hi, just downloaded this and get this error just after the logged in successfully:
Exception caught: Response status code does not indicate success: 429 (Too Many Requests).
StackTrace: at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at OF_DL.Helpers.APIHelper.BuildHeaderAndExecuteRequests(Dictionary
2 getParams, String endpoint, HttpClient client) at OF_DL.Helpers.APIHelper.GetAllSubscriptions(Dictionary2 getParams, String endpoint, Boolean includeRestricted, IDownloadConfig config)Exception caught: Object reference not set to an instance of an object.
StackTrace: at OF_DL.Program.DownloadAllData(APIHelper m_ApiHelper, Auth Auth, Config Config)
at OF_DL.Program.Main(String[] args)
How many accounts are you subscribed to?
Hi, I'd like to add some info to this post in hopes we can get it fixed. I get this same error, but only after I click "Download Purchased Tab".
I only have 5 active subscriptions, but I have paid content from more than 40 creators. Its definitely more than 40 because that's when the program quits and shows this error.
So it seems to start throwing 429 errors when you try to go over 40 I'm guessing. Hopefully this helps fix the issue!
EDIT: To add, I am using CDM keys that I've generated on my own. All other content I scrape, downloads and plays perfectly fine.
Can someone experiencing this attachment a verbose log so we can see what's going on?
I've got you. My honest guess is that its making too many requests in a short amount of time. Wonder if it'd be feasible to add a cooldown timer of some sorts.
OFDL20251231.txt
EDIT: I'm not gonna pretend I know anything about how this downloader works, but looking through the log I see requests looking like this 69 different times all in the span of 15ish seconds before it starts to actually get the posts/messages from the creators. I'm guessing that has something to do with the dynamic rules trying to find the right data.
But towards the end when it crashes, it looks like its trying to make a request to
limit=50&order=publish_date_desc&format=infinite&skip_users=allagain even though it did it at the beginning already.Just want to report that this does seem to be fixed.
So last night, I updated to 1.9.20 and re ran the download purchased tab. It worked! It did spit out a handful of "429 too many requests" but it moved past it and proceeded to download all of my paid content. It worked one time.
Now its spitting out the same message then crashing like it was before.
Then I realized what the real issue was, rules.json was updated but the program never updated the rules.json (or at least it doesn't attempt to when doing the download purchased tab)
Other than that, this spits out in the console when doing the action.
Aside from the console bleed, I think its safe to say this issue can be marked as resolved!
rules.json is never updated by OF-DL. The dynamic rules are fetched automatically (but not stored on your computer) when OF-DL runs. If the dynamic rules source (this website) is ever offline, rules.json is used instead as a backup.
This should be relatively easy to fix now that the codebase has been refactored. We can add our own rate limiting in ApiService at the service level to ensure that all API calls are slowed down by OF-DL. We could do the same in DownloadService if needed.
I don't have the capacity to work on this now due to the major features currently in progress, but it should be an easy fix to implement.