Open samhed opened 4 years ago
This is a known bug, but pretty hard to fix in GSConnect. Since the message _id
field is not unique, we determine uniqueness by date
. The date
timestamp should be unique, but kdeconnect-android seems to send several versions of the same message with different timestamps:
[/service/device.js:_readLoop:361]: Galaxy S10: {
"id": 1600170925694,
"type": "kdeconnect.sms.messages",
"body": {
"messages": [
{
"addresses": [
{
"address": "+46707260865"
}
],
"body": "test send from phone ",
"date": 1600170925223, // <= 223ms
"type": 2,
"read": 1,
"thread_id": "830",
"_id": 15593,
"sub_id": 1,
"event": 1
}
],
"version": 2
}
}
[/service/device.js:_readLoop:361]: Galaxy S10: {
"id": 1600170925872,
"type": "kdeconnect.sms.messages",
"body": {
"messages": [
{
"addresses": [
{
"address": "+46707260865"
}
],
"body": "test send from phone ",
"date": 1600170925532, // <= 532ms
"type": 2,
"read": 1,
"thread_id": "830",
"_id": 15593,
"sub_id": 1,
"event": 1
}
],
"version": 2
}
}
It's possible this may be improved in an upcoming release of kdeconnect-android, but without some complicated heuristics I'm not sure how to deal with this one.
Thanks for your response. I understand.
Is it a known bug for the kdeconnect-android folks as well? Or should I report it somewhere?
Is it a known bug for the kdeconnect-android folks as well? Or should I report it somewhere?
I think I mentioned it once to the developers, but I've never opened a report for it.
Basically the Android app watches a content provider that triggers when a message is received (or something else). Android has several "boxes" (inbox, drafts, outbox, sent, etc), so my best guess is that when a message is "received" it's bouncing through a few "boxes" which is why we get sent several events for the same message at very close intervals.
@sredman or @aniket786 might know better if this is the case (if they have time to chime in :wink:). The reason this probably doesn't affect KDE Connect is that they don't really cache messages like we do.
If terminal notifications are enabled, then you will duplicate notifications. One notification will be from kdeconnect, the other notification will be from the terminal window that's running in the background.
This was the problem for me anyway.
If terminal notifications are enabled, then you will duplicate notifications.
This sounds like an unrelated bug to SMS. Probably you should open a separate issue for this.
If terminal notifications are enabled, then you will duplicate notifications.
This sounds like an unrelated bug to SMS. Probably you should open a separate issue for this.
I wouldn't call it a bug. Terminal notifications could be really useful for a lot things.
I would suggest the OP run down the list of desktop applications with notifications enabled and uncheck boxes to see if that's where the problem lays.
The bug he's reporting is unrelated to notifications. It's a known bug that results in duplicate SMS messages in the message cache when kdeconnect-android sends the same message twice with different timestamps.
having the same problem. Any news about it being reported and investigated yet?
Describe the bug
When I send a text message using my phone while connected to GSConnect, the text I sent appear twice in the GSConnect Messaging window. If I'm using GSConnect's Messaging to send the message, the message appears only once as expected.
Steps To Reproduce:
Expected behavior
I expect the messages to be displayed only once.
Screenshots
Support Log
System Details (please complete the following information):
GSConnect environment (if applicable):
Additional Notes: