-
Notifications
You must be signed in to change notification settings - Fork 359
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
Auto claiming drops stopped working? #333
Comments
I've been getting the same issue using docker on Linux and a friend said he's getting the issue running on windows |
You are not alone. I've got the same issue for a very very long time and mentioned it once. I was told its an issue on my end so I just restart when I notice its stopping to claim. Just happened again. |
Hm strange, at least it doesn't seem I'm alone, thanks. I've never had that happen before, using the container since a few months. |
Guys, you should look at previous open issues, before submitting a duplicate. |
Ah I see. I saw that issue actually but just read the initial posting and dismissed it because it was a special case and open a while longer while it was still working for me. Plus the description doesn't fit a 100% (progress vs. claiming). I did not read the comments that followed until the latest. That explains it. My bad, thanks for pointing it out. Will close this issue. |
Thanks. 谢谢! |
As I understood:
Correct? |
Ok, sure 👍 Yes, the summary is correct. For me it didn't matter which drop, but great you found the same to test with. |
I also noticed that the drops are not taken by hand (due to an error that allegedly the browser does not fit), I turned on the vpn, and took it with my hands. This error came out as I made 26 twitch accounts |
I can give you a ready-made account, with a drop, so that you don't wait |
Can you add pls a log in the telegram that there is a drop on a certain account. Just if you set the method to pick up the drop at the entrance, it is picked up. |
Create a new detailed feature request, it is off-topic here. |
@pchristod and others: are you also not getting the info messages in the console and in the log about the campaign? And there should also be a drop.progress_bar(), I'm not seeing it. |
In the search in the logs, I did not find drop.progress_bar() |
By drop.progress_bar() I meant the actual visual progress bar in the console. |
Note for me: most likely the fix in 8124724 is incorrect. |
i have the same error but paying attention to the execution of the code, I noticed this error : Exception in thread Sync campaigns/inventory: |
and in the code I changed only in main.py line 24, replacing false with true |
@rdavydov How would that look like vaguely? I'm not seeing any visual indicators related to Drops/Campaigns in the Console as far as I can tell. The only thing related to drops when Debug Mode is on, is something like this (snippet):
I have logs from last week where the whole auto claim during runtime still worked. There I'm seeing output like this (no Debug mode), which is missing in the newer logs, obviously because they are not auto claimed: |
Note for me: def __get_drops_dashboard(self, status=None):
response = self.post_gql_request(GQLOperations.ViewerDropsDashboard)
campaigns = response["data"]["currentUser"]["dropCampaigns"] for some reason it returns In the browser:
returns Bummer if it is because of the |
If it can help you, I had created a small script for Twitch drops :
|
Note for me: def __get_drops_dashboard(self, status=None):
# response = self.post_gql_request(GQLOperations.ViewerDropsDashboard)
response = self.post_gql_request(GQLOperations.Inventory)
# campaigns = response["data"]["currentUser"]["dropCampaigns"] or []
campaigns = response['data']['currentUser']['inventory']['dropCampaignsInProgress']
if status is not None:
campaigns = list(
filter(lambda x: x["status"] == status.upper(), campaigns)) or []
return campaigns doesn't fix the issue, because __get_campaigns_details also returns ["data"]["user"]["dropCampaign"] as None. |
This is related to the same issue where for the TV app client ID not only the Same issue in "the other" repository to watch in case they find a solution: DevilXD/TwitchDropsMiner#264 |
Yep, that's the major problem. I've been experimenting all day, looks like there is no solution ATM. Probably can add a very dirty hack to sync_campaigns to just call self.claim_all_drops_from_inventory() every 60 mins. Very poor "solution", but I just don't see any other way now. |
Wow, developing anything for Twitch seems just horrible as they constantly change things. I would agree to those kind words, thank you for putting work into it 😊 Honestly I don't even like the Drops system, but using a bot i can at least get the rewards without doing it actively so the miner is just awesome. |
hi
|
... |
You're doing something completely wrong. First of all, how do you run the miner? Exact detailed steps, please. |
wait |
I just put the name and psw in the replit secret (with the appropriate names) ah, maybe i understand.... the reason is because i imported the code from github?? |
|
bro, I'm very stupid, forgive me, I've only been using github for a while |
bro, i made a replit with version 1.8.5 (also with keep_alive), do you want me to send you the name? |
if you don't like it, I'll immediately delete the link |
@rdavydov it might be fixable by intercepting the WebSocket message and claim based on it {
"type": "MESSAGE",
"data": {
"topic": "user-drop-events.UserID",
"message": "{\"type\":\"drop-progress\",\"data\":{\"drop_id\":\"DropID\",\"channel_id\":\"ChannelID\",\"current_progress_min\":59,\"required_progress_min\":60}}"
}
} |
Seems to work for me in WebSocketsPool.py there's probably a better way, but I don't have the drop instance ID here elif message.topic == "user-drop-events":
if message.type == "drop-progress":
if message.data["required_progress_min"] == message.data["current_progress_min"]:
ws.twitch.claim_all_drops_from_inventory() and of course subscribe to it self.ws_pool.submit(
PubsubTopic(
"user-drop-events",
user_id=user_id,
)
) |
Even better, there's I put the claim GQL request there and it works flawlessly {"type":"MESSAGE","data":{"topic":"user-drop-events.UserId","message":"{\"type\":\"drop-claim\",\"data\":{\"drop_instance_id\":\"DropInstanceId\",\"drop_id\":\"DropId\",\"channel_id\":\"ChannelId\"}}"}} |
As I implemented it in my version I have some feedback on it. While it seems to work on the web version, the Android TV client doesn't seem that have the permission to use it (i don't know for the mobile client). Subscribing to the topic leads to a ERR_BADAUTH response from the WS api.
Do you have an auth made from the android client when you did your tests? |
I have used the |
Ok must be my bad, I guess |
Yes, it's your own user id, just like |
I can also confirm claiming drops is not working at all for me, both campaigns and single drops never seem to auto-claim. I keep seeing this message in my logs, but it has never managed to succesfully actually claim it. 21/12/23 14:52:33 - INFO - TwitchChannelPointsMiner.classes.Twitch - [claim_drop]: Claim Drop(id=d15b1263-8ecf-11ee-9000-0a58a9feac02, name=Mamba Luminae Polaris SKIN, benefit=Mamba Luminae SKIN, minutes_required=120, has_preconditions_met=True, current_minutes_watched=120, percentage_progress=100%, drop_instance_id=44678773#ac5fc373-8ecf-11ee-ba99-0a58a9feac02#d15b1263-8ecf-11ee-9000-0a58a9feac02, is_claimed=False) There are no errors or any indication in the logs why it would have failed to grab |
Seems like this caused by |
It has been working for me but I've been running the bot for a while. It doesn't always seem to claim but later on it gets them I think. Regardless when I go to watch Twitch I've been checking and finding none that need claimed. |
How you see that? I see only drop progress updates. |
Describe the bug
Since a few days (somewhere in between last friday and yesterday) the miner started having problems with the auto claiming of drops. I thought at first this was a problem of the latest release so I temporarily reverted back to 1.8.3 with the same problem. It seems though that there's only a problem while the script is running, restarting the Miner (and having set claim on startup variable) will do the claim fine. Am I the only one having that problem or is there something with the Script/Twitch API?
Thanks!
Steps to reproduce
Expected behavior
Claim Drops automatically like it used to until a few days ago when having 'claim_drops=True' set
Operating system
Docker on Synology NAS
Python version
Docker on Synology NAS
Miner version
latest
Other relevant software versions
No response
Logs
https://gist.github.com/pchristod/1d40e20200023768a3e057167b435622
Additional context
I've tried to capture the issue by starting some random drop campaign and setting the log to Debug (see the ling to the gist). The Drop named 'Necroghouly Wraith' is still sitting unclaimed in my Inventory.
The text was updated successfully, but these errors were encountered: