Rolling log files

I am not sure if this is possible but I am sure some of the instability that people experience from time to time is due to the computer handling the log files and the traffic.

I generate over 800 MB of trigger logs not including the event los action logs etc.  Sometimes you get insufficient virtual memory errors and other lock-ps.  Also opening them to look at the bigger ones takes minutes each.

How about in "settings" having an optional maximum log size, (perhaps 10MB) and aftr that size is reached it saves that log with the suffix "_1,,,2,,,3 etc and starts a new one.  You could even write a macro to glue them all back together at the end of the day (outsite MFP) for checking if that was more convenient.  If size is a problem to query, could you restart the logs after a variable time int he settings, 1 hour, 2 hours etc.

Hi alfaman,

 generate over 800 MB of trigger logs

That is the reason why I switch off logging usually. Only when I do some changes in trigger I switch on logging, to check if everything works as expected.

you get insufficient virtual memory errors and other lock-ps.

My memory problems and lock ups are solved in Version 6. Vorsion 6 works fine for me even if refresh rates are smaller than time needed to update list of bets or when MPF slows down requests to stay below the API limit.

Martin,

thanks again, I forgot you could switch logs off but I generally do want the ability to find out why they have inevitably failed to make a profit again !!

I agree I have had less problems in the more recent updates of version 6 - but I do get some still - not including when the dog switches the PC off in the middle of the races like last night. - anyone want a dead Westie ?

Alfaman, sorry to hear about the dog! 

As for the problem with logs - why don't you use the option "At the start of the program clear log records older than ... days"? Set this to "1" and you won't have that much rubbish piled up in the logs directory.

Oxa,  yes I only keep two days of logs but that's just hard drive space.  When MFpro is active I guess the logs are actually in virtual memory (but perhaps not) but as it can take well over a minute to open the file I presume that slows things down when MFpro is writing to it.

Oh, Ok, I understand the problem now. Well, we'll definitely do something about it, although the log file is certainly not kept in memory: only the last couple of records are, and then they are flushed down to the file on the hard drive.