Something changed in mIRC's logging in the last few versions... which isn't acting right at all to me, so I have to revert to an older version.
When you start logging, if you're in a channel like, say, #Help. It'll make a #Help.1.log .. and when you log off, it'll become #Help.log.
If you log on again it'll make #Help.1.log again and then merge it into #Help.log when you log off again.
Well, what if mIRC crashes or your computer crashes? That merging doesn't happen, and something simple turns into a big mess.
I think it was better before when it simply wrote into the logs, because it came to a point that I had up to .8.log or such, and had no idea what went where in my actual log file.. rendering my logging useless.
The logging feature in mIRC 6.20 worked in the same way as previous versions, so you must be referring to mIRC 6.21.
In mIRC 6.21 the logging behaviour was changed in order to resolve the corrupt/mixed log file issues that many users reported when using multiple server connections.
mIRC 6.21 resolves this issue by ensuring that log filenames are unique for each status/channel/query/chat window and are only afterwards merged into the main log file.
In previous versions if mIRC or Windows crashed, your whole log could either be lost or corrupted. In the new version, only the non-merged part of your log might be lost or corrupted during a crash. This means that your main log always remains intact and only the most recent log might be lost.
In the event of a crash, you can go to the View Logs dialog in the Tools menu and merge any left-over logs if you wish.
I could make mIRC automatically merge left-over log files in the next version, however if the left-over logs are corrupted that might lead to the same issues as before.
Ah, thanks. Would this auto sort by time and such of when the logs began? or would I have to figure that out on my own...
Maybe you could add an option to disable the new logging behavior if someone doesn't have the corrupted issue.
Is there any feature to move the buffer to the actual log (unless part and rejoin)? It's very annoying as I use to automatically update channel statistics with mircstats which generates the stats from the logfile, which means I have to perform this ritual (part-rejoin) every time I want to update my stats page.
Also.. If there isn't, I would suggest a feature for moving the buffer into the actual log or an option to disable buffering.
Thanks, JJS3.
I agree that a (say) /flushlogs command might be useful.
In looking for new stuff about logfiles in versions.txt I noticed that there's a 'Merge' option in the logfile dialogue. You could use that.
I had a go at writing a scripted /flushlogs, and now realise how much of a pain it is. My initial attempt had been a simple:
//var %lfn = $chan(#).logfile | log off | log on -f %lfn
But you end up with logfile names like "#test.network.1.network.1.network.1.log" after a few iterations!
And of course that only works for channels...
//var %re = $+(/(.*)\.,$network,\.\d+\.log/), %lfn = $+($regsubex($chan(#).logfile,%re,\1),.log) | echo -a %lfn | log off $$chan | log on $chan -f %lfn
is a bit better...
Is there any feature to move the buffer to the actual log (unless part and rejoin)? It's very annoying as I use to automatically update channel statistics with mircstats which generates the stats from the logfile, which means I have to perform this ritual (part-rejoin) every time I want to update my stats page.
Also.. If there isn't, I would suggest a feature for moving the buffer into the actual log or an option to disable buffering.
Thanks, JJS3.
This seems to work, but I am not sure of how safe/reliable it is:
alias flushlog {
if ($1) {
var %flush.active = $1
}
else {
var %flush.active = $active
}
var %flush.path.1 = $window(%flush.active).logfile
var %flush.path.target = $gettok($nopath(%flush.path.1), 1, 46)
var %flush.path.2 = $mklogfn(%flush.path.target)
var %flush.color = $color(Info Text)
var %flush.isfile.1 = $isfile(%flush.path.1)
var %flush.isfile.2 = $isfile(%flush.path.2)
if ((%flush.isfile.1 == $true) && $&
(%flush.isfile.2 == $true)) {
.copy -a $+(", %flush.path.1, ") $&
$+(", %flush.path.2), ")
write -c $+(", %flush.path.1, ")
}
if ((%flush.isfile.1 == $false) && $&
(%flush.isfile.2 == $false)) {
echo %flush.color -ae * /flushlog: file not found
}
else {
echo %flush.color -ae * Flushed log: %flush.active
}
}
alias viewlog {
if ($1) {
var %view.active = $1
}
else {
var %view.active = $active
}
var %view.path.1 = $window(%view.active).logfile
var %view.path.target = $gettok($nopath(%view.path.1), 1, 46)
var %view.path.2 = $mklogfn(%view.path.target)
var %view.isfile.1 = $isfile(%view.path.1)
var %view.isfile.2 = $isfile(%view.path.2)
if (%view.isfile.2 != $true) {
if (%view.isfile.1 == $true) {
flushlog %view.active
run $+(", %view.path.1, ")
}
else {
echo $color(Info Text) -ae * /viewlog: file not found
}
}
else {
flushlog %view.active
run $+(", %view.path.2, ")
}
}
A nice bit of scripting there.
Here's a slightly modified version
alias flushlog {
var %flush.active = $iif($1,$1,$active), %flush.path.1 = $window(%flush.active).logfile, %flush.path.target = $gettok($nopath(%flush.path.1),1,46), %flush.path.2 = $mklogfn(%flush.path.target)
var %flush.color = $color(Info Text), %flush.isfile.1 = $isfile(%flush.path.1), %flush.isfile.2 = $isfile(%flush.path.2)
if (%flush.isfile.1 && %flush.isfile.2) {
.copy -a $qt(%flush.path.1) $qt(%flush.path.2)
remove $qt(%flush.path.1)
}
echo %flush.color -ae * $iif(!%flush.isfile.1 && !%flush.isfile.2,/flushlog: file not found,Flushed log: %flush.active)
}
alias viewlog {
var %view.active = $iif($1,$1,$active), %view.path.1 = $window(%view.active).logfile, %view.path.target = $gettok($nopath(%view.path.1), 1, 46), %view.path.2 = $mklogfn(%view.path.target)
var %view.isfile.1 = $isfile(%view.path.1), %view.isfile.2 = $isfile(%view.path.2)
flushlog %view.active
$iif(%view.isfile.2,run $qt(%view.path.2),$iif(%view.isfile.1,run $qt(%view.path.1),echo $color(Info Text) -ae * /viewlog: file not found))
}
I just wanted to post one last update on this topic:
[Changes: The previous /flushlog did not flush the buffer if the main log file hadn't been created yet; it now does. Added an -h switch to hide the results of the /flushlog command.]
alias flushlog {
if (-* iswm $1) {
if (h isin $1) { var %flushlog.hide = $true }
if ($2 != $null) { var %flush.active = $2 }
else { var %flush.active = $active }
}
else {
if ($1 != $null) { var %flush.active = $1 }
else { var %flush.active = $active }
}
var %flush.path.1 = $window(%flush.active).logfile
var %flush.path.target = $gettok($nopath(%flush.path.1), 1, 46)
var %flush.path.2 = $mklogfn(%flush.path.target)
var %flush.color = $color(Info Text)
if ($isfile(%flush.path.1) == $true) {
.copy -a $qt(%flush.path.1) $qt(%flush.path.2)
if (!%flushlog.hide) {
echo %flush.color -atge * Flushed log: %flush.active
}
.remove $qt(%flush.path.1)
}
else {
if (!%flushlog.hide) {
echo %flush.color -atge * /flushlog: file not found
}
}
}
alias viewlog {
if ($1 != $null) { var %view.active = $1 }
else { var %view.active = $active }
var %view.path.1 = $window(%view.active).logfile
var %view.path.target = $gettok($nopath(%view.path.1), 1, 46)
var %view.path.2 = $mklogfn(%view.path.target)
flushlog -h %view.active
if ($isfile(%view.path.2)) { run $qt(%view.path.2) }
else { echo $color(Info Text) -agte * /viewlog: file not found }
}
Is there any feature to move the buffer to the actual log (unless part and rejoin)? It's very annoying as I use to automatically update channel statistics with mircstats which generates the stats from the logfile, which means I have to perform this ritual (part-rejoin) every time I want to update my stats page.
Also.. If there isn't, I would suggest a feature for moving the buffer into the actual log or an option to disable buffering.
Thanks, JJS3.
I'm having the same problem with mIRCStats now, so I've decided to go back to 6.20. An option to disable buffering would be very nice indeed.
You guys are probably misusing the term buffering, if im not mistaken the buffer settings are how much is kept in memory (and thus availible in sroll backs) for each window. Disabling would mean nothing is availible, no scroll back. (although i guess if all the client is doing is logging then it doesnt really matter in that particular case)
Im going crazy about this new "feature"!
Got an log of a channel that is 95MB large and is +1000days old. And now this I can't get mIRC to write to that file. It writes to #channelname.network.1.log no matter how I try to get it to write to the right one it dosen't! Why mess with a system that works!?
Revert back to the old system plz! This one really sucks!
The term 'buffer' simply means a temporary storage place.
The buffer you're talking about is a buffer (in memory) that allows you to get at old information that had been displayed in the window. (And is currently the only use of the term within mIRC)
The buffering here is of the log that will be written to file. The fact that the buffer is a file itself is just an implementation.
Of course, if you were to refer to the buffering of the log file as opposed to the buffering of the window, you'd need two distinct terms to avoid confusion. "Log Buffering" and "Window Buffering" seem perfectly adequate, however
I guess i dont really concider the way logging works with the flat file 'buffering', its not all truely kept in memory surely (that could potentially waste a lot of memory), afaik its actually written to the file, mirc just keeps the file open (and i guess locked) so only mirc can use it. (note that the entire file does not need to be in memory for it to be open)
Anyway, i havn't looked at mircstats for a very long time, but i thought it had the ability to examine dated log files? (as a temporary solution to the problem is appending to a huge existing log file?)
Maybe log file updates could be done on a timely basis (if new data is required to be written) and the files unlocked between updates... this should greately reduce the risk of a crash while a log file is open resulting in corruption. (maybe on top of the timed updates, every xx lines if reached earlier than the next sheduled update)... a command to force the updates would naturally come with this.
Apologies if i am mistaken about how it all works now and in prior versions, logging is of little importance to me so i have never dived too deeply into it.
If it worked I wouldn't have changed it :-] see the board for posts regarding multi-server log file corruption issues in previous versions of mIRC and requests by users to fix it.
The current solution is the only method I could think of that would resolve the problem. You can see my post at the top of this thread for an explanation of the method.
If you can think of another method that makes mIRC handle multi-server log files correctly, let me know and I'll see what I can do.
Do we know exactly what was causing it? I'm always on multiple networks/servers and have never had a corrupted log regardless how many times I've crashed mIRC.
If log file corruption after crashes only happens when connected to multiple servers... how about keeping log files for multi-server connections seperated by including the $cid in the log's name? Like #chan.network.date.cid.log ...also that way log files would be written without a "buffer" again, fixing the mIRCStats issue. Not sure if this would work as I've never had corrupted logs after a crash (in spite of multi-server connections), but it's an idea.
$cid isn't always the same, though. If you close the connection, open another one, then open the closed one again, it won't have the same $cid, which will probably cause problems.
It has been working for +3 years on my logfile, now it dosen't. So I will have to use an old mIRC version from now on?
Perhaps make this an optional setting. If someone is paranoid about corrupting their logs, they can enable the new style logging, and if they want the functionality of old scripts, they can disable the new style, and if they want both.. well they are SOL. :p
-genius_at_work
Just to be clear about this: are you saying that mIRC not saving the log at all? If it's not saving the log, then something is wrong.
mIRC will save the log to #channelname.network.N.log and once that window is closed, it will merge that log file into the main log file #channelname.network.log.
If it is merging the log, then it's working correctly.
If it is not merging the log, can you post a step by step method in a clean install of mIRC that reproduces this issue for you?
I think the 'problem' the original poster was talking about was related to what happens when mirc or (more likely) windows crashes and the automatic merge does not occur (and/or corruption?)
IMO, the underlying crash issue should be fixed, not changes made to software to accomodate it. (if indeed that is the case)
I guess during a crash of some sort the merging does not occur, and if you dont remember to do it manually things could become a mess, or entire time periods missed, etc.
Maybe a few logging options such as 'automerge on startup' or a command/timed automerge feature could be useful for both crashers and mircstats users.
I think the 'problem' the original poster was talking about was related to what happens when mirc or (more likely) windows crashes and the automatic merge does not occur (and/or corruption?)
I guess during a crash of some sort the merging does not occur, and if you dont remember to do it manually things could become a mess, or entire time periods missed, etc.
Indeed. I've got multiple #channelname.network.N.log -files due to crashes etc. I should take a look at the files and try to paste the .N. -files into the actual log file, trying to locate where they belong in the file.
Maybe a few logging options such as 'automerge on startup' or a command/timed automerge feature could be useful for both crashers and mircstats users.
These features would solve all problems I'm experiencing, I think. I don't regularly shut down my PC so the log files won't merge automatically (which means I'll have to part and rejoin channels to perform the merging.)
At the moment I have all mIRC Stats automated update sctipts turned off because it won't update the stats if i don't first part and rejoin the channel (or merge the log some another way).
Now the stats look mostly like this:
#xiit.org Quakenet Stats by JJS3. There's missing a great deal of lines in the log => stats (since they are in the .N. -files.) The channel has been quite active lately but in the actual log there's days of maybe 30 lines.
Oh, uhm now I feel stupid :$
Haven't checked but if thats the way it's supposed to work then it might work :P Are there any other way of merging the log without rejoining the channel then? Some command or something?
I also agree with what someone else in the thread suggested, an option to switch between the old "unsafe" logging method and the new "safe" one.
Temporary log problem (.1.log etc) can be handled easily in mIRCStats by selecting multiple logs with wildcards like this:
c:\logs\#chan*.log
or if you have the same channel open in multiple networks:
c:\logs\#chan.network*.log
This picks up all matching logs, both permanent and temporary and analyzes them in chronological order. It also handles dated logfiles (monthly, weekly...) just fine.
That should work in most cases, unless you crash your mIRC or open multiple connections to the same channel.
I do understand the reasons for this, I have experienced the doubling of lines when connected to the same network twice, etc.
However, this fix seems to need more functionality & configurability (i don't think that is a word... but you get it). Like the ability to change when and/or why the temp log is written to the permanent one. I think at least a manual command to put the temporary log into the actual log file would be great.
Perhaps a way to detect improper mIRC closures (crashes, etc) and do something with logs in the event of this (that might be too much work for such a problem as this).
My main problem with this new fix is that I don't have enough information, I'm not sure when it merges the files or why. I don't want to have join/part all the channels just to force a merge.
I'm pleased with the new logging technique, I would just like more control over it in the next version(s).
Wow, thanks so much Ave. That solves my problem, though I still wouldn't mind the new features. I didn't see this till after I replied above.
For some reason this doesn't work for me. Mircstats just skips the .N. files "due to complete overlapping". I wonder if I've set some option wrong or something..?
Mircstats returns (channel & network name cencored):
Analyzing log structure.. this may take a while.
2 files fitted into the given log filter.
#Channel.Network.log: 153707 lines
(su 28.08.2005 13:08 - ke 24.01.2007 00:29)
#Channel.Network.1.log: 22 lines - SKIPPED
(ma 22.01.2007 00:30 - ma 22.01.2007 00:30)
1 logs were skipped due to complete overlapping.
Ah, fixed. Sorry for needless post.