Yes, it can occur in a clean installation. In fact, I narrowed down the exact cause. Set the following options thusly in yours:
- IRC > Logging > [x] Line Colors
- IRC > Logging > [x] Timestamp Logs = "[HH:nn]"
- IRC > Logging > [Reload Logs] = Both
- IRC > Logging > [Automatically Log] = Both
- IRC > Messages > [ ] Timestamp Events = "[HH:nn]"
With this, mIRC will only strip timestamps from reloaded log lines that don't have ^C# codes before their timestamps (as shown by my original post's screen captures).
On the other hand, if you keep the same settings as above,
and set:
- IRC > Messages > [x] Timestamp Events = "[HH:nn]"
OR
- IRC > Messages > [ ] Timestamp Events = "[HH:nn:ss]"
... then every line's timestamp appears upon reloading a log (regardless of preceeding ^C# codes).
Unless I'm mistaken, isn't this the way it
should work? I.e., if the user wants his logs stamped but his channel window unstamped, then shouldn't timestamps be stripped upon reloading logs as long as [ ] Timestamp Events is unchecked and its format matches the format of [x] Timestamp Logs? At least, that's the way I thought mIRC has always worked ... and thus why I assumed the bug was with the recently-added [ ] Line Colors feature: by placing ^C# codes before timestamps instead of after them, mIRC's timestamp stripping func() must be failing to recognize the timestamps, and they appear in the window even when they shouldn't.
Here's an example, where I rigged two log files manually, one with ^C# codes before timestamps (as happens now), and one with ^C# codes after timestamps:
The result upon re-joining them, when [ ] Timestamp Events=[HH:nn] and [x] Timestamp Logs=[HH:nn]:
The result upon re-joining them, when [x] Timestamp Events=[HH:nn] and [x] Timestamp Logs=[HH:nn]:
So the fix seems to be having ^C# Line Colors codes after instead of before logfile stamps.
If you still can't reproduce the issue, I don't know what else to say except that I'm positively using mIRC 6.20 (under W98SE).
