Some query lines sent again and again

[Jay2k1]

Two of my clients receive an old query message each time they are started, for example my mIRC:

It's always the last line received of a conversation, but it doesn't happen with every query. Unfortunately I couldn't track it down more.
I am using znc 1.6.0.

[NeatNit]

+1 - although worth noting, Jay2k1 is hosting my bouncer as well.

[Jay2k1]

I was able to track this down a bit more.

Upon connecting to znc, a client will receive the last line of every past query. If it was an incoming message, all clients will pop up a query window and show it. If it was an outgoing message though, only those clients who understand this will do it (which rules out mIRC). So I am assuming for queries the start index is off by one or something.

[NeatNit]

I stop receiving the message after a few days though.

[andreagrandi]

Hi! I'm using ZNC 1.6.2 and latest ClientBuffer (I installed everything yesterday!). Everything works as expected for channels, but in query dialogs I also receive the same message everytime I reconnect. Please note that at the moment I'm only connected from the same client (Textual on Mac), but I can try from another PC (Linux using XChat) if you want.

[jb55]

@andreagrandi yup I'm getting the same thing with weechat.

[Jay2k1]

It seems you can do /msg *status clearbuffer <name of query> for every affected query window as a workaround, but that doesn't stop the problem from happening with new queries. I believe the bug is somewhere here https://github.com/jpnurmi/znc-clientbuffer/blob/master/clientbuffer.cpp#L279-L304

[loblik]

I think there is no easy solution for repeating/missing lines without extending cmodule API. The API seems to not provide callback for sent messages with the same timestamps which are used in replay buffer callbacks. That's probably why clientbuffer uses it's own timestamps and that can be cause of trouble I think. Another issue could be the conversion from timeval to double and then back. But I think the main problem is there is currently no way how to identify which messages were already sent to client.

[CyberShadow]

Hi,

I noticed that ZNC 1.7 adds some new module APIs:

• OnChanBufferPlayMessage (deprecates OnChanBufferPlayLine2)
• OnPrivBufferPlayMessage (deprecates OnPrivBufferPlayLine2)
• OnUserRawMessage (deprecates OnUserRaw)

These new APIs provide a CMessage, which makes a timestamp available through the GetTime function.

I think using these should eliminate the problem described in this issue.

[CyberShadow]

Implemented ZNC 1.7 support in my fork here:

https://github.com/CyberShadow/znc-clientbuffer/commits/master

Seems to work perfectly according to my testing.

If you use ZNC 1.7, you could give it a try.

[blole]

Yes, I'm running your fork now and it seems to work.

[aphirst]

Are there plans to integrate this functionality here, or should I just use @CyberShadow 's fork "until further notice"?

[CyberShadow]

With #znc's blessing, my fork is now the project's main repository (as @jpnurmi hasn't been maintaining this one), so feel free to close this :) Please file an issue there if you run into any problems with it.

[arcnmx]

Hm is this still an issue with the fork on 1.6?

Also @CyberShadow you need to enable Issues on your repo.

[CyberShadow]

Hm is this still an issue with the fork on 1.6?

Yes, 1.6 doesn't provide the necessary information to implement this correctly.

Also @CyberShadow you need to enable Issues on your repo.

Thanks for the reminder (GitHub disables issues on forks by default).

[arcnmx]

That's annoying, I had a fork of my own to fix that issue but I've been waiting over a year for 1.7 to hit a stable release... More waiting then!

[aphirst]

I've resorted to running znc-git until there's a real 1.7 release. It all seems stable enough, to be fair.