qTox 🚀 - Messages are sent to me twice on some occasions

Happens to me also, running latest git version

ghost on 22 Dec 2015

Same.

ProMcTagonist on 23 Dec 2015

If the ACK is lost for any reason, the message is resent. Not much to do about it.

ElLamparto on 23 Dec 2015

If a message needs to be resent though can't it send some information with it that tells the qTox client that it has been resent, and then if the qTox client registers that there is another exact duplicate message already being displayed, and this is an automatic resend, and not what the user has requested, then just not to display the duplicate message?

ghost on 23 Dec 2015

You should discuss this in toxcore repo.

agilob on 23 Dec 2015

I have filed a bug report on this here.

ghost on 23 Dec 2015

People keep saying this is a toxcore issue and it is an extension thereof, but I believe qtox is "worse than others" at sending double messages. All of my friends that have qtox occassionally send me duplicate messages. Whereas I (using miranda NG) and some of my uTox friends NEVER send me duplicate messages.

There must be some kind of timeout in qtox that tries to resend a message if an ack(?) is not received within a given timeframe. I would recommend extending this timeout to at least 15-20 seconds. It is somewhat annoying to keep getting duplicate messages from qTox users.

LittleVulpix on 22 Mar 2016

Though it may be something else, this may be completely failing here https://github.com/tux3/qTox/issues/3022.

ghost on 22 Mar 2016

(…) I believe qtox is "worse than others" at sending double messages. (…)

There must be some kind of timeout in qtox that tries to resend a message if an ack(?) is not received within a given timeframe. I would recommend extending this timeout to at least 15-20 seconds. It is somewhat annoying to keep getting duplicate messages from qTox users.

Right, there is timeout, and IIRC it's a bit short. Increasing it might prove helpful, even if it won't fix the underlying issue.

zetok on 22 Mar 2016

👍2

We need numbered messages in core. It's been talked about but probably not focused on because of new groups.

@zetok Do you know what the current timeout is? I agree it should be at least 15 seconds.

ProMcTagonist on 23 Mar 2016

@ProMcTagonist Um, from what I can see, timeout is currently 15s.

I'll make PR doubling it, or perhaps it should be 45s ?

zetok on 23 Mar 2016

Actually, I'm not sure if that's it. It's either of 2 values, and that would be either 2s, or 15s. Well, PR will need to be tested.
Eh, if only qTox code had actual comments :/

zetok on 23 Mar 2016

I don't know if the workaround has entered the "stable" 1.3.0 version but this happens every time there is a minor problem with a network packet and the message cannot therefore be immediately sent. I have received 3 times a group of 5 messages and a friend has received a message 6 times. If you cannot code it on your own, then please use an external library such as http://mqtt.org/.
This problem is one of the few (another would be https://github.com/tux3/qTox/issues/2820) that affect qTox any configuration on any OS. Another similarly to them is that nothing seems to be done about it. Can we trust qTox at all?

ddobrev on 14 Apr 2016

I use qTox 24/24, 7/7 and message repetition happens almost never.
Freezing video on Linux (regression!) is the real problem.

ElLamparto on 14 Apr 2016

I haven't shut qTox, except to apply upgrades, for a long time. I'm on Linux and I get message repetition every few days.

ProMcTagonist on 14 Apr 2016

This is still happening even on the latest qtox. None of the other clients ever send me duplicate messages, just qtox. After restarting qtox, issue is usually gone but I dunno if it's because of any bugs in qtox. I think it's gone because of fresh connections being made/remade...

Usually the duplicate arrives within 10 seconds, but I had one case where it took 30 seconds.
I can say however that I no longer get triplicate messages, which is an improvement..

Assume A is using qtox 1.4.1 latest version available for the updater.

See two actual examples below:

A, 17.05.2016 09:36:07:
??

A, 09:36:10:
??

and one more

Vulpix, 17.05.2016 09:36:27:
respond with "bla" once when you see this

A, 09:36:35:
bla

A, 09:36:40:
bla

and one more where the time is actually 30 seconds...

A, 17.05.2016 17:08:44:
is that a rhetorical question?

Vulpix, 17:09:11:
An actual one :p

A, 17:09:14:
is that a rhetorical question?

Here it's 30 seconds...

LittleVulpix on 17 May 2016

The same here, even with the version 1.4.1 nightly, this problem is not solveed, i receive from one of my friend 3 times the same messages, and all of 3 messages resend it constantly.

I'm on Linux, Netrunner KDE rolling release, and my friend on windows 7 x64. He has the same newest version of qTox.

it is maybe a windows only problem? With other friend and ID i have, no problems, but all of them are on Linux. Just with qTox on Windows it happens.

Getron on 2 Jun 2016

All of my friends where this issue occurs are also on linux. It also still happens but if I had to say, it happens less often.

LittleVulpix on 2 Jun 2016

Fellows, no amount of tinkering with the time-out is going to help with this one. It can only be fixed properly in toxcore so I suggest we all write our comments to https://github.com/irungentoo/toxcore/issues/1486 instead, the maintainers might fix it faster if they see significant interest.

ddobrev on 2 Jun 2016

Fellows, no amount of tinkering with the time-out is going to help with this one. It can only be fixed properly in toxcore so I suggest we all write our comments to irungentoo/toxcore#1486 instead, the maintainers might fix it faster if they see significant interest.

Um, since I want it done faster, I don't comment there – i.e. given the attitude of toxcore maintainer, me commenting there would very likely have effect opposite to the desired one.

zetok on 2 Jun 2016

I see. Well, I guess you know him better even though that issue is half a year old. I left my own comment nevertheless.

ddobrev on 2 Jun 2016

Fellows, no amount of tinkering with the time-out is going to help with this one. It can only be fixed properly in toxcore so I suggest we all write our comments to irungentoo/toxcore#1486 instead, the maintainers might fix it faster if they see significant interest.

It's weird though. I don't get this with any other client (uTox nor Miranda). Not once. It's always just qTox.

LittleVulpix on 2 Jun 2016

I think, i have what the problem is.

No matter windows or linux, it is problem that qTox is able to start twice, 2 instances, or more. And, if there is a 2 instance, then, i think, it is hapend that messages sent itself twice.

Maybe we can set that the qTox not able to start 2 or more instances at a time.

For example, i have set that qTox start with system, on startup. Then, on my KDE Linux, i have set to have an icon on the taskbar. The qTox is started at startup, but, if i click on taskbar icon, it start another instance of qTox (and it is maybe just one instance of Tox core) and here is the problem.

Today, i have looked at PC from my friend over NoMachine, and he has 2 instances started (he doesn't known about this), klicked on the taskbar icon on windows, and voila, 2 instances on background started, and the messages send 2-3 times. I have closed the both instances of qTox on machine from my friend, and qTox is working now like it should be.

Thats my opinnion, what here the problem can be. If started once, not starting one instance more, no matter from where, task icons, all programs on windows, or Menu on Linux - Just one instance overall on one system! Nobody needs 2 instances. Or, maybe, if somebody need this, should be an option to enable starting more than one instance.

Getron on 2 Jun 2016

@Getron more than one running instance might help with reproducing, or you have perhaps found a separate problem, but a single instance is definitely enough for this issue to occur. I always run a single instance and I have got the problem tens of times, so obviously have @LittleVulpix and the others.

ddobrev on 2 Jun 2016

Yeah, the 2 instance thing isn't a prerequisite - but it should definitely contribute, because the main requirement is for a message ack to not arrive in time. This generally happens when the connection is bad - and if you start two tox instances, you have ~1600 "udp connections" (yes yes I know, udp doesn't make connections... but it does! they stay in router's NAT table for ~100 seconds) and that could make some routers or slower connections choke, which in turn causes the aforementioned behavior.

So no, it's not caused by two instances; it's caused by bad link between the two parties talking - but two instances will cause a strain on your internet connection, so it's an accidental "contribution" to the problem.

But in my case, to confirm, only one qtox instance is running on my friends' / parents' computers (at least in my parents' case I know this 100% )

LittleVulpix on 2 Jun 2016

@zetok could you please see https://github.com/irungentoo/toxcore/issues/1486#issuecomment-223391214 ? It says that the problem is not in toxcore at all, and furthermore, that another client, uTox, handles messages properly. Can the qTox team reuse their implementation or at least the idea behind it in order to fix this bug?

ddobrev on 2 Jun 2016

@zetok the maintainers of toxcore have closed https://github.com/irungentoo/toxcore/issues/1486 as invalid, they say handling messages is up to the clients, not to the core.

ddobrev on 3 Jun 2016

Probable cause of problem:

[23:29:41] <zetok> tux3: I think that I found where problem is with qTox's sending duplicate messages
[23:29:57] <zetok> tux3: to reproduce you just need to repeatedly send messages
[23:30:05] <zetok> repeatedly, and quickly
[23:31:14] <zetok> i.e. qTox either doesn't save all sent message's ID, or doesn't send back all IDs of received messages, but only "latest" one
[23:31:49] <tux3> zetok, it's possible the read receipt code is fucked, last I checked it was during the database upgrade and it was a complete mess
[23:33:10] <zetok> no wonder that it's a qTox-only problem :F

messages

zetok on 5 Jun 2016

👍1

@zetok excellent news. I hope this is indeed the cause. In such a case would you have any idea in what time we should expect a fix?

ddobrev on 5 Jun 2016

👍1

@ddobrev when someone will fix it.

zetok on 5 Jun 2016

Fellows, now that it's clear it's your problem and not the toxcore developers', and that you have a reference implementation in uTox, and that you have pretty much found the cause, and that this was reported half a year ago, and that this affects users on any operating system with any configuration, and that the problem is just a little order of magnitude more important than updating translations and documentation which make up the overwhelming majority of your recent git log, do you intend to fix it at all?

ddobrev on 18 Jun 2016

👍2

(…) and that you have a reference implementation in uTox (…)

Last time I've checked µTox didn't even support the functionality. Did that change?

zetok on 18 Jun 2016

@zetok actually it did -> https://github.com/GrayHatter/uTox/pull/295

LittleVulpix on 18 Jun 2016

@zetok https://github.com/tux3/qTox/issues/2726#issuecomment-199784308 suggests and https://github.com/irungentoo/toxcore/issues/1486#issuecomment-223391214 outright states that uTox does not have this bug. Both comments are linked in the discussion above.

ddobrev on 18 Jun 2016

@LittleVulpix I see, thanks.

@ddobrev Right, I thought that µTox doesn't have the bug since it simply ~~has~~ had no functionality that could cause the bug.

Btw,

(…) and that the problem is just a little order of magnitude more important than updating translations and documentation which make up the overwhelming majority of your recent git log (…)

Are you unhappy about people improving qTox? The way I see it, message resending problem is _way less important_ than having qTox localized into $languages. The bug is just a minor inconvenience that happens ~rarely enough to ignore it if you don't have OCD, while no translation for $language is generally a showstopper for most of people who didn't learn English as their first language, or don't know English at all.

(…) do you intend to fix it at all?

Does that question lead somewhere? Are you offering perhaps help with it by volunteering to write the fix, since other people seem to have plenty on their plates already? If that's the case, please do so, _help wanted_ :)

You might want to look at the status of the issue – it says Open.

zetok on 18 Jun 2016

You know that when minor inconveniences occur constantly, they become major, right? I've had this on average twice a day EVERY DAY. Well, as you can tell by my comments, I have been using qTox for 5 months now and let me tell you, having this occur regularly for such a long time is way past "minor". In other words, minor but regular inconveniences do not get ignored, they get stacked.
As for me helping, I said long ago in another issue that I would have if I could but, as you can tell by my profile, I develop my own open source and I cannot spare the time for a tool that I just use. Nevertheless, I keep bringing problems, both new and existing (in some cases for a long time), up in the hope the program will become better for everyone, including myself. So far the result has been 3 major problems, 2 of them universal (that is, causing trouble to all your users), fixed in 5 months. You tell me if it's been worth my time. But you did add the OS X automatic builds so I still haven't given up on you. I hope it won't be in vain.

ddobrev on 19 Jun 2016

So it's happening on uTox as well now! :D https://github.com/uTox/uTox/issues/368

LittleVulpix on 20 Jun 2016

😄1

Wait, you were getting it ×10 with qTox?

zetok on 20 Jun 2016

@zetok Nah, my friend was just sarcastic.. like "better than getting kicked in the nuts" kinda thing.

LittleVulpix on 20 Jun 2016

Ok. Because you see, I have this feel that my last try to make it less common could have had the opposite effect – so anyone interested might see whether with https://github.com/tux3/qTox/pull/3316/commits/a77afca1ec8f86cda68fe7ba853f7e4d854c346f applied / reverted they're getting less / more of duplicated.

zetok on 20 Jun 2016

Most of my friends are on 1.3.0 because of https://github.com/tux3/qTox/issues/3362 and they refuse to update until the problem is fixed.

LittleVulpix on 20 Jun 2016

This issue isn't happening with uTox. These are different issues entirely.

Also, just to clear up a few misconceptions: messages numbering from toxcore wouldn't fix this issue either. Trying to resend a packet at in interval >30s is stupid, should be easy enough to guess why.

Does qTox batch read writes to the message queue database? If so, why?

Does qTox lock the database while the client is open? If not, why not?

GrayHatter on 21 Jun 2016

if the linked problem of uTox is unrelated, this means its implementation of message queues is healthy. In such a case how difficult is it to reuse it in qTox? This problem has been present for more than enough.

ddobrev on 27 Jun 2016

It suprises me. I send and receive tons of messages (often long ones), one of my contacts is on VPN, and I get repetitions almost never. Sometimes I get a contact online/offline many times (what is annoing), but no repetitions.

ElLamparto on 7 Jul 2016

After another glorious month of translation updates, shouldn't this bug at last get a little attention?

ddobrev on 11 Jul 2016

Does one dare hope that after https://github.com/qTox/qTox/pull/3639 this annoying bug will finally be dealt with?

ddobrev on 30 Aug 2016

no it wont

GrayHatter on 31 Aug 2016

@GrayHatter I didn't have the chance to look into that code yet and currently there's enough workload to deal with in #3639 and #3524. If you tracked that down and probably know the reason. Would you mind to start fix it? As long as no UI is involved, this should not even conflict with any of current WIP.

antis81 on 31 Aug 2016

I can only confirm that it's still happening on the latest qtox.

LittleVulpix on 31 Aug 2016

Is there any chance the pull requests could be put off in favour of this bug? I think they shouldn't've been started to begin with given this and other bugs which regularly annoy the hell out of users, along with other bugs. Why didn't you fix the bugs first so that people can have a decent experience while you refactor the code?

ddobrev on 15 Sep 2016

This would be considered a high priority bug on uTox... Perhaps it's time
for a different client?

On Thu, Sep 15, 2016 at 11:30 AM, Dimitar Dobrev [email protected]
wrote:

Is there any chance the pull requests could be put off in favour of this
bug? I think they shouldn't've been started to begin with given this and
other bugs which regularly annoy the hell out of users, along with other
bugs. Why didn't you fix the bugs first so that people can have a decent
experience while you refactor the code?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/qTox/qTox/issues/2726#issuecomment-247411688, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAO20FQIV1a9kRa8jsanasKHPnOqcxBwks5qqY7igaJpZM4G575x
.

GrayHatter on 15 Sep 2016

@GrayHatter perhaps... it seems that bugs are not important to the qTox devs. Is uTox compatible with existing qTox profiles?

ddobrev on 15 Sep 2016

@GrayHatter have you fixed yet bug in µTox that causes whole xorg session to slow down when receiving messages? Seems like something that should have extremely high priority..

@ddobrev

Why didn't you fix the bugs first so that people can have a decent experience while you refactor the code?

You could ask @GrayHatter, he's the one who said that he has knowledge how to fix this bug and that fix could be made very quickly (5 min if memory serves well). Instead he chooses to act like an asshole, trying to promote crappy µTox at the cost of qTox.

The bugs are fixed by people who can reproduce them – in the last month or so I might have run into it like once.

Is there any chance the pull requests could be put off in favour of this bug?

How exactly not fixing other bugs would help fix this one?

zetok on 15 Sep 2016

@ddobrev It should be, unless qTox is doing something shifty...

@zetok I've still never been able to duplicate that bug. But I think I know more about how to fix it, so if you do ever find a way for me to duplicate it, let me know so I can take a crack at it.

And yeah, the fix for that bug is kinda obvious, I don't know how qTox works well enough to open a PR myself. So it wouldn't be 5 min for me. (I also probably shouldn't say 5 minutes either... I don't know how much code would need to be changed)

GrayHatter on 16 Sep 2016

@GrayHatter

And yeah, the fix for that bug is kinda obvious…

Uhm… what do you mean by that? Do you know, where the problem is? Could you provide some pseudo c++ code without internal qTox knowledge required to clarify that?

antis81 on 16 Sep 2016

relevant part from IRC:

[17:51:25] <grayhatter> first... delete this https://github.com/qTox/qTox/blob/master/src/persistence/offlinemsgengine.cpp#L38
[17:52:03] <grayhatter> then delete this
[17:52:04] <grayhatter> https://github.com/qTox/qTox/blob/master/src/persistence/offlinemsgengine.cpp#L102-L106
[17:52:32] <grayhatter> then take everything left here https://github.com/qTox/qTox/blob/master/src/persistence/offlinemsgengine.cpp#L93-L114
[17:52:39] <grayhatter> https://github.com/qTox/qTox/blob/master/src/core/corefile.cpp#L472
[17:52:43] <grayhatter> and put it here
[17:52:54] <grayhatter> that's how you fix the duplicate message bug in qTox
[17:53:13] <grayhatter> do you understand what I'm saying you should do?
[17:55:50] <grayhatter> rip uTox
[17:56:10] <sudden6> i'll look into it
[17:56:30] <grayhatter> do you understand my suggestion though?
[17:58:24] <sudden6> move offline message handling into connection status changed stuff?
[18:00:21] <grayhatter> correct
[18:00:32] <grayhatter> there's no reason to resend messages while the friend is still connected
[18:01:07] <grayhatter> toxcore promises every lossless packet you send will get there, or you'll get a connection dropped callback
[18:01:19] <grayhatter> then you just have to resend once the peer comes back online

zetok on 20 Sep 2016

@zetok @antis81 does the excerpt above contain enough information for the bug to be fixed? That is, shall we see any work on it any time soon?

ddobrev on 21 Sep 2016

does the excerpt above contain enough information for the bug to be fixed?…

It does and it gets even better. The PR #3639 further improves the situation, because unsent (!) messages are sent each time the chat opens (depending on the friend's online status) -> correct initialization.

…That is, shall we see any work on it any time soon?

I can provide the PR for the fix.

antis81 on 22 Sep 2016

@GrayHatter Thanks for the information via chat! Though corefile.cpp#L472 is the wrong place, but i get what you mean.

We provided initialization "incidentally" via #3639, as instead of creating every chat widget "dumb" on startup, we create it, when a chat is "activated" (a friend is selected). This in turn calls Friend::deliverOfflineMsgs() (not yet available in master), if the friend's status is anything but "offline". However, this is still WIP and some topics (especially group chats) are not finished yet (as what users would expect)…

antis81 on 22 Sep 2016

@antis81 thank you for the fix, I hope you'll have little trouble merging it.

ddobrev on 22 Sep 2016

Hello all. I'd like to once again ask you what's happening with this project and if it's ever going to be fully useful. This bug has not been fixed for a year. https://github.com/qTox/qTox/issues/2820 , https://github.com/qTox/qTox/issues/3158 and https://github.com/qTox/qTox/pull/2771 have all seen zero attention as well. The all mighty refactoring at https://github.com/qTox/qTox/tree/ui/redesign hasn't been touched in a month. I do believe it's about time you either fixed some of them or added a large bold text at the top of your README saying "this project is just our playground, if it so happens that it works for you, fine by us".

ddobrev on 24 Oct 2016

@ddobrev not quite in readme, but license states it quite clearly: https://github.com/qTox/qTox/blob/master/LICENSE

I've been thinking about adding a license badge on top of README.md, I'll make sure to do that right after #3793 gets merged.

zetok on 24 Oct 2016

@zetok, @ddobrev is just angry, that's all.

ElLamparto on 26 Oct 2016

Still see this issue built off tip at e606d3cb5573d956aa4df58fbe39a21b8c423860
Comes up when pasting large blocks of text that are split into multiple messages or when sending rapid messages back to back.

The long timeout before resend might actually make the problem worse for me since instead of just getting the same message twice, you get the message once and then again 2 minutes later, interrupting whatever you were talking about at the time.

anthonybilinski on 28 Aug 2017

Looked into this for a bit:
in ChatForm::SendMessageStr, core->sendAction is called, which sends the message and gives us the reciept. Then, profile->getHistory()->addNewMessage is called, which enques statements into the db to register the receipt, and some other stuff.

If your computer load is low, list of queues is small, and network latency is high, you then service the list of queues, add the receipt to the map, get the receipt back from your peer, and everything if fine.

If the load is high, list of queues is large, and network latency is low, you then might receive the receipt from your peer, which is silently discarded in OfflineMsgEngine::dischargeReceipt if not registered. You then service the list of commands, register the receipt, pend with a little spinny wheel forever, resend the message, get the ack, confuse your peer.

Changing History::addNewMessage from db->execLater to db->execNow fixes the problem completely for me. I can spam to my hearts content over LAN.

I'll test it tomorrow when I'm in person (currently remoting to a desktop) and can see how the blocking execute affects feel/responsiveness of the applciation, and prepare a PR.
I'll also remove a double handling of receipts (we currently try to remove each receipt twice, once from chatform registering receipts and once from nexus registering receipts), add a log when we receive a receipt not expected, and decrease our retry timeout from the time it is now (2 minutes) to something lower since I think it was only increased to as an attempt to fix this problem.

anthonybilinski on 30 Aug 2017

This does hurt responsiveness, if you spam like crazy while building or something, it locks up for a few seconds. In normal use it pauses for ~200ms after you send a message. This still seems a lot better for me, since I was getting double messages multiple times a day which confuses conversations, but a bigger refactor to record the IDs synchronously without a db access.

uTox doesn't have this even after enabling history which is off by default.

anthonybilinski on 30 Aug 2017

Fixed responsiveness, back to async, still safe https://github.com/qTox/qTox/issues/4608

anthonybilinski on 1 Sep 2017

Qtox: Messages are sent to me twice on some occasions

Most helpful comment

All 67 comments

Related issues