-
Notifications
You must be signed in to change notification settings - Fork 20
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
New Drops are not counted #138
Comments
Apologies, I accidentally closed the issue by mistake Sorting the currentDropsList and tracking the latest drop timestamp can be a more efficient way to handle this problem
Create an instance of DropTracker somewhere in the script. This approach dynamically updates latestProcessedDropTime based on the most recent drop it processes. It does not use a fixed time window but instead ensures that only drops newer than the most recently processed one are considered. As a result, it inherently accounts for any delays or gaps between checks. Here is the updated Rewards.py that I will be testing for the next couple of days. |
I don't think I've seen anyone else raise a similar issue and I've been busy lately, so let me know here if you get any results on your end! |
This approach dynamically updates latestProcessedDropTime based on the most recent drop it processes. It does not use a fixed time window but instead ensures that only drops newer than the most recently processed one are considered. As a result, it inherently accounts for any delays or gaps between checks. Yudaotor#138 (comment)
Issue: Yudaotor#138 To address this, I implemented a delay and retry logic. This ensures that the earnedDrops endpoint is always captured in the performance log when visiting the reward page. The key changes include adding a retry mechanism with delays, allowing sufficient time for the logs to populate.
Hi @Yudaotor I’ve determined that the getRewardByLog function in NetworkHandler.py is the cause of the problem. Issue DetailsThe issue occurs when revisiting the reward page after the initial visit. If the earnedDrops requests are not present in the performance log (driver.get_log('performance')), the stats object is not updated, and we end up with drop data from the initial request only. SolutionTo resolve this, I implemented a delay and retry mechanism. This approach ensures that the earnedDrops endpoint is always captured in the performance log when visiting the reward page. The key changes involve:
With these changes, I’ve finally seen new drops reflected in the GUI after months of not being able to. The connector is now functioning properly as well: Fix Commit: aeb9636cd2f8f761bd8ed453e6903c7339582131 Additional Enhancement: A new class to track new drops more effectively: 298dd54e2cdb1896fbf36a8d9c866c0564cd88b6 I can create a pull request if other users are experiencing the same issue, or if you would like to review and merge these changes. Please let me know how you'd like to proceed or if there's anything else I can assist with. |
入围赛确实没有一个罐子掉落,我2个号都是这样... |
I noticed today that I haven't received any webhook drop notifications since March, so I began investigating the issue.
I found that I hadn't set countDrops to any value in my config file. However, as I understand it, countDrops defaults to True. Therefore, this should not be the cause of the issue
EsportsHelper/EsportsHelper/Config.py
Line 85 in a3429db
I tested the webhook by setting connectorTest to True, and it succeeded. This indicates that the webhook itself is working correctly.
I debugged currentDropsList, and it successfully retrieved and set the data.
Based on my findings, I suspect that the issue may be related to the following line of code:EsportsHelper/EsportsHelper/Rewards.py
Line 544 in a3429db
If unlockedDateMillis is older than stats.lastDropCheckTime - 6000, that drop will not be included in the newDropList i think that's the issueAs I understand, stats.lastDropCheckTime is updated at the end of the checkNewDrops function. The frequency of checkNewDrops calls is influenced by delays and sleep periods in watchMatches function in (Match.py)EsportsHelper/EsportsHelper/Match.py
Lines 105 to 232 in a3429db
Should we subtract the maximum possible delay or sleep time (whatever is greater) from stats.lastDropCheckTime to ensure that no drops are missed? Increasing the time window or adjusting the logic to account for potential delays might resolve the issue.max sleep time as i understand is 1 hour
Please let me know if this adjustment would help or if there are any other factors to consider. Also, it would be useful to know if other users are experiencing the same issue. I have yet to test this change since I haven’t received any new drops recently.
Thank you!
The text was updated successfully, but these errors were encountered: