Stream state change for a non-existing channel #110
Comments
|
Hello o/ This should be more of like a warning level instead. This "error" comes from the websocket receiving a channel state update, for a channel that doesn't exist in memory at the time. This usually indicates problems with websocket properly managing the topics the main loop gives it. I suspect there might be a race condition at play here, since I've never implemented proper request-response to the websocket system twitch uses, simply because it appeared to work without that. The good news is that, well, in this case you receive too many updates, because these channels aren't tracked anymore. The bad news is that, IIRC, the main loop's design won't "fix" this by reloading, and you'll actually need to restart the application to get rid of those. As a TODO for myself, it'd be adding proper request-response system to the topic subs and unsubs logic of the websocket. I'll try giving it a shot again and see what I can come up with. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@matarife123 This has nothing to do with the topic of this issue. If the autostart doesn't work for whatever reason, unchecking it and then checking it again should fix it. The autostart feature isn't smart enough to figure out that you've moved the folder elsewhere after enabling it. If that won't help (and there's a 99.9999999% chance it will), then please open a separate issue instead of commenting under a completely different one. |
|
@DevilXD I was able to circumvent the error for some time, when tunneling the application through a vpn, so it might be twitch actively doing something? |
|
No, the miner is "wrong" by not checking the state of the topic subs and unsubs like it should. The current websocket implementation just submits a request to be processed, but doesn't wait of the acknowledgement from the server. What happens is, some people have an unstable connection, or are in a region where Twitch just doesn't work as reliably as it does for others, so some requests aren't making it through. This makes the miner think that everything submitted was completed successfully, while the server hasn't acknowledged part of the requests at all, leading to it sending updates about channels the miner isn't tracking anymore. The solution is to rewrite the websocket implementation to include waiting for that confirmation (and retry when no ack is received I guess), but it's as much work as needed in #652, so this was placed really far on my back burner. So like, I have a solution, it just needs a lot of time and work. Best you can do is to just wait patiently. |
errors do not interrupt mining
The text was updated successfully, but these errors were encountered: