Version: 0.19+ #3119 svn (using KDE KDE 3.5.3) Installed from: Slackware Packages Compiler: gcc 3.4.6 OS: Linux If a very long message is sent to a channel it gets split up - but a part in the middle of the message is left out, for example if i send a message like "AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDDDDDDEEEEEEEEEEFFFFFFFFFFGGGGGGGGGGHHHHHHHHHHIIIIIIIIIIJJJJJJJJJJKKKKKKKKKKLLLLLLLLLLMMMMMMMMMMNNNNNNNNNNOOOOOOOOOOPPPPPPPPPPQQQQQQQQQQRRRRRRRRRRSSSSSSSSSSTTTTTTTTTTUUUUUUUUUUVVVVVVVVVVWWWWWWWWWWXXXXXXXXXXYYYYYYYYYYZZZZZZZZZZ[[[[[[[[[[\\\\\\\\\\]]]]]]]]]]^^^^^^^^^^__________``````````aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggggghhhhhhhhhhiiiiiiiiiijjjjjjjjjjkkkkkkkkkkllllllllllmmmmmmmmmmnnnnnnnnnnooooooooooppppppppppqqqqqqqqqqrrrrrrrrrrssssssssssttttttttttuuuuuuuuuuvvvvvvvvvvwwwwwwwwwwxxxxxxxxxxyyyyyyyyyyzzzzzzzzzz{{{{{{{{{{||||||||||}}}}}}}}}}~~~~~~~~~~" konvi shows in the rawlog (outgoing): [23:03:20] << PRIVMSG #/dev/brain :AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDDDDDDEEEEEEEEEEFFFFFFFFFFGGGGGGGGGGHHHHHHHHHHIIIIIIIIIIJJJJJJJJJJKKKKKKKKKKLLLLLLLLLLMMMMMMMMMMNNNNNNNNNNOOOOOOOOOOPPPPPPPPPPQQQQQQQQQQRRRRRRRRRRSSSSSSSSSSTTTTTTTTTTUUUUUUUUUUVVVVVVVVVVWWWWWWWWWWXXXXXXXXXXYYYYYYYYYYZZZZZZZZZZ[[[[[[[[[[\\\\\\\\\\]]]]]]]]]]^^^^^^^^^^__________``````````aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggggghhhhhhhhhhiiiiiiiiiijjjjjjjjjjkkkkkkkkkkllllllllllmmmmmmmmmmnnnnnnnnnnooooooooooppppppppppqqqqqqqPRIVMSG #/dev/brain :qqqrrrrrrrrrrssssssssssttttttttttuuuuuuuuuuvvvvvvvvvvwwwwwwwwwwxxxxxxxxxxyyyyyyyyyyzzzzzzzzzz{{{{{{{{{{||||||||||}}}}}}}}}}~~~~~~~~~~ the other user then recives an incorrect version: [23:03:20] >> :Wiedi!wiedi@p549C4E18.dip.t-dialin.net PRIVMSG #/dev/brain :AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDDDDDDEEEEEEEEEEFFFFFFFFFFGGGGGGGGGGHHHHHHHHHHIIIIIIIIIIJJJJJJJJJJKKKKKKKKKKLLLLLLLLLLMMMMMMMMMMNNNNNNNNNNOOOOOOOOOOPPPPPPPPPPQQQQQQQQQQRRRRRRRRRRSSSSSSSSSSTTTTTTTTTTUUUUUUUUUUVVVVVVVVVVWWWWWWWWWWXXXXXXXXXXYYYYYYYYYYZZZZZZZZZZ[[[[[[[[[[\\\\\\\\\\]]]]]]]]]]^^^^^^^^^^__________``````````aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggggghhhhhhhhhhiiiiiiiiiijjjjjjjjjjkkkkkkkkkkllllllllllmmmmmmmm [23:03:20] >> :Wiedi!wiedi@p549C4E18.dip.t-dialin.net PRIVMSG #/dev/brain :qqqrrrrrrrrrrssssssssssttttttttttuuuuuuuuuuvvvvvvvvvvwwwwwwwwwwxxxxxxxxxxyyyyyyyyyyzzzzzzzzzz{{{{{{{{{{||||||||||}}}}}}}}}}~~~~~~~~~~ as you can see something got lost. I think this is because a message (including protocol) on irc can't be more than 512 chars. Konvi does not violate this rule by splitting exactly at the point so that the outgoing message is 512 chars long. But the receiving message is longer (as it includes more protocol overhead) and so the ircd cuts off the last part. X-Chat cuts this message at 447 chars, together with protocol 468 chars. [23:17:22] >> :Test2!wiedi@p549C4E18.dip.t-dialin.net PRIVMSG #/dev/brain :AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDDDDDDEEEEEEEEEEFFFFFFFFFFGGGGGGGGGGHHHHHHHHHHIIIIIIIIIIJJJJJJJJJJKKKKKKKKKKLLLLLLLLLLMMMMMMMMMMNNNNNNNNNNOOOOOOOOOOPPPPPPPPPPQQQQQQQQQQRRRRRRRRRRSSSSSSSSSSTTTTTTTTTTUUUUUUUUUUVVVVVVVVVVWWWWWWWWWWXXXXXXXXXXYYYYYYYYYYZZZZZZZZZZ[[[[[[[[[[\\\\\\\\\\]]]]]]]]]]^^^^^^^^^^__________``````````aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggggghhhhhhhhhhiiiiiiiiiijjjjjjjjjjkkkkkkkkkkllllllllllmmmmmmm [23:17:22] >> :Test2!wiedi@p549C4E18.dip.t-dialin.net PRIVMSG #/dev/brain :mmmnnnnnnnnnnooooooooooppppppppppqqqqqqqqqqrrrrrrrrrrssssssssssttttttttttuuuuuuuuuuvvvvvvvvvvwwwwwwwwwwxxxxxxxxxxyyyyyyyyyyzzzzzzzzzz{{{{{{{{{{||||||||||}}}}}}}}}}~~~~~~~~~~ So it is received correctly. I did not test if this is just a magic number or if it gets calculated from the own hostmask + channel length. If you need some more information feel free to mail me ;-) Thanks
*** This bug has been marked as a duplicate of 131460 ***
(FWIW, this is not really about chars, but about bytes: The protocol imposes a 512 byte buffer length limit, so what needs to be done is calculate how the preamble will look like on the receiving, and how many bytes the actual message has, which is non-trivial due to encodings which use a variable number of bytes per character (e.g. Utf-8). We're working on it.)