TwitchDropsMiner
TwitchDropsMiner copied to clipboard
Fatal error crash: [{'message': 'service error', 'path': ['game']}]
The program crashes in few seconds after opening with text:
07:32:37: Fatal error encountered: 07:32:37: 07:32:37: Traceback (most recent call last): 07:32:37: File "main.py", line 158, in main 07:32:37: File "twitch.py", line 764, in run 07:32:37: File "twitch.py", line 916, in _run 07:32:37: File "twitch.py", line 1709, in get_live_streams 07:32:37: File "twitch.py", line 1566, in gql_request 07:32:37: exceptions.MinerException: GQL error: [{'message': 'service error', 'path': ['game']}]
Try to reinstall, but that doesn't work
Hello. "service error" signifies a problem with Twitch internals, not the miner. These usually go away on their own after some time passes, once Twitch fixes the issue.
Which games you have added to your priority list?
This error also occurs when I farm RUST drop.
@daeeros Auto-restart makes no sense for a project like this, as it's going to run into the very same error right away, and all you end up with, is the miner spamming the Twitch internal API with errors - a very sure way of encouraging them to take more and further steps to bot-proof their system and essentially kill this project. If auto-restart would be a good idea, I'd implement it ages ago.
Please don't do this.
Can confirm:
09:56:48: Fatal error encountered:
09:56:48:
09:56:48: Traceback (most recent call last):
09:56:48: File "C:\Users\Administrator\Desktop\TwitchDropsMiner\TwitchDropsMiner-master (1)\TwitchDropsMiner-master\main.py", line 158, in main
09:56:48: await client.run()
09:56:48: File "C:\Users\Administrator\Desktop\TwitchDropsMiner\TwitchDropsMiner-master (1)\TwitchDropsMiner-master\twitch.py", line 764, in run
09:56:48: await self._run()
09:56:48: File "C:\Users\Administrator\Desktop\TwitchDropsMiner\TwitchDropsMiner-master (1)\TwitchDropsMiner-master\twitch.py", line 916, in _run
09:56:48: new_channels.update(await self.get_live_streams(game))
09:56:48: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
09:56:48: File "C:\Users\Administrator\Desktop\TwitchDropsMiner\TwitchDropsMiner-master (1)\TwitchDropsMiner-master\twitch.py", line 1709, in get_live_streams
09:56:48: response = await self.gql_request(
09:56:48: ^^^^^^^^^^^^^^^^^^^^^^^
09:56:48: File "C:\Users\Administrator\Desktop\TwitchDropsMiner\TwitchDropsMiner-master (1)\TwitchDropsMiner-master\twitch.py", line 1566, in gql_request
09:56:48: raise MinerException(f"GQL error: {response_json['errors']}")
09:56:48: exceptions.MinerException: GQL error: [{'message': 'service error', 'path': ['game']}]
09:56:48:
09:56:48: Exiting...
09:56:48:
09:56:48: Application Terminated.
09:56:48: Close the window to exit the application.
On latest master version
Infos:
pip updated requirements updated
@DevilXD I guess topics like this will occur from time to time anyway. Because of the very same errors I was unlucky to skip a few Halo Infinite drop campaigns that were running in my nighttime and I couldn't restart miner manually. Maybe it would be a good idea to output this error for the user as "twitch having troubles right now, waiting..." or something like that, and make it auto restart in a minute or two to not spam twitch API that hard.
When a "service error" occurs, there's nothing you can do to help - restarting won't fix it. This is an internal Twitch error that cannot be "handled" by any other way, than just waiting (even a couple of hours) and then restarting the miner. Handling this in a more graceful way was tracked by #347 for some time, but then it got closed due to the issue being no longer present (until again now).
Regardless, I've noticed that unrequested application crashes could use some more notification noise to them, which https://github.com/DevilXD/TwitchDropsMiner/commit/caecef4ecd6f97b103355f7a929a094c71fbc794 should help with.
I'll try to debug this for Rust specifically in the mean time. So far I haven't been able to reproduce it, Rust starts mining just fine for me.
@DevilXD
Can you tell what this method call does? Does it log to a file by any chance? If so I maybe can provide you my response JSON :/
In the past, this error would only occur occasionally and the frequency was very low. But this time, the frequency of the error is very frequent. This error will definitely occur here within 2 hours. Could it be caused by someone abusing the mechanism? For example, divide 100 systems on a powerful server and then use it for 100 accounts at the same time?
Can you tell what this method call does? Does it log to a file by any chance? If so I maybe can provide you my response JSON :/
@someC0d3r That's a debug logger call. You'd need to run the miner with the GQL debug flag: --debug-gql
. Also use --log
to log everything to a file.
The logging system was never fleshed out enough for me to consider using it over "live" debugging via the in-built VSCode debugger, but I guess it's worth a shot.
A word of caution though: note that the resulting log may include some sensitive information about your Twitch account, that'd allow a 3rd party to authorize as you, which could result in "unpleasant" consequences (general "your account has been hacked or hijacked" / potential loss of account). I never built into it any system that'd filter those out. The log file should thus either be thoroughly examined by you, to remove any traces of sensitive information (you have to have the knowledge of what to look for), and any omission means risking the safety of your Twitch account, which means that some "more personal" way of giving me the log file would be strongly preferred. I personally have zero to no interest accessing someone else's account, but if you don't trust me with the log file either, I'd suggest simply not sending one at all.
If you have Discord, I'm available under @devilxd
. Otherwise, you can email me the log file to [email protected]
.
@wlk3773208 I've seen others setup true account farms, that'd run this miner (among other ones) on thousands of accounts. This is considered not only Twitch API abuse, but also an abuse of this project, which I do not support in the slightest. For a more descriptive journey about this, you can check out the project goals: https://github.com/DevilXD/TwitchDropsMiner#project-goals All of this contributes to Twitch putting out preventive measures, that makes it harder to run a personal, single-account miner like this one. But there isn't much I can do to combat this, unfortunately.
Regarding the issue, it's most likely an extra condition on Twitch side, which I'm yet to discover. Since I can't reproduce the error myself, there isn't much I can do for now. I'll keep trying, I guess.
@wlk3773208 I've seen others setup true account farms, that'd run this miner (among other ones) on thousands of accounts. This is considered not only Twitch API abuse, but also an abuse of this project, which I do not support in the slightest. For a more descriptive journey about this, you can check out the project goals: https://github.com/DevilXD/TwitchDropsMiner#project-goals All of this contributes to Twitch putting out preventive measures, that makes it harder to run a personal, single-account miner like this one. But there isn't much I can do to combat this, unfortunately.
Regarding the issue, it's most likely an extra condition on Twitch side, which I'm yet to discover. Since I can't reproduce the error myself, there isn't much I can do for now. I'll keep trying, I guess.
It happens when running on VM and using the manual built solution (adding a line of code) provided by another person in issue #386
Please tell me it's not verify=False
, because that's a pretty terrible idea / """solution""". A better idea would be to pip install either certifi
or truststore
to supply the missing certificates instead.
Looks like problem is gone. I have only one crash this morning, and then program works very well
I bet it was just Twitch themselves messing something up internally on their side, and this being the byproduct. I should really get to some proper handling for "service error" specifically. This isn't one where retrying after mere seconds makes any sense, the miner will need to essentially enter idle and wait until it's over. I mentioned this already under #347, but it got closed without adding said handling, so that was pretty bad on my part.