Miner is not selecting a channel to watch sometimes

[ghost]

Not all channels that can earn drops are displayed in the list or cannot be selected (it's not about new bugs, it's always been like that.). If it is possible to implement manual input of the channel name - so that the application checks that it has the actual drops required by the user and starts collecting (or no checks, just forced operation with the specified channel) - it would be great.

I saw your comment about what the program is for and completely agree with you. Just as an idea for the future, "just in case". Theoretically, this feature would be useful for collecting drops. Recently, SMITE added two different drop at the same time - one regular, another with limited skins for watching 5-6 channels. They were mutually exclusive (i.e. you won't get the first drops for watching those very "5-6 channels"). In that case, program duplicated the columns with the checkout. And apparently, if the first check is unsuccessful, then even if the second check is successful - channel cannot be selected for viewing. Thus, the necessary "5-6 channels" failed the first check for regular drops, and it was impossible to start collecting "special" drops from them (or maybe reason was different, but result was the same - channels were not selected)

[DevilXD]

Hello o/

All of this reads like you're using v15, which isn't stable for over half a year now, due to changes Twitch introduced since then. No manual channel input should be required, you should be able to select an applicable channel for mining, as long as it's online. "Force watching" a channel has no purpose if it isn't going to progress any drops, and if it is going to progress any drop, then the application will already have all information needed to figure out a channel it can watch to progress it.

That's the idea behind the miner. If it ever becomes impossible to figure out which channels can be watched to progress drops, only then I can start thinking about adding such option. Until then, I see no point.

[ghost]

I forgot to specify, version 16.dev, built kinda about May.

Maybe I didn't explain well enough what this functionality is for (I'm using a translator, sorry). Normally, when mining starts, you have channels displayed as a table - channel, status, game, check, viewers, points. In the case I gave for the example, SMITE had two drops running at the same time. The program duplicated some columns, as a result it looked like this: channel, status, game, check, game, check... (I don't remember very well what is listed where, so I may have gotten confused about where what data is listed) The gist of the example is that there are two drops for SMITE at the same time. The first channel is suitable for farming only the first drops. The second channel is for farming only the second drops. But the second channel is not selected in any way, although it fits the conditions, it has active drops on the desired game, and it is online. If you turn it on through the site - drops will be farmed. So everything is fine. It just doesn't pass some kind of check in the app or something.

Now for the reason I was talking about "manually entering the channel". I noticed that not all channels are showing up in the list, even though they are with drops connected. For example, I'm watching a stream, but decide to run the program, and I see that the streamer I just watched is not in the list (even though it's still online). So far I haven't had any problems with this - you just select another streamer and mine. But in the most unlikely situation, when the desired drops will be streamed by one or two people, which the program does not find / does not display - it will be sad). Do I understand correctly that all program resources are executed only on the user's PC? I mean, why not make some kind of "I know what I'm doing" button for emergencies?

[DevilXD]

why not make some kind of "I know what I'm doing" button for emergencies?

Because that takes time, a resource which I'm already struggling with pretty hard. There's no point for me to spend time implementing a feature that isn't needed for the miner to work, I'd rather try and fix the already-existing logic of channel selection instead.

The program duplicated some columns, as a result it looked like this: channel, status, game, check, game, check...

This is impossible, as everything would break if there would be more columns than expected, especially ones with identical names. The existing logic cannot over-generate more columns either. It sounds like you're not really using the latest dev version, but some kind of a fork that's been modified by someone else - in which case, I cannot provide any support for you.

The "2nd channel" not being selected is also unlikely, as it works for everyone else (me included) but you. You seem to be confused about the GUI in some way, the channel has to be ONLINE and applicable to any of the campaigns you can claim a drop for, meaning you need to have your account linked as well.

Either way, without some actual pictures and/or logs from your miner instance, I cannot provide you any more help. Please show me what you actually see and what's happening.

[ghost]

Used a hand-build (without modifications) of your project, following your instruction. Built around May. https://github.com/DevilXD/TwitchDropsMiner/wiki/Setting-up-the-environment,-building-and-running Does the app write logs by default? Only cache, cookies, and settings are in the folder. I don't have any screenshots from that time, unfortunately, and that old version doesn't work anymore. Today I upgraded to the current dev version, and will check sometimes for similar drops

I could be wrong with how I showed it in the picture, but truly at that point I could choose any streamer channel except couple vtubers with their own drop. For now, mining Rainbow Six - no problem... Let's hope I was wrong \ it's been fixed since the old version. And I'm sorry for the inconvenience - apparently there's no way I can provide proof of the issue.

[DevilXD]

Yeah, "built around May" sounds pretty old. The #264 issue that broke the miner recently, forced a Client ID change, so the miner is using an entirely different server flow now, which in itself broke a couple of other things, but those should be sorted now. Just give the latest development build a try and if everything works, I guess this can be closed.