This happened again yesterday. With GOOD network connection!!! But this
time I was able to fetch the log file using the command Matthias posted.
** Description changed:
+ When sending text messages, Ubuntu displays the loading spinner forever.
+ In the provider's monthly reports, I can see that
this is how the SMS could be monitored on sending to the modem, but only
online or short after the sending:
root@ubuntu-phablet:/home/phablet# /system/bin/logcat -b radio | tee
/tmp/radio.out
(btw: one should better use: /system/bin/logcat -b radio -v time
to get as well the timestamps)
...
What brings my attention here is that apparently the receiver is seeing
only one message (comment #7). It is possible that the receiver phone
detects receiving 2 messages that are exactly the same and shows only
one, but I would say that is not usual.
I would like to know if in some case the
@Alfonso: Thank you very much for your response. I really hope that this
will be fixed soon because I agree with your comment from the mailing
list that this is worrying.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
the AT chats can be monitored online from the ring buffers with:
$ sudo /system/bin/logcat -b radio
but this does not help to analyze weeks later what was going on :-(
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
Thank you for your reply, Matthias!
There is only one line in the database per message. Both rows have a
messageStatus of 4 which seems to be correct.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to telephony-service in
a) I sent one SMS every time.
b) Those were short enough to be sent as one SMS by the provider.
c) The receivers' phones are displaying only one SMS.
d) The MySQL database has only one entry both times.
For the first screenshot its timestamp is 2015-07-12T19:31:58.664
for the second one it
comparing the database timestamps and the provider times (from the
screenshots) we see:
databaseprovider
19:31:58.664 21:32:05 ... 21:32:45
11:31:17.015 13:31:21 ... 13:31:32
i.e. (ignoring the 2 hour diff due to TZ) it seems that the database
timestamp is made when the SMS is
Yes, after converting it to the right time zone (UTC+2) it becomes
21:31:58.664 21:32:05 ... 21:32:45
13:31:17.015 13:31:21 ... 13:31:32.
As I remember seeing the phone trying to send it for a relatively long
time on July 12th, it really seems as if there is some issue with
queueing the
The worst one.
** Attachment added: SMS.png
https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1480554/+attachment/4437379/+files/SMS.png
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to telephony-service in
Another one.
** Attachment added: SMS2.png
https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1480554/+attachment/4437380/+files/SMS2.png
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to telephony-service in
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: telephony-service (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to telephony-service in
Ubuntu.
What I do not fully understand is: AFAIK SMS is sent upstream to the
provider with AT cmds, like this example:
AT+CMGF=1
OK
AT+CMGS=+49170xx
CRThis is the text message.
+CMGS: 4711
OK
(+CMGF=1 is text mode, =1 PDU mode).
The response from the provider could be OK or ERROR. Have you
13 matches
Mail list logo
