ID:2149669
 
BYOND Version:510
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 53.0.2785.116
Applies to:Webclient
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
We have a login server that's 2MB, which loads normally, but the main game (50MB) tends to hang for several of our testers once the player selects a server. It can take 5-10 minutes to load or won't load at all, requiring a reset.

The progress meter also isn't displaying the resources: http://puu.sh/rgxrD/1a8b052f36.png

Any information on how we could help debug this would be good, since I know there isn't much to go off of here.

Does the problem occur:
Every time? Or how often? Maybe 1 in 5 of the players.
I think it's because every single file is being downloaded by itself. The browser limits the number of files that can be downloaded... Which looks like four files at once?
The progress meter not updating means it's having some trouble before it ever gets to the resources. What does their JavaScript console say? That's the important clue in these cases.
Yeah, the progress meter doesn't appear, though it does for the initial download (the login server). The console log: http://puu.sh/rgEXD/98e13bae1c

The person that took over 5 minutes to download the files has a slow connection (2mbps), but it still shouldn't take as long as it did... Might be because of the delays between downloading, where it's requesting headers for each group of files. Not sure if this can be improved or not.
The ERR_BLOCKED_BY_CLIENT at the beginning is a big, big red flag, and probably indicates some kind of blocker at their end that's configured improperly.

http://stackoverflow.com/questions/23341765/ getting-neterr-blocked-by-client-error-on-some-ajax-calls

One of the answers there suggests an extension installed by Avira causes some trouble.

Quit code 1 is also in play here, meaning either they had some kind of late authentication error or the server outright dropped them for another reason. The first thing is to solve the block error, because that's the big one.
Well, see, that console log is actually mine and I connected just fine (took under 15 seconds for the resources to load). I'll try to get their log.

EDIT: http://puu.sh/rhewA/17233f7a86.log Here's his log. It took him just under 6 minutes to download the 50MB files at 2MBPS, and he downloaded the resources less than 12 hours ago, so there may also be a caching issue at play here where it's not holding onto them for long (everyone who plays also experiences this).
He's still getting the quit code 1 issue there. I wonder if a domain thing is in play, although that's generally caused quit code 9 when that's been a problem.
Anything we can do here? We really want the progress bar to display since it's confusing for users otherwise. It's a universal problem rather than user specific.
I don't know if there's any way to catch ERR_BLOCKED_BY_CLIENT in my code. The culprit is something that's running on the client's machine that's interfering with the webclient, usually some kind of security software. Unfortunately since it's not showing what it blocked, that's going to be hard to suss out. But the users having that issue will have to be the ones to do it, because I'm not seeing it on my end or in any of my tests.

I know when running AdBlockPlus in Firefox, you're given info on what has been blocked. I don't know if the same is true in Chrome, but if it is I'd recommend those users look at what specifically has been blocked. Maybe with enough data on that I can come up with something.

As far as the quit code 1, I really have no idea what's causing that. That could be your code forcing a disconnect, or it could be something else regarding client data integrity. If this happened to everyone who connected I could probably get it to happen when testing myself; if it's only happening to some then I really don't know.
Yeah, the red progress bar isn't appearing the second time for all users. I'll pager you the server link so you can see it in action, and ask Doohl to post the relevant code here.
I think I'm going to need a new copy of the exact source you're running on that server. Also, I'm not sure what you mean by "the second time".
Sure, we'll get that to you. And by second time I mean after the player selects a server, where it loads the bulk of the game's resources. It'll be pretty obvious to you when you test.
The link you gave me has an embed that points to a single server. I didn't see any server selection on that page. Or are you running a separate server for selection purposes, and connecting users to the next one via link()? Because that'd be pretty crucial info right there.
Yes, there are two servers: one for the login where they select a world, and one for the main game. The players are being connected via link().
Can you give me some info on what the URLs are that they're linking to? I think that's probably the meat of the problem, and it explains some things for me. It could simply be that link() has a bug in it.
Yeah, it must be something with link(), since the code is just P << link("byond://ip:port".
Do you still need the latest source BTW?
Since you've described that link() is involved I suspect I can come up with a test case for this on my own. I'll be looking into it.
Just to let you know, I'm getting out the next build right away since it had fixes ready to go, but this issue is still top of the list for webclient stuff, even higher than the gamepad foo.
Any plans for this fix soon?
Page: 1 2