New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some query lines sent again and again #6

Open
Jay2k1 opened this Issue Nov 17, 2015 · 16 comments

Comments

Projects
None yet
9 participants
@Jay2k1

Jay2k1 commented Nov 17, 2015

Two of my clients receive an old query message each time they are started, for example my mIRC:
screenshot
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

This comment has been minimized.

NeatNit commented Dec 27, 2015

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

@Jay2k1

This comment has been minimized.

Jay2k1 commented Dec 29, 2015

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

This comment has been minimized.

NeatNit commented Dec 29, 2015

I stop receiving the message after a few days though.

@andreagrandi

This comment has been minimized.

andreagrandi commented Feb 12, 2016

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

This comment has been minimized.

jb55 commented Feb 17, 2016

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

@Jay2k1

This comment has been minimized.

Jay2k1 commented Feb 25, 2016

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

This comment has been minimized.

loblik commented Mar 28, 2016

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 added a commit to CyberShadow/znc-clientbuffer that referenced this issue Apr 27, 2017

Don't send buffers to unknown clients
Whenever autoadd is not enabled and an unknown client connects to ZNC,
ZNC will proceed to indiscriminately send the contents of all buffers
to the client. However, this behaviour keeps repeating each time the
clients connects again: as this module is expected to be used with
AutoClearChanBuffer and AutoClearQueryBuffer both off, the buffers
aren't cleared, and ClientBuffer does not prevent ZNC from re-sending
the buffers on each client connect.

ClientBuffer should instead prevent ZNC from sending buffer contents
to unidentified clients.

Fixes jpnurmi#6.
@CyberShadow

This comment has been minimized.

CyberShadow commented Apr 27, 2017

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

This comment has been minimized.

CyberShadow commented Apr 27, 2017

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

This comment has been minimized.

blole commented Jul 22, 2017

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

@aphirst

This comment has been minimized.

aphirst commented Aug 26, 2017

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

@CyberShadow

This comment has been minimized.

CyberShadow commented Oct 8, 2017

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

This comment has been minimized.

arcnmx commented Oct 10, 2017

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

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

@CyberShadow

This comment has been minimized.

CyberShadow commented Oct 10, 2017

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

This comment has been minimized.

arcnmx commented Oct 10, 2017

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

This comment has been minimized.

aphirst commented Oct 16, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment