Fatal error when trying to access available streams #526
Comments
|
Hello. Yes, I can see it in my miner as well. I'll investigate the cause and report back any findings. |
|
I got the same error but from fetch_inventory |
|
I've just got a similar error (KeyError: data) from 3 different GQL endpoints, but the miner has launched just fine the 4th time. My conclusion is that it's a temporary glitch caused by Twitch doing weird stuff in the background. It seems to be okay now. |
|
I printed the response from get_stream and some of the response got an error |
|
It has crashed again for me just now. Unauthorized, huh? Well, there's two things I can deduce from this then: • GQL calls should be handling the "error" field, in addition to the "errors" field. I'm assuming that it's Twitch doing some magic in the GQL, to make it return a response when no response could be returned, but still, it's just a matter of including handling for that as well. For now, I can add the "error" field handling, but there's no real way to tell if that unauthorized error is legit or not, so the miner is going to crash anyway, albeit with a more helpful error message instead. EDIT/PS: According to the |
|
9779d7a implements a way to detect the "error" key being present in GQL responses, leading to a more helpful error message. |
Could you upload the zip file please? |
Thanks. I'm not sure if this is helpful, but in my case, the error seems intermittent, even after re-authentication: 17:29:04: Please log in to continue.
17:29:09: Enter this code on the Twitch's device activation page: ZFYEGLJX
17:29:32: Fatal error encountered:
17:29:32:
17:29:32: Traceback (most recent call last):
17:29:32: File "/home/gui/dev/TwitchDropsMiner/channel.py", line 250, in get_stream
17:29:32: response: JsonType = await self._twitch.gql_request(
17:29:32: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
17:29:32: File "/home/gui/dev/TwitchDropsMiner/twitch.py", line 1354, in gql_request
17:29:32: raise MinerException(
17:29:32: exceptions.MinerException: GQL error: Unauthorized: The "Authorization" token is invalid.
17:29:32:
17:29:32: The above exception was the direct cause of the following exception:
17:29:32:
17:29:32: Traceback (most recent call last):
17:29:32: File "/home/gui/dev/TwitchDropsMiner/main.py", line 153, in main
17:29:32: await client.run()
17:29:32: File "/home/gui/dev/TwitchDropsMiner/twitch.py", line 570, in run
17:29:32: await self._run()
17:29:32: File "/home/gui/dev/TwitchDropsMiner/twitch.py", line 719, in _run
17:29:32: await asyncio.gather(
17:29:32: File "/home/gui/dev/TwitchDropsMiner/channel.py", line 287, in update_stream
17:29:32: self._stream = await self.get_stream()
17:29:32: ^^^^^^^^^^^^^^^^^^^^^^^
17:29:32: File "/home/gui/dev/TwitchDropsMiner/channel.py", line 254, in get_stream
17:29:32: raise MinerException(f"Channel: {self._login}") from exc
17:29:32: exceptions.MinerException: Channel: simuverserden
17:29:32:
17:29:32: Exiting...
17:29:33:
17:29:33: Application Terminated.
17:29:33: Close the window to exit the application.P.S.: The "upload job" of commit 9779d7a randomly failed, so you might want to re-trigger it. |
@matarife123 I've re-triggered the workflow, so you can just grab the latest dev build. Still, this isn't "a fix" any more than a mere "more helpful error message" being printed out, instead of a confusing error it was before. It'll still crash, in the very same place it'd crash on the previous dev build. Again, I don't know what I'm supposed to fix here, as the authentication token still works, Twitch just fails to process it sometimes. This has started happening only 2 hours ago, so I'd imagine it'll pass on it's own, once Twitch fixes the issue on their end. |
|
`23:05:00: Fatal error encountered: ` It's still broken, even with the new files, guess we'll see if Twitch does anything or not. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@Artanisx That's an entirely different error, that has nothing to do with this issue. Before you report anything here, make sure it's actually the same issue you're experiencing. New issues have to be filed separately. Btw, that has been fixed over 2 weeks ago by 0f3a784, so you're most likely using an outdated miner version. |
Thanks. Sorry for the mistake, also I wasn't aware of a new version as Github says the last one was released on December 2022 and the last dev one is marked May 19, 2023. I only now realized the "Last build date: 2024-08-02 20:41:45+00:00" message inside. Going to update now! EDIT: I can confirm my off-topic issue is indeed fixed, thanks :) |
|
OK, this time I'm indeed getting the same error of this thread #526 (comment): :) |
|
It would be nice if there was a way to automatically restart the application when a fatal error like this occurs |
|
Since this started happening, I haven't even been able to get past startup at all. Not on my account, not on my friend's. (And a fresh login doesn't change anything.) |
|
I'm really not sure what to do here, this issue has passed for me yesterday, and didn't crash since. I'm not able to reproduce it anymore. Fresh login won't change anything, as the authorization key does not expire, and thus the application will receive the very same one it had before re-logging. The only way to change the authorization token, is to change your Twitch account password. If @avdichiara Auto-restart has already been suggested before, and the answer is still no. If you'd like to learn why, you can search the already closed issues for an explanation. |
|
I think the problem was on twitch's side of things, as I am able to mine again, not sure how long it has been since it works again but it works now, grateful enough for that. I think you can close this issue since it wasn't related to something you could fix yourself, afaik. |
|
i just deleted all the cookies, lock and cache files and logged in again and now it works, i'll report back if it breaks |
|
I would say leave this open until long enough has passed with no reports. I'm still getting unauthorized infrequently. |
Maybe that functionality should be hidden behind a launch parameter, to indeed only be used when the user specifically needs a band-aid? P.S.: It doesn't immediately crash when I tick Priority Only. It still crashes quickly on Priority, but I do get to idle for a few minutes. |
Hmmmmm. I actually kinda like that idea. Like, I'd prefer to know that something bad is happening, but at the same time, have the ability to just tell the miner to "deal with it". There would have to be some additional code to deal with the missing information, but for some portions of the miner, it'd be doable. I'll think about it overnight, and see what I can come up with tomorrow. |
|
I had this issue today as well still going on with the Authorization token problem. Clearing cookies, lock and cache fixed it for a bit but then it re-triggered again as soon as I added a new game to my list. Closing and re-opening seemed to fix it after a few tries. I'm using v16.dev.9779d7a |
|
I also had this problem v16.dev.9779d7a |
22:14:38: 正在观看: 國濤
22:23:46: 观看直播获得积分: 50, 总积分: 490
22:23:46: 观看直播获得积分: 50, 总积分: 1070
22:23:46: 观看直播获得积分: 50, 总积分: 110
22:23:46: 观看直播获得积分: 50, 总积分: 110
22:23:46: 观看直播获得积分: 50, 总积分: 110
22:36:40: ERROR: Exception in process_notifications task
22:36:40: Traceback (most recent call last):
22:36:40: File "O:\zsn\TDM\TwitchDropsMiner\utils.py", line 142, in wrapper
22:36:40: await afunc(*args, **kwargs)
22:36:40: File "O:\zsn\TDM\TwitchDropsMiner\twitch.py", line 1194, in process_notifications
22:36:40: await self.gql_request(
22:36:40: File "O:\zsn\TDM\TwitchDropsMiner\twitch.py", line 1362, in gql_request
22:36:40: raise GQLException(
22:36:40: exceptions.GQLException: Unauthorized: The "Authorization" token is invalid.
22:36:52: Fatal error encountered:
22:36:52:
22:36:52: Traceback (most recent call last):
22:36:52: File "O:\zsn\TDM\TwitchDropsMiner\twitch.py", line 1545, in get_live_streams
22:36:52: response = await self.gql_request(
22:36:52: File "O:\zsn\TDM\TwitchDropsMiner\twitch.py", line 1362, in gql_request
22:36:52: raise GQLException(
22:36:52: exceptions.GQLException: Unauthorized: The "Authorization" token is invalid.
22:36:52:
22:36:52: The above exception was the direct cause of the following exception:
22:36:52:
22:36:52: Traceback (most recent call last):
22:36:52: File "O:\zsn\TDM\TwitchDropsMiner\main.py", line 153, in main
22:36:52: await client.run()
22:36:52: File "O:\zsn\TDM\TwitchDropsMiner\twitch.py", line 572, in run
22:36:52: await self._run()
22:36:52: File "O:\zsn\TDM\TwitchDropsMiner\twitch.py", line 730, in _run
22:36:52: new_channels.update(await self.get_live_streams(game))
22:36:52: File "O:\zsn\TDM\TwitchDropsMiner\twitch.py", line 1556, in get_live_streams
22:36:52: raise MinerException(f"Game: {game.slug}") from exc
22:36:52: exceptions.MinerException: Game: naraka-bladepoint
22:36:52:
22:36:52: 正在退出...
22:36:53:
22:36:53: 应用程序已终止，请关闭窗口以退出应用程序。still error |
turn on my PC this morning and now got the error again |
|
I've decided to, in the end, just add the extra handling without any additional launch arguments, b20f98d implements the changes. I'd like to note that this does not resolve the problem, merely silences the two main sources where this error can happen (mass stream refresh on reload, and GQL drop progress query after every watch request is sent), which leaves other GQL requests untouched. Hopefully other requests won't ever crash, or will be doing so infrequently enough to make this issue bearable. |
|
Hmm, well, while it does help, it doesn't solve everything: Fatal error encountered:
20:08:18:
20:08:18: Traceback (most recent call last):
20:08:18: File "main.py", line 153, in main
20:08:18: File "twitch.py", line 572, in run
20:08:18: File "twitch.py", line 622, in _run
20:08:18: File "twitch.py", line 1442, in fetch_inventory
20:08:18: File "asyncio\tasks.py", line 619, in _wait_for_one
20:08:18: File "twitch.py", line 1397, in fetch_campaigns
20:08:18: File "twitch.py", line 1362, in gql_request
20:08:18: exceptions.GQLException: Unauthorized: The "Authorization" token is invalid.Fetching campaigns isn't something that can be skipped on. More research is needed to deal with this issue, which I'll be doing over the next couple of days. |
|
Hello! I did some research, and investigate how work Twitch-Channel-Points-Miner-v2. That miner doesn't have any issues, because it use Update: |
|
Hmm, interesting. It may be more worthwhile to switch back to the android app again. Last time this miner was using it, they've made the login flow use their integrity system. Hopefully it's not the case anymore. |
|
I have sent PR, accept it if you want this client. |
|
An alternative solution would be to just retry the failed requests. I've been testing a proof-of-concept retry loop when this error happens, and in all cases so far, if the first request failed, the second one succeeded. |
Errors happen's very often as I know, but you can try what solution fit better |
|
After further research on the subject, it seems like Twitch has implemented a rate limit on the amount of GQL requests one can send at one time. The miner tends to be quite efficient with those, except in a particular case - when setting channels online right after a reload, which is exactly what is causing the problems. My current test case has tried to set 343 channels online at once, resulting in 343 separate GQL requests being send at once, and 50 of those bouncing back as "Unauthorized". It could be the case where Twitch has implemented a local rate-limit on GQL access in their web client, and anyone other accessing GQL faster than intended will be "shooed away" with "Unauthorized" errors. This is all just speculation, but if true, the fix is quite simple - just implement a local rate limit in the miner. This should hopefully resolve this issue, and we can go back to the state from before the dirty fixes that were applied here. Besides a rate limiter, I can also optimize the operation of setting all channels online on reload, since GQL can actually take in a batch of up to 20 operations at once. That'd reduce the GQL "hammering" from 343 separate requests, down to only 18. Should be much more manageable. Campaign details are already fetched in batches like that, and it works perfectly there. I'll be working on this over the next upcoming days. |
Hah! I suspected this might be the issue but hadn't looked into it further to the point where I wanted to bring it up here yet. |
|
Looks like a new one has popped up: websocket is giving me Are they rejecting tokens now that are getting generated at |
he knows about this error its been reported and he's working on a patch for it now |
This is different behavior than to what was previously reported, which is why I posted about it. |
You may want to try: I have encountered zero error after using this one-line change. |
|
18:46:21: Fatal error encountered: have you solved it?this is the log |
Hey! You can try version here: https://github.com/Windows200000/TwitchDropsMiner-updated/releases/tag/v15.8.1 |
|
I'm not quite sure if my problem is linked to this issue, I was getting the following error:
The version you linked seems to have fixed my issue though! |
this version also worked for me until DevilXD fixes his, its working right now! guys download this! |
|
Can confirm, the tagged build does work. EDIT: It was working for a while, and then: EDIT 2: Stable and fixed as of f705cc1 |
Hello! Pull requests has been submitted: |
building the application from source is quite straightforward! |
It may be even simpler to run as a Python script. |
|
I guess this can be closed, as the issue isn't happening anymore, and a new bulk-channel-refresh logic has just been implemented, that should help avoid running into similar issues again. |
and others
The text was updated successfully, but these errors were encountered: