[SOLUTION] Constant disconnects at loading screens?

"

Maelstromicus wrote:

So that would imply that it is almost certainly something to do with the way that the game files are pretty much all stored within one gigantic ggpk packed file.

A single file is almost always more efficient than many small files in terms of access performance. It allows a more efficient metadata mechanism to be used, and it reduces seeking.

"

bbnh_jesus wrote:

I have tried the following:

restarting computer
restarting router
unplugging router for 10 minutes
lowering graphical settings to bare minimum
lowering DX11 target fps to minimum
REPLACING the platter HDD the game was installed on

None of this worked.

I then tried installing the game onto a platter HDD raid array for faster platter drive load times and this cut down on the disconnects during loading screens by a small but noticeable amount.

I moved the PoE install from my platter HDD to my SSD (m.2 drive w/ PCI-e adapter) and all of these problems have gone away.

Interesting. Can you find the client.txt log from the period you were on the HDD, and see if it gives any reasons for the disconnection in there?

In other areas, GGG have a ten second network timeout - basically if the client and server don't communicate on the network for ten second, you get a disconnect. Loading data from disk in the load screen shouldn't stop network communication, though, so that should be independent.

If you can find log messages confirming it is the network, then this indicates that GGG have an issue with loading stuff blocking the network somewhere, and by confirming that to GGG tech support, they can go yell at the developers. (or buy them slow disks to make sure they don't break it ;)

There is nothing in the logs, it looks like that:

2017/12/27 18:38:13 16927980 d50 [DEBUG Client 5156] Entering area MapWorldsBog
2017/12/27 18:38:37 16952332 698 [INFO Client 5156] Abnormal disconnect: An unexpected disconnection occurred.

"

SlippyCheeze wrote:

"

Maelstromicus wrote:

So that would imply that it is almost certainly something to do with the way that the game files are pretty much all stored within one gigantic ggpk packed file.

A single file is almost always more efficient than many small files in terms of access performance. It allows a more efficient metadata mechanism to be used, and it reduces seeking.

If it were a single file with a single file structure I would agree with you. However, the ggpk file is not a single file per se, it is a single archive somewhat akin to a 7z, rar, tar type archive.
Therefore it's hardly more efficient, in fact, on the contrary it is less efficient than if the files in the archive were stored separately on the local drive. Instead of the game seeking out and deploying a file, instead it has to access it within an archive, temporarily unpack it, then deploy it. I do not pretend to know how many of these files are needed per instance that we open, but I would hazard a guess that it's more than one just by judging how complex a game program is. So, having to interrogate the archive multiple times and go through the deployment procedure is way less efficient than simply locating and using files stored locally.

I suspect that this is possibly what causes the disconnections. There's probably some sort of timeout setting for local file response on the server side that is getting triggered. However, we'll never know at this rate, as no one official seems to want to give us any more information on the actual process.

"

Maelstromicus wrote:

"

SlippyCheeze wrote:

"

Maelstromicus wrote:

So that would imply that it is almost certainly something to do with the way that the game files are pretty much all stored within one gigantic ggpk packed file.

A single file is almost always more efficient than many small files in terms of access performance. It allows a more efficient metadata mechanism to be used, and it reduces seeking.

If it were a single file with a single file structure I would agree with you. However, the ggpk file is not a single file per se, it is a single archive somewhat akin to a 7z, rar, tar type archive.
Therefore it's hardly more efficient, in fact, on the contrary it is less efficient than if the files in the archive were stored separately on the local drive. Instead of the game seeking out and deploying a file, instead it has to access it within an archive, temporarily unpack it, then deploy it.

Ah! I see why you are confused. Software can just read the data right out of the archive format into memory, without having to do any "unpacking" to disk in between.

"

Maelstromicus wrote:

I suspect that this is possibly what causes the disconnections. There's probably some sort of timeout setting for local file response on the server side that is getting triggered. However, we'll never know at this rate, as no one official seems to want to give us any more information on the actual process.

Your theory for disconnections is that GGG deliberately designed a file format to be as inefficient as possible, then wrote code to specifically cause it to fail when slow, then?

Sounds logical to me:

* write really bad code that disconnects a lot
* ???
* profit!

"

SlippyCheeze wrote:

Interesting. Can you find the client.txt log from the period you were on the HDD, and see if it gives any reasons for the disconnection in there?

In other areas, GGG have a ten second network timeout - basically if the client and server don't communicate on the network for ten second, you get a disconnect. Loading data from disk in the load screen shouldn't stop network communication, though, so that should be independent.

If you can find log messages confirming it is the network, then this indicates that GGG have an issue with loading stuff blocking the network somewhere, and by confirming that to GGG tech support, they can go yell at the developers. (or buy them slow disks to make sure they don't break it ;)

Here are some blocks of data in the log file. I'm stumbling through this absolutely massive file, but I did find a few things that I think might be related to what you're talking about.

2017/12/15 09:28:16 3444314 a5 [INFO Client 8120] Async connecting to sjc.login.pathofexile.com:20481
2017/12/15 09:28:16 3444408 cc [INFO Client 8120] Connected to sjc.login.pathofexile.com in 31ms.
2017/12/15 09:28:39 3467434 b1e [DEBUG Client 8120] Got Instance Details from login server
2017/12/15 09:28:41 3469399 b3b [INFO Client 8120] Just before calling client instance session
2017/12/15 09:28:41 3469399 d1 [INFO Client 8120] Connecting to instance server at 209.191.164.185:6112
2017/12/15 09:28:41 3469431 156 [DEBUG Client 8120] Connect time to instance server was 16ms
2017/12/15 09:28:49 3477730 7ca [DEBUG Client 8120] Joined guild named [x]
2017/12/15 09:29:06 3494422 966 [INFO Client 8120] : You have entered The Sarn Encampment.
2017/12/15 09:29:10 3497979 d44 [DEBUG Client 8120] Entering area 1_3_town
2017/12/15 09:29:34 3522252 68c [INFO Client 8120] Abnormal disconnect: An unexpected disconnection occurred.
2017/12/15 09:29:36 3524093 a5 [INFO Client 8120] Async connecting to sjc.login.pathofexile.com:20481
2017/12/15 09:29:36 3524124 cc [INFO Client 8120] Connected to sjc.login.pathofexile.com in 16ms.
2017/12/15 09:29:38 3526262 b1e [DEBUG Client 8120] Got Instance Details from login server
2017/12/15 09:29:38 3526309 b3b [INFO Client 8120] Just before calling client instance session
2017/12/15 09:29:38 3526309 d1 [INFO Client 8120] Connecting to instance server at 209.191.164.179:6112
2017/12/15 09:29:38 3526340 156 [DEBUG Client 8120] Connect time to instance server was 15ms


There's a ton of this information but I'm not sure what I should be looking for. There are a ton of disconnect lines in the log but there's no listed reason for it. It's just an abnormal disconnect.

"

bbnh_jesus wrote:

There's a ton of this information but I'm not sure what I should be looking for. There are a ton of disconnect lines in the log but there's no listed reason for it. It's just an abnormal disconnect.

Dang. I had some hopes, but yeah, that has nothing useful. :?

I'd suggest you take it to GGG tech support via email at this point. I'm out of ideas, so it is time to involve them. Send 'em the same network traces and stuff so they don't ask you to repeat those tests. :)

Good luck!