Twitch is down, retrying #172
Comments
|
|
|
I finishes mining |
|
The issue seems to be it gets one bad url and then just retries that one again and again instead of trying to get another one. I'll look deeper tmrw. |
|
Of 60 requests, 57 went through and 3 failed with all 4 different broadcast qualities. Maybe I made a mistake yesterday when I thought I figured out that it's not always all broken or all working. update: 3/207 successful ones did end up working with the 2nd link. I must've gotten really lucky noticing that yesterday :D |
|
So immediately retrying the send_watch function makes it work. This means we can probably just do that after the first fail. A pretty serious issue is that TDM doesn't stop counting down once it fails. This is a really difficult issue to solve, because a lot of the code still relies on minute intervals. I hacked the new 20s on top by just not advancing a minute if there is still seconds remaining. That means nothing checks if 2/3 of the requests even succeeded, and it's just assumed they did. |
|
here you can check what I currently have: in-dev...Windows200000:TwitchDropsMiner-updated:issue-172-ttv-down-retrying |
|
For me, it completely freezes, once it unfreezes I do get the error, but any action on the program freezes it again, before the error everything was completely fine. |
|
Compile from the fork in my above comment. This seems to be pretty rare. Or take this exe: |
|
yes, im having this issue and progress is being reset too, very annoying |
|
Sadly your exe doesn't work for me too. 3/50 Websockets connected, at first it gets channel list, ends up breaking on rewards that might be a subscription reward, goes back to "gathering channels" and can't connect to Twitch again. (which freezes the app constantly) |
The subscription reward is ignored. You have to rename the Json I sent 3 messages above to an exe. GitHub doesn't allow executables in comments. Try clearing your cookies file and logging in again too. |
sadly its the same... |
This seems to be working for me, it did freeze like others mentioned for a minute at most while it was gathering channels but then it eventually unfroze, threw a connection error for a slight bit and then it started working just fine. I do get random: things coming up in the output section a ton but it at least seems to be progressing on twitch drops as well.
|
|
yup, the error not error is what I used to try and figure out what;s going on, you can ignore that. The freeze doesn't affect me, I guess it's a separate issue? |
Yea I kind of figured that it could be ignored for the most part.
Possibly, I only had it freeze the one time during the gathering channels bit and it was a very short amount of time that the window was frozen, other than that everything seems to be running fine for me though so far for the past 3 hours that I've been running the version posted above. |
|
Ooop I ran into it now just throwing twitch is down retrying error after I had a intermitten downtime of my internet, I ended up shutting down TDM for the time being that my internet was down and once my internet was back up I re-opened TDM again and it has just been stuck on I did try the original version of TDM from DevilXD and it seems to be working perfectly on connecting and all that, so it def seems to be something to do with this specific fork.. |
|
Using the updated .exe provided above, im still receiving the error. |
|
Delete the cookies.jar. |
That doesn't really make any difference on my end. |
This is temporary fix when it is happening. |
|
I merged the branch into in-dev. I will be running it on my end as well and if it works I'll make a release. I'm still really busy, unfortunately. Download here. |
|
So far everything has been running perfectly on my end ^^ |
|
Updated to the dev build...problem is back. Its 100% twitch's fault but also TDM seems to freeze when gathering campaigns and channels. |
|
Have no issue with TDM freezing still, but did run into the |
It had been working fine for me as well for the past couple of days since switching over to using the in-dev code, so far this has been the second time only that it has happened, but the thing that was weird about this one was that it was still mining (albiet it kept returning the same progress on an item drop but it was still actually progressing on other items when I viewed my twitch inventory) while throwing the connection error like how it shows in the following snippet from my logs: Was stuck doing something along those lines on repeat even though it was still actually progressing on other items in the same campaign until I did the whole shutdown, deleted the cookies file and restarted everything and then everything started working fine again and been since.
good to know, I'll try that next time. |
|
I've encountered the issue again where it gets stuck on the Before restarting with the debug flags, I downloaded the logs from my container and noticed that the following error was being repeatedly logged every so often about the same time the connection issue started: (Note: The I hadn't seen the resource warning coming up any before hitting the connection problem, though I suspect it was likely happening when I previously said something about the connection issue happening as well, but I just didn't catch it then. I've got the debug information running now, so if the issue happens again, I'll upload the log from my container. @Windows200000, if it does happen, is there any sensitive information I should remove from the log beforehand? Lastly, are these two lines here responsible for controlling the |
I didn't add any, but DevilXD might have. I know none of these are sensitive: I just asked him and will reply again once I get an answer. |
|
I never had this issue previously but I downloaded 15.9.0 because I like to make sure I'm up to date. After that I constantly got the retrying error. I downloaded 15.8.2 again but the error persisted with that version too even though it didn't happen with that version before. Both versions of the app felt very sluggish and froze a lot when trying to access inventory/settings. I downloaded DevilXD's latest version and dropped it into the same folder and that is working fine. Very strange issue. I've made a log I can send over if you need 👍 Edit:
This is what it looks like when I run 15.9.0 now. CPU usage is fairly high when it's running, using about 10% of my 16 core CPU. |
|
@This-Person can you try running the |
|
It is strange thing though, as even when I run the application side of things instead of going and running through docker, I haven't experienced the sluggish/freeze issue that others have mentioned any other than the very first time I ran the in-dev version that was mentioned way above before 15.9.0 was released, any other time I've ran the application I've not experienced it since, even though I have still experienced the connection error several times now. Still waiting for the error to happen again on my end but so far haven't seen it again since I started back up with the debug flags 6 hours ago >.< |
I won't lie I have no idea what I'm looking at but I can't see any obvious errors. Lots of messages like this in a row for different channel names:
Then after those messages stop a lot of messages like this in a row for different channel names:
I've removed the requestID and sha256Hash just in case they're identifiable. As I say without changing anything at all, deleting the 15.9.0 exe and dropping DevilXD's latest exe into the same folder instead makes everything work again. No idea what's causing it. Edit: Unsure if it's pertinent but as soon as I run 15.9.0 I get this message everytime: I don't have Star Wars Outlaws in my list of games to mine so not sure what it's mentioned. Although checking the logs, despite not having the game in my list it mentions some streamers streaming the game? An example is below:
|
The hash is hard-coded for the persistent query, and the requestID is likely invalid after a very short time. However, DevilXD said, that at some point the authorization token might get logged, which would be a pretty huge issue, that's pretty much the same thing as malicious extensions, that steal your cookies and can gain access to your sessions (logins). I'm gonna let mine run for a bit and search for any weird stuff. |
|
Actually, yeah, there's the auth_token in there, which isn't great. Try using only |
|
adding my logfile if someone is interested |
|
@Sparh4wk remove it, it contains your auth token. Sorry for not clarifying that, I wasn't aware myself. I'll add you to a GH support ticket I have about this. |
|
They're all deleted now by GitHub support, including yours. |
Thanks. I was afk till now |
|
I can confirm that after 4 or 5 minutes the CPU usage goes down, the 'cannot connect to Twitch, retrying' error disappears, the app stops freezing/being sluggish and the app starts mining normally. I've let it run for 10 mins to get a wee -vvv log which I'll attach here, hopefully it helps! If you need a more in depth log let me know and I can e-mail it over or something 👍 Edit: At 22:28 I pushed reload in the Settings to enable autostart and the CPU usage spiked again and the error returned for another few minutes if something looks weird in the log. |
|
Apologies for the double post but wanted to give a small update. I switched my laptop on this morning and the 15.9.0 app just auto launched normally. No high CPU usage or error messages, it just checked the inventory then got straight into mining. Very strange! |
Windows200000
added
Solved
|
Unsure of why this was closed fully as it is still an on-going issue. I do seem to notice a huge spike in CPU/Ram that others are talking about while it's running into the twitch is down retrying error, upon reloading the program (or in my case the container) the usage does go back to normal until it goes and hits the problem again. I did switch back over to the |
I closed it, because I thought it was a separate issue, since it has been completely resolved for me.
Thanks a ton for the log! It seems like it is now retrying every 2 seconds, which is not good. But it is quite likely caused by the container. Python is really not the right programming language for this, so the exe is janky solution that generates the .py fiels in a temp directory before running them. If you look ath the forks of the upstream, there should be another one, that is meant to be run in docker. I strongly suggest you use that. From README.md:
|
@Windows200000 If you're referring to @Valentin-Metz fork, I forked his version recently (couple days back (was the 18th or 19th of last month)) to integrate updates from this repo (which he pulls code from this repo and is pretty much the base of his code) more quickly into my container and to make some adjustments and adding my own modifications to the health checker bits. I'm not using the .exe version within the container; instead, it runs the command I'm mentioning the retry connection error issue here because (other than this issue being a direct corrolation to what I'm experiencing and I'm sure others are still as well), during my testing of the .exe version from this repository (outside of Docker), I encountered the same connection retry problem during all the times I've commented in this issue. The last time I ran the .exe version on my main machine was last night, shortly after uploading the log from my container because you had closed this issue and I wanted to test to see if there was something different I wasn't seeing. About 2-3 hours after starting it, I ran into a connection retry error. Interestingly, I didn't seem to experience connection retry errors any while testing the default version of TDM (DevilXD's version) however as I had to test it last night due to dealing with a different issue related to a specific drop, which I'll mention below. Unfortunately, I don't recall the exact error that forced me to switch to Devil's version of TDM, as I was too tired and forgot to write it down. However, last night, I encountered a specific issue with the |
|
@Windows200000 do you plan on merging your fork with devils upstream? |
I am looking to merge it. The issue is that DevilXD doesn't like some parts, like prioritize by ending soonest which I didn't write, and the dark mode implementation, which he would rather be implemented more cleanly, even if you then potentially need to restart to apply changes. I'll work on that once I have some time, hopefully relatively soon. |
|
Since I've been mentioned here, and read that y'all have an issue with the "Gathering channels..." phase of the reload process, I figured I'd shed some light on this. The reason it freezes and gets into the "Can't connect to Twitch" loop, is because this fork still tries to set all ACL channels online at once on reload: TwitchDropsMiner-updated/twitch.py Lines 913 to 917 in 42fe404 ..., while I disabled that almost a month ago: DevilXD@f705cc1 The cause of this is Twitch implementing a rate-limit on GQL requests, that'll return "Unauthorized" if there's lots of GQL requests being sent at once, which is exactly what happens when the channel status is loaded in the code above, and there's a lot of channels to load. Ref issue on my repo: DevilXD#526 Disabling this piece of code means that the miner may throw the "No available channels to watch. Waiting for an ONLINE channel..." message into the output window once the reload finishes, but it can be safely ignored. The channels are still gathered, the websocket still subscribes to channel status updates, and Twitch will still send channel status updates to the miner, including the "viewcount" event, that is sent repeatedly every so often (every like 30s), which main purpose is to update the viewer count for a stream - btw that's how you can see the viewer count updated in real time under a stream on the website. Once the event arrives, the miner processes it into updating the channel's entry on the Channels list. But if the channel's status happens to be OFFLINE, the miner realizes it has an outdated channel state, and sets it online: TwitchDropsMiner-updated/twitch.py Lines 1233 to 1245 in 42fe404 Setting a channel online has a 2 minutes of a delay added to it, because the usual way a channel is set ONLINE, is by receiving the "stream-up" event. and these events are usually sent way before the stream actually starts. These 2 minutes are really generous, as the actual delay roughly matches the usual delay you get from watching a stream, if you've ever watched someone stream and respond to chat messages, it's more like 30 seconds max instead of the 2 minutes, but I've never really bothered min-max optimizing this - some delay was needed, 2 minutes worked, I just left it at that. So shortly after a reload, you'll see the miner switch to the IDLE state, but shortly afterwards, some channels on the channel list will change their status from Ref issues for more info on the above: DevilXD#537, DevilXD#541, DevilXD#551. That's how the current master branch of mine works, until I can rewrite the commented out code, as it can be optimized to not send up to ~200 GQL requests at once, which is what happens if you have several games added to the Priority list, and they all together happen to reach the channels limit of the miner - which is also why this issue happens only to some people, and reproducing it is "unreliable". |
|
@Windows200000 lol did you have a stroke while writing that last message xD @DevilXD hmm, I'll push that commit into my repo and keep an eye on things to see if it makes things better or not. |
I just have a new phone without a broken screen and am getting used to typing with fingers again. I'll correct it 😅 |
|
Well to make an update on the situation since merging in the DevilXD@f705cc1 commit to my repo and testing things out, I have yet to see any |
|
Another update on things, everything had been running perfectly fine since my last message (albiet a lot of it was without it actually farming anything since I had no campaigns to farm during a good portion of that time) up until about an ~2-3 hours ago when it started farming a campaign that had finally become active and then I eventually started hitting a Unsure of what exactly caused it but anyways here is my log (it's somewhat of a fresh log as I did restart my server last night).. |
|
@DevilXD unsure of what is going on but I've recently noticed that the change you are talking about in #172 (comment) with commit DevilXD@f705cc1 makes it so that sometimes a channel never seems to come online in the miner even though it is clearly online on the site. I've tested this with the default version of the bot (as in from your own repo) as well and not a forked version and it has the same problem so I'm unsure if you want me to make an issue in your repo as well. Example: Once I reverted the code change from that commit it ofc never had an issue with seeing any of the channels online and it instantly started mining... I'm unsure if the problem is affecting any other games/channels or not (I'm sure it probably is though) Not sure if @Valentin-Metz has seen the same or not as well, since he has the commit pushed into his repo as well, so I'm sure he probably has been. |
Are you experiencing this error? Please tell me!
I have it working for myself, where it tries more URLs and if it fails, doesn't get stuck in a retry loop.
If other people have it, I will prioritize cleaning it up and make a commit.
Description
After a while, TDM gets stuck with the message
Twitch is down, retrying in x seconds...To Reproduce
Expected behavior
it mines
Observed behavior
It retries, only very rarely actually mining
Screenshots
No response
Logs
No response
OS
Windows 11
Build
.exe
Version/Commit
v15.8.2
Additional context
Might be correlated with
Summer Vibes Token Store: Drop 6fromWorld of Tanks.The text was updated successfully, but these errors were encountered: