Page 1 of 1

logs over 1 mb not being moved via utstats ftp

Posted: Thu Oct 21, 2010 7:40 am
by CVROY
I have to manually transfer logs from my game server to my web server because the log parse with proper FTP cfg only transfers files less than approx 1 mb. Anything smaller the log parse works as it should, grabbing logs from my game server, pulling them to the utstats for parse.

Panther, Is there a limit on the file size it will transfer or a timeout I can adjust in any of the .php files?

UTStatsDB version = 306
Operating system and version = Linux
Database type and version = mysql 4.1.22-standard
PHP version = 5.2.11
Web server and version = 2.2.14 (Unix)
Unreal Tournament version = UT3
Stat logger type and version = utstats 104

Re: logs over 1 mb not being moved via utstats ftp

Posted: Thu Oct 21, 2010 3:16 pm
by CVROY
OK I found where you can change the PHP time in the main CFG menu... my question regarding log size still remains. Is there a limit to the size log that utstats can parse?

Re: logs over 1 mb not being moved via utstats ftp

Posted: Thu Oct 21, 2010 3:44 pm
by Panther
There is no size limit in current versions. A long time ago UTStatsDB (which it wasn't even called at the time) would load the entire log file in at one time to parse it but now it simply reads it one line at a time, up to 1,536 bytes (if a line is over 1,536 bytes then it's going to get truncated and likely not get parsed correctly, but you shouldn't have any log lines that long).

Re: logs over 1 mb not being moved via utstats ftp

Posted: Thu Oct 21, 2010 4:04 pm
by CVROY
Great, thank you for the information :)

Re: logs over 1 mb not being moved via utstats ftp

Posted: Fri Oct 22, 2010 6:37 am
by CVROY
I changed the parse time to five minutes however there is on large log that will not parse, I have attached it... if you could look at it and see if anything sticks out that may be causing this.

I did notice that it seems to happen on maps where it goes into OT... it generates a huge log because the game goes on so long and then it does not parse. This one is the largest log I have seen yet.