client
client copied to clipboard
Slow startup + traffic blocked
Last few lobby releases this happens: FAF opens then freezes for 10-40 seconds. Can't click anything. The longer it takes the higher chance I'll get traffic blocked. https://gist.github.com/speed2CZ/edd0c39eb34428a68c2041a96f942824
The traffic blocked message just indicates some kind of timeout, which may or may not be related to traffic being blocked. Perhaps a more informative/accurate error message would help?
there is some Upnp related error in that log, i'm not quite sure though if that is to blame. this seems to be said error http://pyxr.sourceforge.net/PyXR/c/python24/lib/site-packages/win32/lib/winerror.py.html#1127 the error is being described a bit here https://msdn.microsoft.com/en-us/library/windows/desktop/dd542645%28v=vs.85%29.aspx maybe the actual error is here https://github.com/FAForever/client/blob/develop/src/fa/upnp.py#L35
New log https://gist.github.com/speed2CZ/0ddbfe2ba2050ff31a7ec7b577cbc0ba
I've been getting the error constantly last week, can't even play anymore :(
this error: https://github.com/FAForever/client/blob/04d8eb709bd6ffa4f7957caf097a77f09aac8584/src/connectivity/helper.py#L160
newest log from version 0..1.58-27-gd359279+504 https://gist.github.com/speed2CZ/4e03eb9e52526d80fed5bb2165aa5b39
updated log on icecreamer's request https://gist.github.com/speed2CZ/2eb6ec9e679119e5ff580a41b75a4619
Seems like either the client startup needs to be done more sensibly (so stuff doesn't hang while other things are loading) or the server needs a longer timeout on the connection test.
Timeout is already 20 seconds (I can't recall the exact value).
Having the client be this slow to load isn't really acceptable...
it wasnt so slow few version ago
I don't get it. Client boots in <2s for me :/
I'd argue that being unable to use FAF is less acceptable than having to wait 30 secs before you can use it.
Obviously the client needs some performance work on startup, but increasing timeout delay is an easy win for people getting this error (and it isn't an infrequent thing).
I'm also experiencing this issue, and with two computers using different internet connections.. Any solution would be very appreciated. I assume that there are a lot more people experiencing this who haven't reported it, and it's not exactly going to us attract new players if they're getting errors like this...
Found a solution!! Open Forged Alliance through steam, and when prompted by window's firewall, click 'allow access'. Quit and load faf and it worked after that!
@speed2CZ Please tell me you have opened a hole in your firewalls...
I do, it started when I was restarting FAF and I highly doubt that windows would decide to quickly block it in that moment
I experience the same problem. Client freezes for a while, then the traffic blocked message. @b2ag experienced the same problem. But we're using the client natively on Linux. Two days ago I even saw the error on a friends PC using Windows. It was gone after some reconnecting.
My hurry-now-I-want-to-play-patch is:
diff --git a/src/replays/_replayswidget.py b/src/replays/_replayswidget.py
index 42b1aa5..764ca5f 100644
--- a/src/replays/_replayswidget.py
+++ b/src/replays/_replayswidget.py
@@ -400,6 +400,7 @@ class ReplaysWidget(BaseClass, FormClass):
# This game is the game the player is currently in
mygame = False
+ return
# Create player entries for all the live players in a match
for team in info['teams']:
if team == "-1": #skip observers, they don't seem to stream livereplays
I was debugging the client during the freeze and it was doing work in the ReplayWidget. With this return
statement the client loads fast and stable. It probably breaks a lot of Replay stuff.
So the client receive a message from the server on startup with info about games here: https://github.com/FAForever/client/blob/develop/src/client/_clientwindow.py#L1322
When I looked to see what was in these I found that more than 600 game info objects were being received in that one message, of which more than 400 contained both: u'num_players': 0, u'state': u'closed',
(429 of these to be precise)
Not sure what is meant here by a 'closed' state, but with num_players being 0 these probably are being sent in error, and result in everything that connects to the gameInfo updates from the client (namely replay and game widgets) getting hammered.
Holy mother, that would sure explain something. @HardlySoftly can you check muellni's thing too? If he is also right, and something in ReplaysWidget is jamming too, we have a potential double-barrelled fix.
TLDR: this is the same as muellni's issue.
When the game receives this message, it takes each game item and passes them individually to _replayswidget, _gameswidget, and _coopwidget (because the code in these three was copied and pasted).
_replayswidget and _gameswidget then both generate a game object for each item, place into a dictionary of such items, then upon realising it is state == closed remove them again.
Doing this 100s of times in both gameswidget and replayswidget is what slows things down (at least, it sped up a lot for me when I got it to stop doing that)
Sounds to me like you're well on your way to a nice fix :)
I'm not so familiar with the server code, and that's where the fix needs to be really.
What did you do to 'fix' it locally?
Got it to ignore game info messages with those characteristics. Without knowing more about what game info is passed between server and client I can't tell if that breaks something more subtle though. (I only ran the client for 10 secs to see how quick it started up)
Don't suppose you could make a PR so we can get an alpha emergency client build up doing it client side quick and dirty for those having the most trouble?
PR to prevent the server from wasting effort sending such messages: https://github.com/FAForever/server/pull/145
I propose that, instead of having a client-side filter, we stop the server from sending pointless messages, and restructure the client so it doesn't have this horrid performance property anyway. Even if we filter such messages (or just stop sending them) we'll encounter the same problem in the presence of many open games, so we do need to make the client able to handle many games being sent on startup without catching fire.
And yes, holy crap HardlySoftly, you weren't kidding about how much copypasta there is here.
sharpens chainsaw
Deployed just now.
Tracking client performance issue here: https://github.com/FAForever/client/issues/351
Yep traffic blocked even after "fixing" stuff. I am new, really wanted to try this out, I spent money thinking this would work... I kind of want to leave an angry comment on Gyle's channel right now. Seriously though...
@dhoffsteder try https://github.com/FAForever/downlords-faf-client
This is still a thing and it's probably the biggest problem that needs to be fixed in the client.
Maybe "fixed" with server update tomorrow