Something's up with 3.0.2

[dr_venture]

It's taking *forever* to log into my campaigns, even with my localhost version on the GMing computer. My C&C group has been seeing this get worse and worse over the last couple months... tonight I couldn't log in with my localhost player on the GM computer, so I did some debugging/testing.

If I open the console and log in as localhost, it looks like once a player gets to the Character Selection screen, a huge number of assets and/of nodes are being transferred veeeerry slooowlly before the list of characters even shows up. After about 15 minutes I gave up, then went in and turned off all extensions and closed all modules, and exported/eliminated characters from about 20 down to 8. This did speed things up, but even so, logging in takes about 7 or 8 minutes for the localhost copy. I tried logging in with another computer on my home intranet and it's been trying to log in for about 20 minutes

During this time, the GM's copy of the program freezes up - if more than 1 person is connecting, the GM's program is totally unusable. I've nuked the cache on the GM computer (thinking that maybe the localhost would log in faster, but still no good.

UPDATE: The other computer on my home network finally showed a character to select after about a half hour, but I'm still unable to even get into the GM's version of the program.

2nd Update: After 30 minutes of 3 people trying to log in remotely, no one was successful, and I am unable to get into the FG application - it's locked pretty solid right now. Since I clicked away, I can't see if any files are still transferring. This is pretty majorly bad - totally unusable. Web pages seem to be loading totally normally now, though the sole remaining player debugging with me just reported, "Downloading at less than 100Bps. NOT Kbps." He the guy with the fastest connection, too. I just pinged him on Hamachi and got:

Reply from 25.18.209.24: bytes=32 time=123ms TTL=128
Reply from 25.18.209.24: bytes=32 time=129ms TTL=128
Reply from 25.18.209.24: bytes=32 time=129ms TTL=128
Reply from 25.18.209.24: bytes=32 time=142ms TTL=128
Reply from 25.18.209.24: bytes=32 time=169ms TTL=128
Reply from 25.18.209.24: bytes=32 time=172ms TTL=128
Reply from 25.18.209.24: bytes=32 time=120ms TTL=128
Reply from 25.18.209.24: bytes=32 time=122ms TTL=128
Reply from 25.18.209.24: bytes=32 time=121ms TTL=128
Reply from 25.18.209.24: bytes=32 time=153ms TTL=128
Reply from 25.18.209.24: bytes=32 time=133ms TTL=128
Reply from 25.18.209.24: bytes=32 time=128ms TTL=128
Reply from 25.18.209.24: bytes=32 time=246ms TTL=128

CPU usage is at about 25% - Fantasy Grounds shows as using about .2% of CPU cycles. Total RAM usage is at 3.7gb - about 50% of total. Of that FG is about 1.7gb.

[sigilbeckons]

This is an issue we are having as well, even local loads take forever and can even cause the whole thing to lock up and crash.

[Shimrath]

I've been having an identical issue, and some nice folks have been trying to help:

https://www.fantasygrounds.com/forums/showthread.php?20519-FG-Freezing-When-Players-Connect

[dr_venture]

Just tried having the user with the fastest connection log in a select a character in a new, entirely empty campaign - took him about 2.5 minutes - he reports his speed as "70Kbps instead of 70 bps"... after which tokens keep downloading.

Do tokens redownload to each player every time they connect, or only once the first time they connect?

[dr_venture]

I've been having an identical issue, and some nice folks have been trying to help

Thanks!

[dr_venture]

FWIW, my intuition is that something happens to a campaign over time that increases the amount of work that FG has to do at the Character Selection screen. I definitely have a lot of tokens & need to put them in modules, but that hasn't been a crippling problem in the past, and isn't a problem with the new campaign test we did tonight. I have been noticing this problem getting steadily worse session by session since December, I'd guess. Could it be tied to the node permissions where everyone whose ever connected or reconnected gets added to just about every node as an owner? My hunch is that it's something along those lines that is just kicking FG in the nuts when it gets to the Character Selection screen... God forbid multiple players getting to that screen at the same time!

This should have nothing to do with Hamachi or connection speeds, as I can't connect with localhost or another computer on my home network.

...and yes, the console log is 163 pages long at courier 10 point. Is there a setting that turns on/off verbose logging? Perhaps that is the problem?

