mIRC Home    About    Download    Register    News    Help

Print Thread
#235897 18/01/12 09:31 PM
Joined: Jan 2012
Posts: 10
M
mtakala Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Jan 2012
Posts: 10
Hello!

Over the last few weeks I've noticed that on some channels at some random times, the display buffer which is set as 2000 lines in the options, gets flushed so that a little over 100 lines is visible.

Logging is enabled for all channels, so I've not missed anything important on any channel.

Is there a setting somewhere that could affect this? Why would a buffer get cleared to less than the limit set in the options? Or have I accidentally stumbled upon a hidden hotkey, after ten years of mIRC usage?

I'm on mIRC 7.22, Windows 7 64bit, 8GB, 21 active channel windows on 4 different networks.

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Do you maybe have a script that will rejoin a channel for some reason? For example, if you're in a small channel and you're an op, you might have one that rejoins the channel if you're the only one in there and you're not an op (regain ops script). Or there may be some other reason you might have a script to rejoin a channel. If you /hop, the buffer won't clear, but if you /part and /join, the window will close and reopen, causing you to clear the buffer.

Other than that, there is a /clear command that will clear the buffer. Perhaps something like that is in a script.

Just throwing some things out as I've never seen that happen.


Invision Support
#Invision on irc.irchighway.net
Joined: Jan 2012
Posts: 10
M
mtakala Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Jan 2012
Posts: 10
I only have a simple on start { /server some some servers } on connect { join some channels if network==right } which has worked for years. I do not run any other scripts.

Also, the buffer emptying does not seem to be associated with any disconnects, parts or joins either.

And this has just seemed to start happening during the last weeks... and I did update to this version of mirc sometime over Christmas or New Year, and the previous version was 7.17.

Joined: Feb 2011
Posts: 448
K
Pan-dimensional mouse
Offline
Pan-dimensional mouse
K
Joined: Feb 2011
Posts: 448
I've managed to get this "bug" from time to time, its rather rare.

7.22 WinXP

Joined: Mar 2010
Posts: 57
W
Babel fish
Offline
Babel fish
W
Joined: Mar 2010
Posts: 57
Hurray! someone else has actually experienced this bug.

Ok, so let's point out some details about this. I've experienced this bug for quite a while now (possibly predating 7.x, but I cannot confirm this) however it's impossible to reproduce by its very nature. A few things I've noticed about this bug:

The bug does the following things:
  • 1) The channel buffer shrinks to about ~75-100 lines where previously the channel could have had as much as 1000s of lines. (If the buffer was much bigger, say 10K lines, it might be reduced to a little more lines, say ~200-500 lines.)
  • 2) The scrollbar remains very small as if the buffer still got 1000s of lines. The second you scroll up, the scrollbar updates (and grows) to reflect the fact that the buffer is only about 75 lines (or more on larger buffer sizes).

The bug has the following properties:
  • 1) The bug happens on a per-channel base. i.e. even though one channel is affected, other don't have to (often this seems to be the case).
  • 2) The bug can effect different channel buffers on different networks, it's almost random.
  • 3) Channel activity does not seem to change the likelihood of the bug. (It happened in a channel where I was the only person there, with a few 100s lines of testing messages).
  • 4) The bug applies to windows xp, vista, and 7. Both 64 and 32 bits.
  • 5) The window buffer size in the option dialog has no effect on the bug.
  • 6) I have experienced the bug on a clean mIRC
  • 7) $line($chan, 0) and like idents report the reduced amount, as expected


Once again, the bug is very hard to spot if you do not actually scroll up the chat as the scrollbar does not indicate this problem . Many people are likely experiencing this bug without even realizing it.

One could script a detection for this bug by tracking the $line($chan,0) count as it changes.



P.S. The title is not really correct, the bug does not empty the buffer, just shrinks it.

Last edited by Wiz126; 19/01/12 03:10 AM.
Joined: Mar 2010
Posts: 146
Vogon poet
Offline
Vogon poet
Joined: Mar 2010
Posts: 146
I've experienced this bug too. However, mine was getting fully flushed on a channel window... Couldn't figure what may cause it tho.


Nothing...
Joined: Jan 2012
Posts: 10
M
mtakala Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Jan 2012
Posts: 10
Great news that I'm not alone with this!

But, this is the kind of bug that will be difficult for Khaled to fix without steps to reproduce.

Joined: Jan 2012
Posts: 10
M
mtakala Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Jan 2012
Posts: 10
I took a bit of time to try to make this happen on purpose rather than by accident.

Immediately I got a hit on more than one channel window, and captured it on video: http://youtu.be/a4J3AscU2bw

Apologies for bad resolution. And no private matters were discussed on the channel I was on.


Last edited by mtakala; 19/01/12 01:40 PM.
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for the video, I can see that the vertical scollbar is changing size, however this is actually normal in some situations. It does not indicate that the number of lines has changed. mIRC calculates the size of the vertical scrollbar on-the-fly.

For example, if you resize the status window to the smallest possible size and fill it with several hundred lines and then maximize the status window, when you scroll up, the size of the vertical scrollbar will change.

As mentioned in a previous post, to see the actual number of lines, you would need to use the $line() identifier.

Since there are many possible situations where a buffer can get cleared, eg. a script, parting and rejoining a channel, and so on, I am not sure how easy it would be for me to reproduce this or to even monitor for it. One possible approach would be to use a script that, once a second, counts the number of lines in every window, outputs the count to a debug file, and alerts you if the number of lines has suddenly decreased.

Joined: Jan 2012
Posts: 10
M
mtakala Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Jan 2012
Posts: 10
Another instance of this happening; this time the buffer had gotten so short that it fit the window without any scrolling. Also, the scroll bar was at its correct height.

http://tinypic.com/view.php?pic=jhsjug&s=5

At the time, mIRC hadn't done any disconnects nor reconnects on any network, and it had not rejoined any channels. I had only been idling for some hours and that's what I saw when I returned to the PC. The PC's uptime is 4 weeks and some days, which is also the uptime of mIRC itself, but uptimes seems to be irrelevant in regards to my experiences with the buffer's strange behavior.

If there is anything I could try to do to produce useful debug for Khaled, I'll be more than willing to help. I've got some experiences with debugging windows software, but not running mIRC scripts.

Last edited by mtakala; 15/02/12 09:23 PM.
Joined: Feb 2012
Posts: 18
S
Pikka bird
Offline
Pikka bird
S
Joined: Feb 2012
Posts: 18
The main problem is that your window might get cleared, or culled, due to another script that messes with it directly. If that is the case, rudimentary debugging won't help.

However, that would probably be rare and it's more likely the result of some manner of event.

Below is a chunk of code that enables standard debug logging (server messages, sent and received) as well as adding debug logs for most events that wouldn't be caught by the debug logging.

In mIRC, press ctrl+r to open the remote scripts window, go to File, new..., then copy/paste the entire thing below:
Code:
; set to $false if you do not want a pop-up window asking you for feedback to appear
; set to $true to allow you to provide additional information in the log when the line count for a window decreases
; for example, you could enter "I was messing around with NNscript"
alias feedback { return $true }

alias checklines {
  ; make sure we still want to check things
  if ($window(@debug) == $null) { .timerchecklines off | .disable #debugevents }

  ; loop over all windows
  var %numwindows = $window(*,0)
  var %i = 1
  while (%i <= %numwindows) {
    var %window = $window(*,%i)
    var %windowlines = $line(%window,0)
    var %windowindex = $findtok(%window.cache,%window,44)
    ; if we have previously recorded this window
    if (%windowindex) {
      ; and thus its number of lines
      var %windowlines.old = $gettok(%windowlines.cache,%windowindex,44)

      ; check if it decreased, and log it if it did
      if (%windowlines < %windowlines.old) {
        echo -t @debug ?DEBUG -> WINDOW LINE COUNT DECREASED -> window: %window line.old: %windowlines.old line.new: %windowlines
        if ($feedback) { beep | echo -t @debug ?DEBUG -> FEEDBACK -> $?="feedback:" }
      }

      ; update the number of lines for the window in the cache if it's different either way
      if (%windowlines != %windowlines.old) {
        set %windowlines.cache $puttok(%windowlines.cache,%windowlines,%windowindex,44)
      }
    }
    else {
      ; otherwise this is a newly opened window and we can just add its results
      set %window.cache $addtok(%window.cache,%window,44)
      set %windowlines.cache $instok(%windowlines.cache,%windowlines,0,44)
    }
    inc %i
  }

  ; Now let's loop over our cache, and cull any cache results for which we no longer have an open window anyway
  ; ( This could partially be dealt with in on:close )
  var %i = $numtok(%window.cache,44)
  while (%i >= 1) {
    var %window = $gettok(%window.cache,%i,44)
    if ($window(%window) == $null) {
      set %window.cache $deltok(%window.cache,%i,44)
      set %windowlines.cache $deltok(%windowlines.cache,%i,44)
    }
    dec %i
  }
}

alias startdebug {
  .enable #debugevents
  echo -s ?DEBUG -> Debug info logging for window line count started
  echo -s ?DEBUG -> To disable, simply close the @debug window
  .debug -t @debug
  .log on @debug -f @debug.log
  .timerchecklines -o 0 1 /checklines
}

alias debugevent {
  if ($window(@debug)) { echo -t @debug ?EVENT -> on: $+ $event $iif($1,->) $1- }
}

on *:start:{
  unset %window.cache
  unset %windowlines.cache
  /startdebug
  /debugevent
}

#debugevents off
on *:active:*:{ debugevent lactivecid: $lactivecid activecid: $activecid lactive: $lactive active: $active }
on *:appactive: { debugevent appactive: $appactive }
on *:chat:*:{ debugevent <msg>: $1- }
on *:close:*:{ debugevent target: $target }
on *:connect:{ debugevent network: $network server: $server }
on *:connectfail:{ debugevent <reason>: $1- }
on *:dccserver:chat:{ debugevent chat }
on *:dccserver:send:{ debugevent send }
on *:dccserver:fserve:{ debugevent fserve }
on *:disconnect:{ debugevent network: $network server: $server }
on *:dns:{
  var %n = $dns(0)
  while (%n > 0) {
    debugevent n: %n dns: $dns(%n) nick: $dns(%n).nick addr: $dns(%n).addr ip: $dns(%n).ip
    dec %n
  }
}
on *:exit:{ debugevent }
on *:filercvd:*:{ debugevent filename: $filename nick:$nick }
on *:filesent:*:{ debugevent filename: $filename nick:$nick }
on *:getfail:*:{ debugevent filename: $filename nick:$nick }
on *:input:*:{ debugevent target: $target <input>: $1- }
on *:load:{ debugevent }
on ^*:logon:*:{ debugevent network: $network server: $server }
on *:logon:*:{ debugevent network: $network server: $server }
on *:midiend:{ debugevent }
on *:mp3end:{ debugevent }
on *:nosound:{ debugevent filename: $filename }
on *:open:*:*:{ debugevent target: $target }
on *:playend:*:*:{ debugevent filename: $filename }
on *:sendfail:*:{ debugevent filename: $filename nick:$nick }
on *:serv:*:{ debugevent <msg>: $1- }
on *:tabcomp:*:{ debugevent target: $target <input>: $1- }
on *:wavend:{ debugevent }
#debugevents end

on *:unload:{
  debugevent
  unset %window.cache
  unset %windowlines.cache
}

( code is preliminary, may have bugs )

Then press the OK button.
mIRC will warn you that there are initialization events in it, just accept those (you can see in the code for 'on:start' what they do).

From that point on, a bunch of logging will occur to the @debug window. Just leave that running in the background. If at any point the number of lines in a window decreases, the computer will beep (or play the default beep sound) and you'll get a little dialog asking you for feedback. I.e. if you pressed some button, you can enter that, and it will be included in the debug output.

Example output:
Code:
[03:37:11] ?DEBUG -> WINDOW LINE COUNT DECREASED -> window: Status Window line.old: 8 line.new: 0
[03:37:12] ?EVENT -> on:appactive -> appactive: $true
[03:37:14] ?DEBUG -> FEEDBACK -> I typed /clear, then alt-tabbed to the mIRC forums


The debug log is logged to a file as well, in mIRC's application data folder, 'debug.log'.

If you don't want the feedback popup to occur, you can disable it near the top of the script.

Last edited by Steeeve; 17/02/12 02:42 AM.
Joined: Jan 2012
Posts: 10
M
mtakala Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Jan 2012
Posts: 10
thanks for the script!

This is what I got (needed to blank out some ip-addresses and nicks.)

[17:31] ?EVENT -> on:appactive -> appactive: $true
[17:31] ?EVENT -> on:appactive -> appactive: $false
[17:31] ?EVENT -> on:appactive -> appactive: $true
[17:31] <- :____!_____@____-___-____-____.aa.dnainternet.fi PRIVMSG #channel_1 :teki [nimi]1 jos oli 2 numeroa samalla henkilöllä
[17:31] ?DEBUG -> FEEDBACK -> didn't do anything, mirc was idling.
[17:31] ?DEBUG -> WINDOW LINE COUNT DECREASED -> window: #channel_2 line.old: 449 line.new: 431
[17:31] ?EVENT -> on:appactive -> appactive: $false
[17:31] ?EVENT -> on:active -> lactivecid: 1 activecid: 1 lactive: #channel_3 active: #channel_3
[17:31] ?EVENT -> on:appactive -> appactive: $true
[17:31] ?DEBUG -> FEEDBACK -> didn't do anything, mirc was idling.
[17:31] ?DEBUG -> WINDOW LINE COUNT DECREASED -> window: #channel_2 line.old: 393 line.new: 226
[17:31] ?EVENT -> on:appactive -> appactive: $false
[17:31] ?EVENT -> on:active -> lactivecid: 1 activecid: 1 lactive: #channel_3 active: #channel_3
[17:31] ?EVENT -> on:appactive -> appactive: $true
[17:31] ?DEBUG -> FEEDBACK -> didn't do anything, mirc was idling.
[17:31] ?EVENT -> on:active -> lactivecid: 1 activecid: 1 lactive: #channel_3 active: #channel_3
[17:31] ?DEBUG -> WINDOW LINE COUNT DECREASED -> window: Status Window line.old: 1688 line.new: 1664
[17:31] ?EVENT -> on:appactive -> appactive: $false
[17:31] <- PING :irc.cs.hut.fi
[17:31] -> irc.cs.hut.fi PONG :irc.cs.hut.fi
[17:31] ?EVENT -> on:appactive -> appactive: $true
[17:31] ?DEBUG -> FEEDBACK -> didn't do anything, mirc was idling.

hmm. After testing a bit more, this seems to be somehow related to activating the mIRC's main window and switching the active channel.

Last edited by mtakala; 17/02/12 03:44 PM.
Joined: Jan 2012
Posts: 10
M
mtakala Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Jan 2012
Posts: 10
and that seems to be further confirmed by running mIRC for a time with you script running and trying to chat normally. I never got a popup with mIRC just idling, but usually when i either switch to the mIRC window from another window or change the active channel.

Memory related issue perhaps? I use the legacy fixedsys font... hmm.

Joined: Mar 2010
Posts: 57
W
Babel fish
Offline
Babel fish
W
Joined: Mar 2010
Posts: 57
Originally Posted By: Khaled
Thanks for the video, I can see that the vertical scollbar is changing size, however this is actually normal in some situations. It does not indicate that the number of lines has changed. mIRC calculates the size of the vertical scrollbar on-the-fly.

For example, if you resize the status window to the smallest possible size and fill it with several hundred lines and then maximize the status window, when you scroll up, the size of the vertical scrollbar will change.

As mentioned in a previous post, to see the actual number of lines, you would need to use the $line() identifier.

Since there are many possible situations where a buffer can get cleared, eg. a script, parting and rejoining a channel, and so on, I am not sure how easy it would be for me to reproduce this or to even monitor for it. One possible approach would be to use a script that, once a second, counts the number of lines in every window, outputs the count to a debug file, and alerts you if the number of lines has suddenly decreased.


Hey Khaled, after running a custom script to compare $line() with the actual amount of lines that should be printed, I found out that the buffer does not get cleared but rather doesn't grow, sometimes it decreases a little. On some channels for example it remains at 701 lines consistently for days. The number of lines seems to go down a little and then increase in no clear pattern.

Additionally, the scrollbar actually reports the correct "expected" buffer size as if the lines were added.

Note that the tests were done on two blank, freshly installed mIRCs on two separate machines. (No other scripts, dlls, /parts, or /clear[all] calls)

Here are a few samples: (Note that the lines are indeed consecutive)

Quote:
Format:

network : #channel <$line()count>/<expected count> : event : $nick : $1-


freenode : ##c : 1674/2000 : join :
freenode : ##c : 1675/2001 : text :
freenode : ##c : 1676/2002 : text :
freenode : ##c : 1675/2003 : join :
freenode : ##c : 1675/2004 : text :
freenode : ##c : 1676/2005 : text :
freenode : ##c : 1675/2006 : text :
freenode : ##c : 1675/2007 : quit :


freenode : ##c++ : 872/2195 : join :
freenode : ##c++ : 873/2196 : join :
freenode : ##c++ : 872/2197 : text :
freenode : ##c++ : 873/2198 : text :
...
freenode : ##c++ : 872/2305 : text :
...
freenode : ##c++ : 913/3405 : text :
freenode : ##c++ : 912/3406 : text :
freenode : ##c++ : 912/3407 : text :

(I did remove $nick and $1- for convenience from here.)

This sort of behavior happens on every channel. On some more than other for no clear reason as far as I can see. Notice that the buffer size might go down a few lines and then increase again.

Last edited by Wiz126; 17/02/12 09:56 PM.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Without having the data to confirm this myself, I think the two posts above are enough to outright confirm the existence of this bug. I think a thank you to Steeeve is in order for writing such a useful script to track this down!

I guess the question now is, what the heck is going on to cause this?


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jan 2012
Posts: 10
M
mtakala Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Jan 2012
Posts: 10
Tried 7.23 beta; the bug still exists. Didn't do any comparative analysis on finding if the behavior is different in some way. At least pressing page up on a channel windows (with a lot of traffic) resized the vertical scroll bar as if it thought there was a lot of lines but just found that the amount of lines in the window was smaller than expected - just as in the video I posted.

Joined: Jan 2012
Posts: 10
M
mtakala Offline OP
Pikka bird
OP Offline
Pikka bird
M
Joined: Jan 2012
Posts: 10
Noticed the new stable version, 7.25, and installed it over the weekend.

Came home today; full screen mIRC which was set to show 2000 lines per window only had less lines than should fit in the window vertically, and chat had been active on that channel all day. I mean, that the window was only half full, with huge amount of empty space!

So, this is still not fixed.


Link Copied to Clipboard