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
Drops not advancing #284
Comments
Logs? |
I have some recent logs from yesterday. |
On the log appears to be some kind of thing with [send_minute_watched_events] because it appears like a couple of times but then even with the stream ON the is no more messages. Status: 204. |
Apologies. Updated OP with two errors I see that might be related. I've since updated to 1.8.2. No error, but still not incrementing drops. If I specify a single streamer to watch it will increment the drop. But not if I have a streamer list and have it pick based off my standard priority list:
In looking at the container log, it's in the chat for the user with the drop, but isn't watching as it's collecting channel points in 2 other chats. |
New set of errors which look like they might be related to deciding if a drop is available, or if the username already has the drop in inventory. DNS appearing to be the common denominator. That being said, there are currently drops which it's not collecting and those errors were a while ago.
|
I've sent you the logs on Telegram. |
@OrbitalCannon I got a response, turns out that i was blind, You can only watch 2 concurrent channels, so maybe you are using those slots and the program don't gets the watch time for those drops. |
Correct, only 2 channels can be watched at a time. With the priority list I posted above, it should be watching streak, then drops, then subscribed, then order, and I assume followed list after that. But that's not the behavior I'm seeing. |
I have the same issue (not sure since when). In the past I added a bunch of streamers to the config with |
Update on this issue. It applies to all drops. Unless the miner happens to be watching a channel already, or I specifically tell it to watch one or two channels it's hit or miss if it catches them. Almost like it either can't tell there are drops, or it doesn't know if I need drops. The errors mentioned in #284 (comment) continue to repeat occasionally. |
I checked the log and noticed a changed sha256 for the 20/07/23 15:54:10 - DEBUG - TwitchChannelPointsMiner.classes.Twitch - [post_gql_request]: Data: channel is 24/7 live with drops, request when Twitch UI does it returns
Pretty sure that's exactly it EDIT: after debugging this locally with just one channel in the config, the GQL endpoint started to return the correct data again, both with the changed sha256 and the one currently listed in |
I see, most likely related to DevilXD/TwitchDropsMiner#189 (comment) We can try the temporary fix too, by removing the drop_tags requirement in drops_condition in Streamer.py. I'll add the code, or maybe even release a temporary fix version soon. |
Funny, was about to comment that I got it fixed by removing the
I am too unfamiliar with how this is supposed to work but wouldn't the positive confirmation from |
I am also unfamiliar. ;) Looks like so. I guess __get_campaign_ids_from_streamer should be enough then. |
I made these two changes to a test container. EDIT: I'll monitor over the weekend to confirm fix, but it eventually did pickup a drop. |
After running it for a day, it seems to work, and I now see why the tag check was in there before. Right now (with the drops_tags check removed) it will try to get drops that are set for the future ( |
I'm far from familiar with writing Python, but something like this (I tried using the diff --git a/TwitchChannelPointsMiner/classes/Twitch.py b/TwitchChannelPointsMiner/classes/Twitch.py
--- a/TwitchChannelPointsMiner/classes/Twitch.py (revision 4fca577e8b703ae32619fe489f08f9f933485b04)
+++ b/TwitchChannelPointsMiner/classes/Twitch.py (date 1690037213547)
@@ -672,14 +672,21 @@
json_data["variables"] = {"channelID": streamer.channel_id}
response = self.post_gql_request(json_data)
try:
- return (
- []
- if response["data"]["channel"]["viewerDropCampaigns"] is None
- else [
- item["id"]
- for item in response["data"]["channel"]["viewerDropCampaigns"]
- ]
- )
+ if response["data"]["channel"]["viewerDropCampaigns"] is None:
+ return []
+ else:
+ campaigns = []
+ for item in response["data"]["channel"]["viewerDropCampaigns"]:
+ if "timeBasedDrops" in item:
+ drops = list(map(lambda x: Drop(x), item["timeBasedDrops"]))
+ drops = list(
+ filter(lambda x: x.dt_match is True and x.is_claimed is False, drops)
+ )
+ if drops:
+ campaigns.append(item["id"])
+ else:
+ campaigns.append(item["id"])
+ return campaigns
except (ValueError, KeyError):
return []
for someone else looking into this, a current campaign is active, but most drops are time locked for a week from now |
Did not fix. Have a drop that hasn't incremented for 2 days. |
@jabbink have you tried applying your code with the filter to your miner? Did it work, any issues? |
Yes, the code from 2 comments above works perfectly fine for me. Had no issues until 2 or 3 days ago when claiming drops stopped working (unrelated to this change though, time keeps on increasing) |
Updated to 1.8.4 today and switched to the latest example.py. So far I have 2 drops that should be advancing but are not. The miner is reporting gaining points on other channels. No errors in the log. The miner seems to be present in the streamer's channel, but is collecting points elsewhere. I assume points and drop % are both triggered off the same activity? |
@OrbitalCannon I'm tired of answering this. It is in the README and in the Twitch.py: |
I'm not so familiar with the whole drops logic, but there is also a useful comment: |
My comment wasn't directed at collecting points in every single channel, the miner can only collect points in any 2 channels at one time as mentioned in the README which I've read and understand. My priority list seems to be getting ignored or drops aren't being detected and the miner is in other channels when it should be in the drop channels. Example: There is an overwatch2 drop and a Marbles on Stream drop currently available for me. The miner is instead in two unrelated Zoo channels which I'm following.
Correct, I'm aware for any one drop you can only collect progress from one channel. Meaning if there are 2 drops and I have a Chrome/Firefox tab open for each of them it will advance both drops. If there is 1 drop and 2 tabs, it will increment at the rate of 1 tab. This works the same with the miner. |
after the issues I've had over the past weeks I looked a little bit more into the drop algorithm, and it's not necessarily ideal for example it will add 2 streamers to the list of watching streams despite it already being known you can only advance one at a time; furthermore there is no prioritization on drops expiring sooner; then the issue from a few comments above (about it trying to advance locked drops currently) |
@OrbitalCannon from the above comment, maybe run the code in a debugger to see why it's not picking up the expected streams by putting a breakpoint in that function. It's the selection algorithm. Possibly an idea to add debug logging for this to be able to see it in the logfile by default without checking for the minutes sent log line (giving no reason on how it was selected) |
DevilXD refuses to offer a console only or Docker integration unfortunately. |
@OrbitalCannon I see. I was referring to this
and instantly thought about the 2 streamer limit. Now that you've explained the priority issue, it is getting clearer, thanks. There is a wider issue with |
Ah yeah, I could see the confusion there. When I said that I was meaning the miner denotes a I have observed the issue with not claiming drops automatically as of recent as well as mentioned in #333 , keeping an eye on that one as well. |
@OrbitalCannon joining the IRC channel does nothing besides notify you when you get mentioned (and set that up in the config) and give you "points" on channels that use third party bots to do so (e.g. streamelements) a common issue I've heard from people trying to debug drops is that they have watch streak as highest priority followed by drops, and when you then start the bot, it will get 7 minutes of watch time for every channel that is live right now, because it attempts to get the watch_streak point event (which won't happen, as you already got the streak before you restarted the bot). So before you even start gathering any drops with this (with the priorities set up as I mentioned), you would have to wait 7 minutes x amount of online streamers in your config (+ potentially followed streams) / 2 |
Well that's interesting. That is the config I have at present I wonder if there is a way to shorten the watch streak time. When a streamer goes live I get the notification about the watch streak within a minute or two. |
a sidenote I forgot to mention earlier: if you're also watching in a real browser, it overrides the minutes watched sent from this tool, so e.g. you are actually watching someone, and then this tool watches one stream for the "streak", and another for the "drop", you might override the "drop" stream with your real human activity. You can see this in the log via discrepancy under sending minutes watched and getting the +10 channel point logs (mentioning different channels) |
Curious if that could be lowered to 1 or 2 mins and still catch streak bonus. Would significantly decrease the amount of time spent catching streaks. I have seen the discrepancy if watching on a browser and running the miner. Mostly having the miner take up my 2 view slots and not being able to earn channel points and drop minutes in a browser. So far, removing |
So removing Twitch-Channel-Points-Miner-v2/TwitchChannelPointsMiner/classes/Twitch.py Lines 413 to 418 in 8124724
Sanity check. Has this been tested at lower values? I figured I'd start with 1min in there to see if a lower value would work. |
Preliminary tests seem to indicate setting this to
|
Running over the weekend changing
to and streamers[index].stream.minute_watched < 1 has functioned as desired. |
I am additionally testing this. I have started now and will watch how it performs over the weekend and into next week. |
Catching streaks was causing rdavydov#284 to stall out and constantly try to catch streaks. In my testing streaks take less than 1 minute to catch. Reducing from 7 mins to 1 allows the miner to be more efficient about switching back to what it was doing prior to catching the streak.
Still functioning as desired. Part of me wonders how low we could go with it. But 1 min seems fine. I'll submit a fork and pull request. |
Catching streaks was causing rdavydov#284 to stall out and constantly try to catch streaks. In my testing streaks take less than 1 minute to catch. Reducing from 7 mins to 1 allows the miner to be more efficient about switching back to what it was doing prior to catching the streak.
Describe the bug
Marbles on Stream drops are not progressing despite following appropriate channels and restarting container. It progresses and collects other drops fine.
Steps to reproduce
Expected behavior
Marbles on Stream drop progresses with watch time.
Operating system
DISM 7.1.1
Python version
3.11.4
Miner version
1.8.1
Other relevant software versions
No response
Logs
Two error entries regarding Inventory/drops.
Additional context
No response
The text was updated successfully, but these errors were encountered: