Rust campaigns: Waiting for an ONLINE channel (channel tags are not being updated)

[Slinetina]

Im unable to switch streamers during the current rust campain. i have 5 i can switch to and the rest (about 60 of them) i can not switch to all of them are online and playing rust right now...i can watch and clain in twitch but not through the miner

[nudave]

Same issue here. Seemed to have started with the Rust drops...

[Stiphr]

I'm facing the same issue

[DevilXD]

Hello o/

The condition for switching to a particular channel is the same as for channel auto-selection - it has to be a valid mining target. And that means, besides being ONLINE and other things, that it needs to have the drops enabled. From the picture, only the currently selected channel qualifies:

If the streamer adds the tag more than 2 minutes after the stream begins, the miner might miss on that happening. Assuming that's what happened, reloading the miner manually will fix the issue. If the streamer went online but didn't add the tag at all (yet), progressing the drop will be impossible, either the normal way or through the miner - this is a streamer error, not the miner's.

As far as fixing the possibility of missing on the tag being added, it'd require adding another event topic to subscribe to via the websocket, which means the channel tracking capacity of the miner would reduce by 33%, from 199 to 132. There's some optimizations I could make regarding this, like only subbing the topic once the channel goes online, as that's the only time we should care about the tags being updated, which would allow for tracking between 132-199 channels, but that introduced a dynamic channels range that'd need extra logic to allow "pruning" the channels due to needing more sub topics. I can't find the time to handle any of the other remaining issues, yet alone implement something bigger like this one is, so for now, you'll need to either rely on auto-reload which will pickup on the tag changes after an hour, or manually reloading the miner.

This issue can remain open to track this feature being added in the future, hopefully.

[Stiphr]

Hello o/

The condition for switching to a particular channel is the same as for channel auto-selection - it has to be a valid mining target. And that means, besides being ONLINE and other things, that it needs to have the drops enabled. From the picture, only the currently selected channel qualifies:

If the streamer adds the tag more than 2 minutes after the stream begins, the miner might miss on that happening. Assuming that's what happened, reloading the miner manually will fix the issue. If the streamer went online but didn't add the tag at all (yet), progressing the drop will be impossible, either the normal way or through the miner - this is a streamer error, not the miner's.

As far as fixing the possibility of missing on the tag being added, it'd require adding another event topic to subscribe to via the websocket, which means the channel tracking capacity of the miner would reduce by 33%, from 199 to 132. There's some optimizations I could make regarding this, like only subbing the topic once the channel goes online, as that's the only time we should care about the tags being updated, which would allow for tracking between 132-199 channels, but that introduced a dynamic channels range that'd need extra logic to allow "pruning" the channels due to needing more sub topics. I can't find the time to handle any of the other remaining issues, yet alone implement something bigger like this one is, so for now, you'll need to either rely on auto-reload which will pickup on the tag changes after an hour, or manually reloading the miner.

This issue can remain open to track this feature being added in the future, hopefully.

I've tried restarting and reloading, but it still isn't working. Strangely, manual farming works fine.

[rustyvanilla]

same problem here, I left it running overnight to mine Rust drops
it mined 7 drops then stopped, currently displaying this message:

No available channels to watch. Waiting for an ONLINE channel...

I think the problem is it's not correctly marking channels with drops enabled

reloading didn't work --- the weird thing is it only marked a channel called "sleepy" as drop enabled and they're playing a different game

[DevilXD]

Hmm, that's strange then. I've seen a while ago that Twitch has updated it's tags system a bit, where it now allows "free form" tags to be added to streams. It seems problematic though, considering the "drops enabled" option being enabled for a stream can no longer be deduced from a particular channel's tags. Anyone can add a fake "Drops Enabled" tag and trick the miner (and viewers too), and also one can just enable the option but don't add the tag. At least that's has far I was able to see it works.

I'll try to find some time to dig into this matter further, and see if I can help it a little.

[rustyvanilla]

I see! I think they list the participating channels for each drop in the https://www.twitch.tv/drops/campaigns page, maybe we could pull it from there? either way take your time and thanks for quick response!

[DevilXD]

That list is already pulled from there, That's not the issue. The issue is, for a drop to be progressed by watching a particular channel, all of these have to be true:

• A campaign has to be in the "Active" state.
• If defined, the campaign's channels ACL (that list you've just mentioned) has to include the particular channel.
• The particular channel has to be ONLINE.
• The particular channel has to have the drops enabled in the streamer dashboard (this is the part that doesn't work).

So far, determining this "drops enabled" setting was done via a channel tag, that each channel had automatically added if they enabled the drops for the channel. This is done via the streamer dashboard, per the FAQ:

https://help.twitch.tv/s/article/mission-based-drops

https://dashboard.twitch.tv/drops

Now, it seems that the tag is no longer added, so the miner cannot determine if a channel has that option enabled or not. As far as I understand it, users can now manually add a fake "Drops Enabled" tag to let the users (who were familiar with the old system already) know the drops are enabled, but it's no longer something that can be used to determine if that option is enabled or not, and I need to find another way. The interesting thing is that the channel search used for finding livestreams with drops enabled, which also uses this old tag to do the search, still works as before. There should be a way to determine that information with the new tags system, but as I said, I haven't had the time to really look into it yet.

The simplest "fix" for now would be to just skip checking for the drops enabled tag. The miner might end up trying to watch a channel with the drops being disabled because of that (and thus get stuck not progressing any drops), but at least it'll work with Rust. A temporary fix is better than nothing.

[DevilXD]

I'm at work, but this is the best I can do for now: 1df916f

Please try the latest master branch.

[rustyvanilla]

the temporary fix works, thank you!

[chambom8]

I'm at work, but this is the best I can do for now: 1df916f

Please try the latest master branch.

We appreciate it <3

[letum00]

Thank you @DevilXD this is working well for this particular Rust campaign. The miner is correctly switching to channels and getting the drops.

Even now, checking for the tag at https://twitch.tv/directory/game/RUST?tl=c2542d6d-cd10-4532-919b-3d19f30a768b shows only five streamers using the correct "Drops Enabled" tag. Many streamers seem to be using a typed tag, specifically "DropsEnabled" or "DropsActivated."

Perhaps an option to toggle the specific tag versus a custom tag at the risk of the miner accidentally watching a troll stream instead of a valid drop stream? Thank you again for your time and efforts.

[DevilXD]

Perhaps an option to toggle the specific tag versus a custom tag at the risk of the miner accidentally watching a troll stream instead of a valid drop stream? Thank you again for your time and efforts.

This "typed tag" is not reliable, as far as I understand it. It's added manually by the streamers, meaning that one can simply not add it at all but still have drops enabled, or misleadingly add it without enabling the drops, and neither us nor the miner would know it. Please correct me if I'm wrong about this.

A different, more reliable solution needs to be figured out long-term. Worst case scenario, a system that'll "try out" a channel for ~5-10 minutes to see if it can progress a drop will need to be implemented. But it only complicates the already complicated internal miner machinery that's already there.

[fraizzo]

i think there is a problem with the rust drop also, from about 4 hours not works also from browser

[Santya95]

Guys to have the bot fully working you need to compile the source code.
Now download the zip of the source code from the main page of the project.
Extract the main folder and put in your desktop
Install git and python (Must install them in order to proceed)
Open CMD with admin
In the CMD type: cd C:\Users\YOURNAME\Desktop\TwitchDropsMiner-master
Now in the CMD type: setup_env.bat and wait for it to finish
When it finish type: build.bat
When this finish in the bot folder you previously extracted a dist folder should be created and you'll have the exe updated with the latest fix to switch channel

[fraizzo]

Guys to have the bot fully working you need to compile the source code. Now download the zip of the source code from the main page of the project. Extract the main folder and put in your desktop Install git and python (Must install them in order to proceed) Open CMD with admin In the CMD type: cd C:\Users\YOURNAME\Desktop\TwitchDropsMiner-master Now in the CMD type: setup_env.bat and wait for it to finish When it finish type: build.bat When this finish in the desktop folder a dist folder will be created and you'll have the exe updated with the latest fix to switch channel

Can you compile for us?

[Santya95]

Guys to have the bot fully working you need to compile the source code. Now download the zip of the source code from the main page of the project. Extract the main folder and put in your desktop Install git and python (Must install them in order to proceed) Open CMD with admin In the CMD type: cd C:\Users\YOURNAME\Desktop\TwitchDropsMiner-master Now in the CMD type: setup_env.bat and wait for it to finish When it finish type: build.bat When this finish in the desktop folder a dist folder will be created and you'll have the exe updated with the latest fix to switch channel

Can you compile for us?

https://drive.google.com/file/d/1hQCzWNmbJ3gWqRNNWT6YxyAexx8tyfvg/view?usp=share_link

No problem

[fraizzo]

Guys to have the bot fully working you need to compile the source code. Now download the zip of the source code from the main page of the project. Extract the main folder and put in your desktop Install git and python (Must install them in order to proceed) Open CMD with admin In the CMD type: cd C:\Users\YOURNAME\Desktop\TwitchDropsMiner-master Now in the CMD type: setup_env.bat and wait for it to finish When it finish type: build.bat When this finish in the desktop folder a dist folder will be created and you'll have the exe updated with the latest fix to switch channel

Can you compile for us?

Really thanks, it works now

[skupfer]

This "typed tag" is not reliable, as far as I understand it. It's added manually by the streamers, meaning that one can simply not add it at all but still have drops enabled, or misleadingly add it without enabling the drops, and neither us nor the miner would know it. Please correct me if I'm wrong about this.

How about a custom tag list. I know this also isn't a great long term solution either, but the user would be able to maintain it themselves in this case. Feed it with the most common ones and let the user decide what else to add.

[DevilXD]

How about a custom tag list. I know this also isn't a great long term solution either, but the user would be able to maintain it themselves in this case. Feed it with the most common ones and let the user decide what else to add.

That does not solve the issue of the "free form tags" being entirely dissociated with the actual setting state. The tag's existence, or lack thereof, isn't indicative here. It can't be relied on, at least entirely. It can be taken as something that's added "in good faith" of the tag's existence potentially confirming the setting is enabled, but at that point I'd rather create a system where all channels start as ones that have the drops enabled, and if the miner does not receive any drop progression from a particular channel, then it considers it's drops option is disabled and switches to a different one.

Unfortunately, with the Twitch API being so unreliable about the drop progression reporting, it'd most likely run into constant false-positives. I'm not sure until I'd attempt to add such system and test it of course, but that's my expectation. The miner currently has three (3) different ways of trying to make sense of how Twitch returns drop progress, those being "the usual way" of waiting for a websocket event, "the hard way" of asking GQL about the currently mined drop (if websocket doesn't respond), and if even that fails, then finally "the probably way" of scanning the entire inventory for drops that could potentially be earned on the channel it's currently watching, sorting them by descending progress percentage, and artificially advancing the top drop's progress by 1 minute, literally hoping that drop is the one being progressed. Usually this works fine. Before 14b0259, it could even "fake" a drop being progressed on a random game, that wasn't even added to the priority list.

I have very little personal time to properly sit down and think of a solution here. If you want to help and you're going to suggest anything, please start with what Twitch returns out of it's responses first - hopefully something there can be used to determine the setting state. If we can't figure out anything useful, then this "testing channels" approach I've explained above will remain as a last resort good option for doing this.

[TinyNStrong]

ok so i have tried everything that my tiny little pee brain who doesn't understand code can try to do I cant quite comprehend exactly what needs to be done to access the new code you put in i tried that google drive link that didn't work i tried the new master branch download that and i don't see a program that can be run in the files i tried figuring out the command prompt section and cant figure out that whole thing. any help would be greatly appreciated.
i would like to add thank you for all your time and dedication to this as i can see it is just a helpful program you created and you do have a life outside of creating this one specific thing. so from a grateful user thank you for any time you are putting towards this thing at all it is much appreciated,.

[DevilXD]

Hi. First of all, please try to keep issues free of off-topic discussion. Speculations are fine, but dropping in and talking about an entirely different issue is a no-no.

@presto053 If you have a problem with the miner that isn't related to this exact issue's topic, please open a separate issue for it.

As a side-note, I can atest that the miner is free of anything that could cause you getting banned in-game. Not through the EAC at least, I play a game that uses EAC myself and never had any problems myself. If you don't trust the executable, there's still an option of just running it from source. The executable is only there for people who wouldn't want to bother installing Python for this.

[DevilXD]

@presto053 For your information, I've already told you that matter has exactly nothing to do with this issue, which is about the "Drops Enabled" tag not being available in all cases now. Unless you are having the same issue, or have anything that would actually contribute to this issue, please just create a new issue and put your thoughts there. This is the last warning from me, before you have the ability to comment and open issues revoked here.

As a "for your information" to everyone else here, #177 has just been merged, and a pre-release development build is now available on the Releases tab: https://github.com/DevilXD/TwitchDropsMiner/releases You can use it to get the latest temporary fix for this issue, in a built executable form instead of having to compile the miner yourself.

[DevilXD]

I've tried to figure out a solution for this, and found something promising. There is a DropsHighlightService_AvailableDrops GQL call, that takes in channel ID and supposedly returns a list of campaigns that can be progressed in the particular channel. It also supposedly won't return any campaigns when the "drops enabled" option is turned off. The miner currently doesn't use this call at all, but it's already prepared to be used where necessary.

It'd be cool to avoid additional API calls for this, but I'll try to implement if if no better way exists. I'll keep searching. I also want to note that I have about a month or two of 10/6 delegation work coming up, starting next week, so it'll be challenging for me to find the time for an implementation, but I'll still try doing it in the off hours.

[Snappy9]

What should I do to make it work for me?

[DevilXD]

@Snappy9 Nothing, this is still an open issue for a reason. I'm currently struggling to find the time for it, as it requires quite a bit of changes to the internals to implement. I've also been thinking about pushing #220 instead, and handle this issue somewhere along the way, but that'd require even more time, that I don't currently have.

This project is popular, and with popularity come issues. They're appearing faster than I'm able to squash them out. I've said that before, and I'll say it again - in case anyone capable is reading this, I'm looking for a maintainer to this project. Even something as simple as tackling down a single issue via a PR would be appreciated.

[DevilXD]

Using "AvailableDrops" for each channel has been implemented over 9 months ago (163a056), and has been doing okay ever since. It's not ideal, but does it's job I guess. This issue can now thus be closed already.