Channel points not being tracked + AppImage Errors & CPU Usage

[iXerxes]

I'm unsure where to post this, so I'll just post it in both places. (DevilXD #420)

I'm also aware that I'm not exactly using the miner as it was intended to be used, however, I thought I'd at least make note of this issue, just in case, as I was never getting these errors with previous versions.

I'm running the miner on Linux Ubuntu using @Windows200000's fork, from the AppImage file, and I'm getting some errors I wasn't having before:

1. My console is being spammed with this error:

/tmp/.mount_miner.h1wTkZ/usr/lib/python3.10/asyncio/sslproto.py:320: ResourceWarning: unclosed transport <asyncio.sslproto._SSLProtocolTransport object at 0x7f230e8fe2c0>

2. The miner will disconnect from Twitch far more frequently than before, and give me the "Trying to reconnect" message. Not only this, but when the reconnect message appears, it seems to spam the console in a no-delay loop, meaning my CPU hits 100% load for an extended period of time.

[iXerxes]

Seems to be something related to:

• There are no channels available
• A channel that the miner was watching has stopped streaming the required game

My miner only has one eligible drop. It was watching a stream, but the streamer stopped playing the required game and there were no others to watch. The miner seemed to freeze indefinitely, until I reloaded (using the button in the settings tab), which then spammed "unable to connect", pinning my CPU at 100% for a short period of time before it finally fixed its self.

I think this only fixed its self because someone else started streaming, and had there be no available streamers, I'm unsure it would have worked.

[Windows200000]

@iXerxes This is the right place for now.

I'm also aware that I'm not exactly using the miner as it was intended to be used

What do you mean by that? Seems like you're just trying to mine drops, like everyone else.

Other than this being a Linux build oddity, I don't know what could have changed. The only parts of the code I touched are the watching itself, which is independent from finding what to watch, and the countdown to drop-end timer. I'll look through the diff to DevilXD's original repo and see if I can find what it could be.

[iXerxes]

What do you mean by that

I'm running multiple instances of the miner on an Ubuntu Server machine, using Xpra to provide a persistent remote GUI.

I'm not certain what causes the issue to be honest. I've been watching it all night, and it seems very unstable. I've had to terminate some instances multiple times over several hours.

Sometimes it will randomly disconnect from Twitch and spam the output with reconnection messages, causing it to freeze up, and become unresponsive. Very rarely will it fix its self. Other times, it seems to be related to switching channels, or switching drops. Something along these lines will cause it to disconnect and pin the CPU at 100% with indefinite output spam.

Only one instance I have running is working perfectly. Also, something else I should probably mention is that this one instance is the only one that outputs channel point information. All of the others seem to lack any knowledge of this data, only outputting online/offline and channel switching info.

Like I said, I'm not using this miner as it was intended, however I have been using the miner like this or several months now with no issues.

[Windows200000]

Only one instance I have running is working perfectly. Also, something else I should probably mention is that this one instance is the only one that outputs channel point information. All of the others seem to lack any knowledge of this data, only outputting online/offline and channel switching info.

That's interesting, as the windows build also seems to not show channel points as reported in #34. As I said there, I think this might have to do with the API change, that also changed how drops were mined.

The only thing actually changed in the code is how the drops are mined, which is entirely independent, and there's an additional current_seconds var, that makes a watch only progress a minutes watched, if current seconds are at zero. This is a patchy workaround, but a lot of the code seems to depend on the watch interval specifically being a minute, which this achieves.

[Windows200000]

Added context from #34

@Kuddus73
The "Output" cell only shows details for a few seconds at the beginning of when you open the app and then it stops showing anything.

The output doesn't show all the points earned like it used to do before.
However, the mining does work fine as the drop was automatically claimed on Twitch after the required time but again, like the points, the claiming wasn't shown in the output.

[Windows200000]

from @Walter-o, #89:

Hey!

Today i punched this program into a docker container and ran a few instances but noticed something alarming.

My server's harddrive started to sound like it was going to explode every 10~ seconds.

I could not debug it really thoroughly but here are the facts i have:

• I was hitting tons of rate limiting from twitch
• I limited Websockets to 2 per account but left topics at default 50
• 3 Instances were being ran without proxies
• It only happened after about 30 minutes of running (likely related to rate limiting kicking in gradually)
• It got fixed by switching the cache+lockfile+log to an in-memory (RAM) volume

If i had to guess it's some short circuiting that happens when getting connection errors and then trying to read/write cache.

Anyways, i worked around it but i figured i'd still let you guys know about it, the issue can be closed if needed.

[Windows200000]

It looks like the CPU/write issue is related to multi-account and/or docker usage. I will leave it bundled in this issue, as it seems related, but the main problem remains channel points not being tracked after the API change.