Forums Bug Reports [v7.68.1100] Batch or znc.in/playback

Upon upgrading to v7.68.1100 I was met with dozens of old messages (from/to myself), which were processed by my open/text scripts. It was not very nice for all those new browser tabs to open and begin beeping.

These old messages are now received every time connecting to the server.

I am using znc, query buffer size is set to 50 and 'Auto Clear Query Buffer' is unchecked. I do not know if these are the default values or values I set years ago. Or even if these are relevant to the feature in question.

So now I've got to upgrade all my scripts or muck around with my znc settings?

Thanks for your bug report. I am afraid I have little experience with ZNC, so I cannot say why this would happen. The beta has simply added support for IRCv3 echo-message. The support for echo-message is an IRCv3 server-side setting that causes the server to echo messages back to confirm delivery of sent messages.

From what I understand, it can also be used to replace the ZNC self-message feature and can be used by the znc.in/playback feature?

That said, znc.in/playback appears to have been superceeded by IRCv3 "chathistory". Most clients from this point onwards are supporting IRCv3 as a standard instead of ZNC-specific features, so this may require changes to scripts.


Is this a setting that you have enabled in ZNC? To send mIRC a chat history on connect? How is this working in v7.68? Are you using a script to parse these messages in v7.68?

Are you using a self-message script like the one mentioned on the ZNC Query Buffers page that links to this self-message script page?

Update: I have just tested v7.68 and v7.68.1100 with ZNC and its query buffer feature. In v7.68, ZNC only plays back messages you received from others. In v7.68.1100, with echo-message enabled, ZNC also plays back messages that you sent. That is what you are seeing, which means that you would need to update your script to handle those messages as well.

This is the same issue as when users first tried to use ZNC with the self-message and playback features - you needed to use a script to correctly handle the custom ZNC messages.

Update2: I tested again using a beta that enables support for parsing ZNC self/playback messages into appropriate windows. This is code that I decided -not- to include in the v7.68.1100 as I was concerned it would interfere with existing ZNC scripts but as ZNC is doing its own thing here with echo-message, I thought I would test out the code. The code specifically changes how mIRC handles PRIVMSGs that have your nick as the source and a different nick/channel as the target. A client should normally not receive these types of messages. However, some services, eg. ZNC, can send them. In my beta, mIRC will now display these as if sent by your nick in the appropriate query/channel window.

Unfortunately, it's not that simple.

The PRIVMSG parsing routine handles at least ten different PRIVMSG contexts, and supports many features, eg. updating the IAL, triggering notify, resetting idle time, playing sounds, speaking text, triggering script events, flood protection, CTCPs, ignoring lines, stripping control codes, updating tab history, etc.

The playback buffer that ZNC sends to mIRC on connect includes messages that you have already received as well as messages that you have not yet received.

The messages that you have already received have previously triggered all kinds of events. But since you are now receiving them again, they are triggering those same events again.

The message you have not yet received are triggering events as expected.

As mentioned in various places on self-message / znc.in/playback / chathistory documentation, a client needs to remember the timestamp of the last message it received in order to know the difference between messages it has already received and new incoming messages, so that the client can handle these differently. This means mIRC would need to save the timestamp of the last message received for every query/channel and to process messages arriving after this timestamp as new messages, and messages before this timestamp as old, already-received messages.

It's also not clear whether messages with your nick as source and a different nick/channel as target should trigger the above events, since these are technically messages that you have already sent to someone else.

I also use znc and I'm using beta version 7.68.1100 and I don't see any problems.

Okay, messages are received from myself which previously were not. The new behavior was extra confusing to me that these kept appearing every time I connected - but this was because of my scripts (or rather - the script needed to do more). I was already sending a clearbuffer message to znc every time I received a message. This took care of the playback from other users. But when I received these messages from myself, I processed them as expected but did not issue a clearbuffer (because I had not needed to in the past). So I'll issue that command now and that'll be fine.

The only other problem then is receiving back messages I *send* which I believe is what you're referring to in your edits and the other filed report(s). Sending messages to myself means that the scripts process on the first received message and also on the echoed copy of sending it. Duplicated messages also appear in the playback, if you handle that separately.

When echo-message is enabled, mIRC will filter out echoed messages, so scripts should never see them, unless they are using on PARSELINE.

In the next beta, I will be adding an on PARSELINE identitifer $parseem that is set to $true if mIRC thinks the incoming line is an echoed message.

Using beta 1159

I am messaging myself to communicate between different mIRC instances. All messages are sent from Client A. $parseem is always false on Client B.

Messaging myself on Client A - two of the same message are received on Client B and processed twice by text events.

Messaging another user on Client A - my sent message appears on Client B as being sent from myself (in a query window for myself and not for the other user). $nick == $me for this text event.

Thanks for your bug report. I have not been able to reproduce any issues so far with how echo-message or $parseem are working.

Here are the steps that I followed to try to reproduce your issue:

1) Install a clean copy of mIRC using portable mode to the documents folder with no scripts or addons.
2) Run this copy of mIRC.
3) Connect to the server using /server irc.snoonet.org:+6697 -i nick1
4) Connect to the server using /server -m irc.snoonet.org:+6697 -i nick2
5) Open two debug windows for both status windows
6) Open a query window from nick1 to nick2
7) Open a query window from nick2 to nick1
8) Send a message from nick1 to nick2

When I follow the above steps on Snoonet, I see:

1) nick1 sends one message to nick2.
2) nick2 receives one message, $parseem is $false, and should be since nick2 is only receiving a message.
3) nick1 receives an echo and $parseem is $true for the echo, $false for all other events.

If you follow the above steps, are you able to reproduce the issue?

Your recommended steps do not capture what's going on with this bug. It's necessary to be using ZNC for this to make any sense. The echoed message is received by all clients connected to ZNC, not just the client that sent the message.





Client A and Client B are both connected through ZNC with nick Membear.

Client A sends message to other nick "mem2". Both Client A and Client B receive the echo for this sent message. In Client B this opens a query window for its own nick Membear, it's supposed to be in a window for "mem2". A remote text event is triggered for this message, which I dislike because it's an echo of an outgoing message not a real incoming message. In this case at least you can check if the message was an echo because it lists the address of the sending nick and the string of the nick it was sent to.

Messaging yourself makes this even worse



Client A receives both the incoming and echoed message, and processes one of them as a remote event.



Client B receives both the incoming and echoed message and processed both of them as remote events.

In this case the address of the sending nick and the nick it was sent to are the same, so it doesn't appear to be possible to detect if one of these messages was an echo. This feature just doesn't seem compatible with ZNC.

https://imgur.com/a/J3UTBEV

Additionally, the specs appears to call out this use case:
https://ircv3.net/specs/extensions/echo-message.html
https://ircv3.net/specs/extensions/labeled-response


"There are also additional complications for self-targeted private messages."

"When a client sends a message to itself, the server MUST NOT include the label tag, except for any acknowledgment sent with the echo-message mechanism. This allows clients to differentiate between the echoed message response, and the delivered message."

My general hope is that by providing a step by step example, the person reporting the bug will reciprocate with a step by step method that reproduces their issue :-)

Reading through your post: it sounds like you are using one copy of mIRC with two status windows, are connecting both status windows to ZNC using the same nickname, and ZNC in both cases is connecting to the target server using the same nickname and presumably virtualizing the second connection, since you can't connect to the same server twice with the same nickname.

Here are the new set of steps that I followed to try to reproduce your issue:

1) Install a clean copy of mIRC beta 1159 using portable mode to the documents folder with no scripts or addons.
2) Run this copy of mIRC.
3) Connect to the server using /server zncaddress:port zncnick:zncpw
4) Connect to the server using /server -m zncaddress:port zncnick:zncpw
5) Open two debug windows for both status windows
6) In status window 1, open a query window from zncnick to zncnick
7) In status window 2, open a query window from zncnick to zncnick
8) In status window 1, send a message in the query window

When I follow the above steps, I see this:

In the status window 1 connection:
a) The client sends one message
b) It then receives the message it sent to itself
c) and it receives an echo of the message

So far so good. This is what should happen.

In the status window 2 connection:
a) The client receives the message that was sent by the status window 1 connection
b) and it receives an echo of the message

(to clarify, the messages are being played back to the status window 2 connection)

As far as I can see, this is wrong. ZNC should not be sending an echo to the status window 2 connection, since that is an independent connection that has no idea about how many messages were sent by the status window 1 connection.

It looks like ZNC is treating both connections as the same connection, but that is not the case. There are two independent client connections, both of which maintain different internal states based on how they interact with the server.

Thanks, this case is already handled on ircds that implement support for echo-message without labeled-response.

However, as mentioned in my above post, ZNC does not seem to be doing the right thing here.

Even if labeled-response was enabled, this would still be an issue, because it is the sending client that is maintaining internal states and tracking outgoing messages.

That said, with labeled-response, a client could just filter out echoed messages by label. But even with labels, mIRC is currently being more deliberate - it is assigning an internal identifier to associated displayed lines and sent lines, storing nickname count used in the /msg or /notice, and using the identifier as the label (if labeled-response is available), and then tracking incoming messages, so it will only filter out echoed messages that it is expecting.

The spec suggests ZNC should be sending the echo to all clients, "In this scenario, when users send messages from one client, the messages get automatically relayed to other attached clients. This allows all attached clients to display full conversation." This makes sense for conversations with other users, and I believe that echo should not trigger text events. It does make a little less sense for conversations with yourself though.

And although echo-message says it addresses self-targeted message limitations in the labeled-response doc, I do not see that addressed and I still do not understand how mIRC could differentiate between sent message and its echo.

I literally cannot remember if I responded again yet but...

If the self-messages cannot be solved even with label-response or some other means, the echoed messages with other users can at least be identified - the message contains both your own address and the nick of the other person so it can be filtered in that way. Or is that what you were trying to avoid, not stepping on scripts which already deal with that? I suppose they would have to trigger *some* script if the user wanted to change the style of those messages.

So if these use cases can't/won't be solved - can the echo-message support be disabled? And will it be disabled by default?

The spec says that the echo should be sent to the client that sent the message.

In the above example, the status window 1 client sent the message. The status window 2 client has no idea about what messages were sent by the status window 1 client.

ZNC is then forwarding the message that the status window 1 client sent to the status window 2 client, which is a different client that has its own server connection states.


It works correctly when used on a standard ircd that supports echo-message with or without labeled-response. I explained how mIRC does this in my previous post.

That said, reading my example again, I was looking for your issue and I think misread what was happening.


Actually, this looks right. ZNC is forwarding what it thinks the status window 1 client is seeing to the status window 2 client.

If you message yourself in the status window 1 query window, you will receive your message and an echo of that message. The echo message is filtered out. In the query window itself, you will see the message that you sent and the message that you received, ie. two messages.

The status window 2 client then receives two messages: the message that should be displayed as if it was sent and the message that was received, ie. two messages.

So we are now back to the issue of how a script should handle these messages. Without echo-message, a script is needed to display ZNC self-messages in the correct windows. With echo-message, this has become slightly more complicated because the echoed message has to be handled by the script as well.

If this isn't the issue you are seeing, I really would need a numbered, step by step example, that reproduces your issue exactly.

I did somewhat follow the original instructions, except that I connected through znc, used two instances of mIRC instead of one, and used /msg from the status window. I provided this video earlier, it got compressed though so here's a better one: https://giant.gfycat.com/AngelicSelfreliantHammerkop.mp4

But I guess this problem of duplicated text events when targeting yourself is just a specific case of the more general problem that all echoes (to yourself, or other users, or channels) trigger text events at all.

To reiterate the issues when using ZNC with more than one attached client:

1. All echoed queries to other users show up in a query window for $me/$nick instead of a query window for $target.
2. All echoed messages (to any channel or to any user) are now triggering text events.
a. Echoes to other users *can* be distinguished by checking for a difference in $nick and $target
b. Echoes to yourself *cannot* be distinguished from a real message (except by checking that echo-message is enabled then ignoring every other received message, but this sounds fragile)

Problem 2 seems to me rather insurmountable. Users may have scripts which never took into account the possibility of being triggered by their selves and could take some unwanted action. On the other hand, some scripts may want to apply custom formatting to these messages.

So I really don't know what else to say here or suggest, except that no matter what is implemented I hope I can disable the feature as I'm sure it will disrupt my current setup.

Okay, thanks for feedback and testing.

Re-reading the above posts again, I am still not entirely sure if ZNC is relaying messages or playing them back to the status window 2 connection. If ZNC is relaying messages, it should not be sending echoes to the status window 2 connection, since the status window 2 connection has no idea about which messages were sent and is therefore not expecting echoes. If ZNC is playing back messages to the status window 2 connection, so that it shows the same channel/query window contents as the status window 1 connection, then the behaviour seems fine.

At the end of the day, all mIRC can do is implement the IRCv3 spec for echo-message in a way that works on ircds that support it.

In the case of ZNC, its implementation of features like playback/self-message/etc. have resulted in behaviours that aren't quite standard, which is what we may be seeing with its echo-message support currently.

Am I understanding correctly that you are connected to one (and the same) ZNC user with >= 2 (m)IRC (different) clients? Would implementing CyberShadow's clientbuffer solve the problems you are having?

Using this module enables ZNC to keep track of separate buffers (one for each client connecting to it). You would have to setup the client id's, for example mirc-home and mirc-work then you can connect with: zncuser@mirc-home/network:password and zncuser@mirc-work/network:password. I'm assuming you have the route_replies module installed as well? (This page has more information: https://wiki.znc.in/Multiple_clients)

These two scenarios are exactly the same to me. How do you think they are different?

The echo-message spec has considerations specifically for bouncers, and ZNC is doing exactly what the spec says it should: sending echo-messages to all connected clients.

With that in mind, is mIRC adhering to this?

I explained this in my post.


Yes, this is not the issue.

Am I correct in thinking that for the latest beta you have

1. Corrected the target window of incoming echo-messages
2. Prevented these messages from triggering text events

This is pretty good, but means that the message will be left in znc's playback buffer when "Auto Clear Chan Buffer" or "Auto Clear Query Buffer" znc flags have been disabled. These require a "clearbuffer" message be sent; without an event to capture these messages to send the clearbuffer, all sent messages are replayed on every reconnection. PARSELINE can probably be used to handle these incoming messages, but that seems wasteful.

Disabling the CAP from the CONNECT event was too late and the playback buffer was still sent, but capturing the RAW event was soon enough to prevent it. So barring any other complications, this is probably what I'll be going with.