-
-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Miss drops due to randoming changing what part of the hour check for campaign. #428
Comments
Hello o/
Correct, the maintenance task will automatically reload the application every up to 60 minutes. The reload period can be shorter, if the miner deems necessary. The "three seconds" you're seeing is how long the logic takes to process the reload order.
The maintenance task uses an internal list of time triggers, to decide when to perform a reload. If no campaigns become active within the next hour, the wait time is 60 minutes. If a campaign becomes active in the "last 15 minutes" of those 60 minutes, the wait time is 45 minutes, after which a reload is performed for every campaign that starts. In order for the miner to know that a campaign starts in 45 minutes though, it has to be added to the Twitch drops system at least an hour before it starts. If the game developer adds the campaign 15 minutes before it's supposed to start, the miner won't know such a campaign even existed (because it didn't exist on the last reload), and won't do anything until after 60 minutes pass and a normal reload is performed. Only then it'll learn there's a new campaign that's already active, and pick it up as a mining target. There's nothing the miner can do to fix this - if the developer won't add the campaign beforehand, there's no way to predict when one will be added. Checking more often than 60 minutes is not an option, that's done to avoid bothering Twitch too often. A "barrage" of ~40-80 requests every hour is already more than an average user will achieve during normal website usage. If the above doesn't happen though, then as long as the campaign is added at least an hour before it starts, then the miner should pick it up automatically right after it starts, without missing anything. |
Hi, same thing happens to me for Warframe's drops.
Here's the output.
Wasn't at home all day so didn't see if they turned on drops less than an hour before the first stream started, which is probably why the miner didn't pick it up. But changing the reload time to happen exactly at the top of the hour would imply a traffic spike on Twitch's side, which could be potentially flagged. (but still forced a reload at 7pm?) |
A reload that happens more often would help resolve this. A partial reload flow was brought up and is tracked by in #301. |
I don't know what to say or do here. Partial reload is already tracked by #301, and I won't be making the reload process happen at exactly a round hour, because it's pointless. The miner already tracks the campaign start and end times, and already will perform a reload sooner due to that, so there's nothing to change here. I'm calling this a NoFix from my side. |
When first starting the program, it will check for active campaigns every 60 minutes three seconds.
If the campaign starts at the top of the hour and only lasts 45 minutes and the drop happens after 15 minutes of watching, it will be missed if the check happens at 55 minutes( five minutes before the top of the hour.)
The only way to set this is to start the program at 5 minutes after the hour. But this get messed up after watching a campaign and goes back into wait mode.
In my case, I started the program at 5 after the hour. After a couple campaigns, it now checking at :51. Not desired due to now is missing the short campaigns.
The text was updated successfully, but these errors were encountered: