Missing messages on random channels

[codeurimpulsif]

I just create this issue in case someone fall in the same situation.

Issue

I use this plugin on a ZNC 1.8.2 running in Docker, it work without any issue.
But on another ZNC 1.8.2 running on Debian, it fail: if I'm connected on a client and then launch another client I can't see a lot of messages in the second one, I can see only my messages but not messages from other people on the same channel.

This issue occur only on some channels and I can't figure it out.
While multiples clients are connected they all get messages, but if a client is not connected and then connect it only see my user messages.

I install this plugin following the ZNC wiki page Multiple clients.

Example

On Client 1:

[18:23:58] <Me> This is a test
[18:24:21] <OtherUser> Is it working?
[18:24:38] <Me> I hope so
[18:24:51] <AnotherOne> keep fingers crossed

Then after this, I open Client 2 and only see:

[18:23:58] <Me> This is a test
[18:24:38] <Me> I hope so

[CyberShadow]

Sorry, I forgot about this issue.

Let's continue the discussion from IRC:

<CyberShadow> Codimp: Did you follow https://wiki.znc.in/Clientbuffer#Configuration ?
<Codimp> CyberShadow: yes I see this page, I enable the plugin on all my networks with the autoadd argument
<Codimp> and the listclients command return all my devices
<CyberShadow> The link is for the "Configuration" section (specifically I wanted to point at the paragraph mentioning AutoClearChanBuffer) but your browser window may be too tall to automatically scroll to it
<Codimp> Yes I disabled AutoClearChanBuffer and AutoClearQueryBuffer, I don't have the savebuff module but on the docker ZNC it work without it so I think I don't need it
<CyberShadow> Could you please double check that AutoClearChanBuffer is disabled on the installation where you're having the issue, as the symptoms you describe sound a lot like AutoClearChanBuffer being enabled
<Codimp> it's uncheck on my webadmin panel: https://home.lithio.fr/files/share/f.php?h=0AA4oeNS&p=1
<Codimp> I also check inside the ZNC conf file it is set to "false"
<CyberShadow> 👍
<CyberShadow> Codimp: If you disable ClientBuffer, does the problem where you're seeing only your messages go away?
<CyberShadow> (putting aside the per-client watermark functionality that ClientBuffer provides)
<Codimp> Yes
<Codimp> I know it's a strange issue ^^

Off the top of my head I can't think of anything that could cause this for sure, but here are a few things you could try to help narrow this down:

• Try to narrow down the difference between the two environments that are causing it to behave in one way in one environment an differently in the other. For example, what about ZNC 1.8.2 installed on Debian running in Docker? Are there any configuration files on the Debian machine which might affect this behavior?
• Are the two ZNC and ClientBuffer binaries built in the same way? (To exclude e.g. compiler misoptimizations)
• Are you connecting to the two instances with the same IRC client? (To exclude the possibility of e.g. the IRC client not supporting the message time extension)

[gennaios]

I’m also seeing such. Only on mobile devices. One thing that seems to often trigger it is if I post a message to some channel and then switch away to another app. Such is likely then auto-closed by iOS and perhaps acts like a force quit. Returning to the app sometime later, the channel history becomes completely blank though eventually it may fix itself.

I haven’t yet tried to track it down. ZNC 1.8.2 as provided by host provider. Plug-in compiled myself. Using Igloo client on iOS. If any other details would help.

[codeurimpulsif]

Trying to investigate this issue again, I still have it and now I'm using ZNC 1.8.2 everywhere but it don't work properly anywhere.

I have 3 ZNC 1.8.2 installations (two on Debian 11 on Raspberry Pi 4B and one in Docker). I have tested 4 IRC clients (Weechat, Revolution IRC, KVirc, Konversation). And still the same issues.

Is this module as been tested with ZNC 1.8.x? (I can see last commit on master branch is 2 years ago just after ZNC 1.8.0 was released)

[pezz]

Just wanted to chime in with a "me too" but my setup is much simpler.

Single znc instance on a server plus two desktops with Hexchat clients with different identifiers and I see the exact same thing as the reporter (my own chat is replayed but nobody else's).

All systems are Arch Linux running the same version of Hexchat and on the server, running:
znc 1.8.2-15
znc-clientbuffer 1.0.48-2

Cheers.

[glechapelain]

o/ o/

I am seeing this as well and I am pretty sure I narrowed it down. I was working off of znc#322. (I have put my finding there.)

I am thinking if we only update the timestamp upon receiving message from the client, then we would not lose messages.

Of course we might end up with duplicates. To that the best I could come up with is send a ping for each message sent to the client and clear when we get the pong.

Otherwise it does feel like the protocol itself is falling short.. :|

[glechapelain]

znc/znc#322 (comment)

[glechapelain]

Got znc-clientbuffer/pull/16 up,

I will be running with it a bit a report

[codeurimpulsif]

Thanks!

In facts I found a workaround which seems to work: Running ZNC with UTC Timezone, by setting TZ=UTC in environment variables when I launch it.

Now it seem my friends don't miss any messages anymore.

[CyberShadow]

Great find. All my systems use the UTC timezone; this would explain why I can't reproduce it.

[glechapelain]

Thank you! This does make more sense.

My change applies to when the connection simply dies-out without a proper /quit. So it will do to the mobile device switching app.

We were updating the timestamp on the buffer upon every message sent without knowing whether they made it to the other side.

To make the buffer update more I also removed the check for the type of messages the client sent before updating the timestamp (so we catch the pong as well.

With this change, I do now see the ***Playback complete*** message (which I did not before, but don't mind.) But more importantly I am not missing the messages sent when my computer or wifi goes to sleep.

(I could have put that in the change itself.)