mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2003
Posts: 23
P
Pomax Offline OP
Ameglian cow
OP Offline
Ameglian cow
P
Joined: Jan 2003
Posts: 23
I haven't upgraded my 6.2 to 6.21 yet, but the decision to change how logging is handled makes me apprehensive of upgrading at all.

I'd like a feature in the logging dialog that lets me specify whether I want my logs to be written per line of incoming data, or per "when you close the windows". I for one don't close mirc at all; it runs pretty much 24/7, the only reason windows get closed is because I need to reboot the machine it's running on for some reason, which is very infrequent.

This means that if I were to upgrade, I no longer actually have any access to my logs at all, which is mighty inconvenient if I need to go back through a log for information that ran past the buffer (server helpdesk and teaching japanese means I have to do that a lot).

It seems that for people who run mirc 24/7 this new logging choice is kind of detrimental to the very functionality of logging (you have access to what was said). Before someone replies with "you can just look in the temp log", yes this is true, and no that's not user friendly in any way =)

so, feature request: option to specify that logs should log per old policy (per line), per new policy (when you close windows) or perhaps even per time unit (cath-up log every ... seconds/minutes)

- Pomax

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
I think you misunderstand how it works. You're still logging everything. Your "current" logs are just put into a .1.log file instead of a .log file. When you part the channel, close mIRC, etc, then the .1.log file is merged with the .log file. You still have everything... you just might have them in different places (old log before parting in .log and new log after rejoining in .1.log). You won't lose anything and you will still have access to all of your old logs.

You did mention the temp log (what I'm talking about above). However, I fail to see where this is less user friendly than looking in the .log file. They look the same and work the same. The only time it's an issue is when you have an old part and a new part that aren't in the same .1.log file. If you're always online and never leaving channels, then you'll have just one file to look at.

What people don't like about it are the various log viewers that no longer work properly because they don't know what to do with the .1.log files. It really isn't difficult to update these to work with the new logging method, of course.

As for the option, I have a feeling the number of annoyed users may be enough so that Khaled does make it optional in the next version. But until then, I really don't see any reason to be concerned about the logs.


Invision Support
#Invision on irc.irchighway.net
Joined: Mar 2006
Posts: 47
C
Ameglian cow
Offline
Ameglian cow
C
Joined: Mar 2006
Posts: 47
Originally Posted By: Riamus2
I think you misunderstand how it works. You're still logging everything. Your "current" logs are just put into a .1.log file instead of a .log file. When you part the channel, close mIRC, etc, then the .1.log file is merged with the .log file. You still have everything... you just might have them in different places (old log before parting in .log and new log after rejoining in .1.log). You won't lose anything and you will still have access to all of your old logs.

Hmm? I'm still getting .1.log (and sometimes .2.log and .3.log) files that end up never getting merged... With sessions before and after the main log. That's partly why I tried to script my own logging system that logs upon EXIT. But I've talked enough about this elsewhere.

Last edited by CitizenKane; 20/01/07 01:48 AM.
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Well, it should always merge the files unless you crash. At least, that's how it's supposed to work. I know that I always have .log for everything except the current log file for each log, which is always .1.log.

If it's not merging correctly and you haven't crashed, then it may be some bug (or perhaps a script) that is preventing the merge. I really don't know because the change in logs doesn't affect me... I can read the current logs just fine through Invision's log viewer.

Although not a "nice" solution, if you have troubles with the logs merging properly, you could have a script that will automatically /hop the channels every few hours or every day or whatever. That /hop should act like a /part and your logs should merge when that happens. (Untested)


Invision Support
#Invision on irc.irchighway.net
Joined: Oct 2005
Posts: 1,741
G
Hoopy frood
Offline
Hoopy frood
G
Joined: Oct 2005
Posts: 1,741
Like others, I think that Khaled should make the logging method optional. I also think that related commands should be added. The only one that comes to mind right now is something to immediately merge all the .1.log files into their respective .log files. That would make it very easy to modify the log viewers (just add a /mergelog line to certain points in the scripts).

-genius_at_work

Joined: Aug 2006
Posts: 183
T
Vogon poet
Offline
Vogon poet
T
Joined: Aug 2006
Posts: 183
Actually, just including a /mergelog command would be wonderful. I too haven't upgraded yet because it would require some pretty extensive re-scripting on my part.


Yar
Joined: Aug 2004
Posts: 28
0
Ameglian cow
Offline
Ameglian cow
0
Joined: Aug 2004
Posts: 28
Just in case some have missed it, you can use this for now. (I'd prefer to see a similar command included in an upcoming release, though.)

Code:
/flushlog [-h] [window]


Code:
/viewlog [window]


Code:
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
    }
  }
}


Code:
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 }
}

Joined: Feb 2007
Posts: 2
T
Bowl of petunias
Offline
Bowl of petunias
T
Joined: Feb 2007
Posts: 2
Thanks! This script does its job smile

For Khaled: I'm running mIRC usually around 5-7 days in a row and I've got mIRCStats doing the stats for the channel log every morning automatically, but due to this log change it only does the stats from the old log that doesn't contain the new information. I've never had any problems with the logs (my log is already over 300MB) so I'd really want to see this log change made optional, or at least implementing a command like this above flushlog to give an option to merge the logs automatically at certain times. Other than this (from my personal POV) unwanted change - keep up the good work!

Joined: Feb 2007
Posts: 2
T
Bowl of petunias
Offline
Bowl of petunias
T
Joined: Feb 2007
Posts: 2
Originally Posted By: Tormentor
Thanks! This script does its job smile


Well actually, it seems not to work after all, I just didn't check it all the way before.. It does find the files and deletes the .X.log, but does NOT merge it to the older one - maybe the problem is that the older one is 300MB big, dunno :I


Link Copied to Clipboard