sxiii / gtalksms

Automatically exported from code.google.com/p/gtalksms
0 stars 0 forks source link

Long delay in sending a reply or no reply at all, when the phone is locked. #29

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Reply to a sms within the client with the phone that has been locked due to 
inactivity.

What is the expected output? What do you see instead?
The expected output is that the client immediately (or at least within a 
minute) receives "Sending SMS to <contact>" notification in the chat window and 
the phone fires off the SMS to the contact. 

What I see instead is a delay. Sometimes more than a few minutes or so. When I 
receive an SMS, it has always been instantaneousness. My phone vibrates and I 
already have the SMS on my chat window. Whether the phone had its screen off or 
not, receiving SMS is instant.

However, when I send the SMS with a "cold" phone, a phone that is locked (not 
security lock) and the screen dark, it takes a few minutes at times or I give 
up and open up the phone to the homescreen. 

However, when I see that I'm not getting the "Sending sms to <contact>". I turn 
the screen on the phone and the SMS proceeds to send I receive the expected, 
SMS sent, SMS delivered. 

What version of the product are you using? On what operating system?
gtalksms: 1.6 (donate version). Phone: HTC Incredible 2.2. Desktop: Windows 7. 

Please provide any additional information below.
I've attached a screenshot that shows the timestamps. The first red circle 
shows how fast the Send SMS occured, while the 2nd circle did not send the SMS 
until I finally opened up the phone from its inactive state.

I can recreate this scenario pretty much every time.

Original issue reported on code.google.com by i.vita...@gmail.com on 5 Jan 2011 at 9:53

Attachments:

GoogleCodeExporter commented 8 years ago
Sorry, my title is wonky. Should be: 

Long delay in sending a reply when phone is locked.

Original comment by i.vita...@gmail.com on 5 Jan 2011 at 9:57

GoogleCodeExporter commented 8 years ago
Issue 30 has been merged into this issue.

Original comment by Florent....@gmail.com on 5 Jan 2011 at 11:01

GoogleCodeExporter commented 8 years ago
I think it's due to the xmpp protocol latency and battery preserving on idle 
state.

Original comment by Florent....@gmail.com on 5 Jan 2011 at 11:05

GoogleCodeExporter commented 8 years ago
It seems that it only delays on sending a SMS/replying to a SMS. All other 
commands happen near instantly. Receiving SMS is also instant. 

Out of curiosity, is xmpp protocol absent from those functions?

Original comment by i.vita...@gmail.com on 6 Jan 2011 at 8:01

GoogleCodeExporter commented 8 years ago
Weird, tonight I've sent about 200 SMS (to test sms conversation new feature) 
and indeed about 100 SMS take between 5 and 10s to be sent, others are 
instantly sent.

With the new implementation of GTalkSMS we use severals intents to process a 
single message, it's maybe a lead to this issue...

Original comment by Florent....@gmail.com on 6 Jan 2011 at 11:26

GoogleCodeExporter commented 8 years ago
FWIW, I too see gtalksms take quite some time to respond to commands when 
asleep - not quite a few minutes, but possibly up to 1 minute.  I've seen this 
forever - but can't reproduce it simply by pressing the power-button on the 
device.  I don't quite understand how sleep mode works on Android, but I 
suspect simply pressing that button so it *looks* asleep isn't quite the same 
as being truly asleep.

When I last saw this I grabbed the logs from the device and there is no 
evidence our process was killed - it just seemed slow to receive the request...

Original comment by skippy.hammond@gmail.com on 6 Jan 2011 at 11:44

GoogleCodeExporter commented 8 years ago
@florent - maybe add a log message to toe packet receiver in the xmppmanager - 
the logs might then help us work out if gtalksms is introducing the delay or 
the delay is before we are called.

Original comment by skippy.hammond@gmail.com on 7 Jan 2011 at 1:40