[Trenloe]

Could it be tied to the node permissions where everyone whose ever connected or reconnected gets added to just about every node as an owner? My hunch is that it's something along those lines that is just kicking FG in the nuts when it gets to the Character Selection screen... God forbid multiple players getting to that screen at the same time!
Check the size of the db.xml in the campaign - how big is it?. Make a copy of your campaign, load up that copy and try typing /flushdb in the chat window and see if that makes a difference. After using /flushdb and the campaign has saved, what is the size of db.xml?

[dr_venture]

Dang it... I just flushed the DB before checking the db size. It's currently at 1383k... a previous DB from today is 1853k, so yeah, that's a *lot* of garbage removed! I was able to get my localhost to log in, but it still took about 10 minutes. Attached is the console log from soon after the localhost began attempting to log in, up to the point the characters filled into the Character Selection window. Each 1 on those lines represents .5 to 1 second of time... so a lot of waiting around for background processes. Also, towards the end of the process, I began noticing the console log stopping for 10 or 20 seconds, while either the GM or localhost window title had "(NOT RESPONDING)" appended to it, then that not would disappear and the console log would continue... almost like some buffer had become over-full. FWIW.

[Trenloe]

Are there a bunch of Rolemaster tables being transferred? I see a lot of "Network Notice: Send - DATAR: tables.rm_grapple...", rm_krush, rm_martial_arts_strikes, etc.. Pages 71-140 are transferring tables that begin with rm_

[dr_venture]

Those are Rolemaster tables I have converted for use with C&C - they're basically big standard FG tables that use the built-in table functionality, with a column for each crit type. I noticed those too - I'm assuming that the log-in code has to go through all the tables and assign player-ownership to them.

[Trenloe]

Those are Rolemaster tables I have converted for use with C&C - they're basically big standard FG tables that use the built-in table functionality, with a column for each crit type. I noticed those too - I'm assuming that the log-in code has to go through all the tables and assign player-ownership to them.
Could you export the tables to a module, remove the tables from the campaign and then try logging in with and without the table module activated? Basically, try to see if the tables make a difference.

[dr_venture]

Will do... but does FG copy the tables to the players every time they log in... meaning they're not cached? I suppose the workaround would be to put the tables in a module and have all the players download and install it... but what about other modules - if a player doesn't have the PHB and I set it to force loading for players, does FG always download a fresh copy of the module every time they log in? That would unfortunately take a lot of the convenience out of that feature :|

[Trenloe]

Will do... but does FG copy the tables to the players every time they log in... meaning they're not cached?
I don't know. Try logging in again with the network diagnostics and see if the tables are being sent again.

[dr_venture]

I don't know. Try logging in again with the network diagnostics and see if the tables are being sent again.

Yep, they are re-downloaded every time a player logs in for each session. Dang.

[damned]

tables or PHB or both?

[Leonal]

We had an issue with this and it appears having "network diagnostics" enabled makes connecting take forever. If you have it on, turn it off and try again.

@Smiteworks: My GM has had network diagnostics enabled ever since it was implemented, and it only became an issue the past few weeks, even when connecting through a second instance with localhost.

[dr_venture]

THAT'S IT! Thanks! Simply turning off networking debugging makes the larger campaign usable again. Leonal: I'll have your baby now.

@Smiteworks: Was there a change to network debugging in the 3.0.2 release, or some small change in the past month or so?

[Moon Wizard]

Please turn Network diagnostics off in all cases, unless specifically asked by us for debugging a network issue.

It hugely increases the overhead of all network communications, since every network interaction has to be logged to disk which is way slower than networks.

Regards,
JPG

[Shimrath]

It appears that disabling network diagnostics has also solved my issue! Thanks everyone.

[dr_venture]

Please turn Network diagnostics off in all cases, unless specifically asked by us for debugging a network issue.

May I suggest that a message be shown in red text when the program starts and network diagnostics have been enabled, telling the user that it should only be on if they have been requested to enable it by Smiteworks? It sounds like it's basically always an error to run the diagnostics except in unusual circumstances. Or perhaps more simply put a warning dialog in the settings window where this option is set, warning the user.

[Blacky]

Seconded (although I had this one for weeks and weeks without any issues).