Phone abandons incoming call

[Matthew Exon]

I just received five incoming calls but I couldn't answer any of them. In each case the phone started vibrating, then after a while the ring tone started and the answer buttons were displayed, but before I had a chance to answer, the phone seemed to give up and go back to sleep. Then I could see the green envelope meaning that I had missed a call.

The fifth time was me trying from another phone. In this case it seemed that the line was still ringing, but again I was unable to answer the call.

After rebooting the phone, I can now answer incoming calls no problem. So it seems this is some bad state that the phone gets into after a while.

I've previously had problems with my phone's cover blocking the light sensor and preventing me answering calls. However in this case I was expecting the call and had prepared by opening the cover, so this can't be the problem.

Phone is an MX4. OS Ubuntu 15.04 (OTA-10.1).

FYI, this was a job interview, with a CTO who was phoning from New York. I'd already had to delay a week after missing the first appointment due to the exact same problem. I've been barely tolerating Ubuntu Phone's bugs up to now, but this is the final straw.

[Ren (ubuntech)]

Ok with you Matthew. It is sometimes difficult to answer
a call. The ring may be short, low sound or the touch screen does
not want to take a phone communication for a reason
difficult to know.
I hope that my comment will help. Thanks.

[Matthew Exon (ubuntubugs-mexon)]

"The ring may be short"

I phoned my phone from a spare phone. The Ubuntu phone showed it was ringing for about 1 second, then stopped ringing and displayed a missed call. Meanwhile my spare phone was still playing a ring tone and waiting for a connection. This matches what other people reported for the other missed calls, they hung on the line for a very long time. The ringing was definitely not short.

"low sound"

I was expecting this call and had carefully turned the volume up to maximum. I also opened the case so as not to trigger the light sensor.

"the touch screen does not want to take a phone communication for a reason difficult to know"

I did not touch the touchscreen. It only displayed itself as ringing for a second, it did not have time to dim the screen and I did not have time to answer.

But besides that: if my phone randomly decides it doesn't want to answer an incoming call, for a reason that is difficult to know, then it's really not much use as a phone is it?

[Pat McGowan (pat-mcgowan)]

@Matthew very sorry this happened
Was this the only time it occurred?
If it can be reproduced we may want to get some additional logging
Any idea if you had been running certain apps prior to the occurrence, anything that may be related?

Can you also attach the media-hub.log file from .cache/upstart from the same time if its still there

[Pat McGowan (pat-mcgowan)]

@alfonso and tiago any ideas to debug?

[Tiago Salem Herrmann (tiagosh)]

Could you also attach .cache/upstart/dbus.log? And if you are able to reproduce it easily, it would be good to also grab two additional logs using the following steps:

connect the device in development mode via usb in your desktop and run:

1) adb shell dbus-monitor > call_dbus-session.log
2) in another terminal run: adb shell dbus-monitor --system > call_dbus-system.log
3) receive a call and reproduce the bug
4) attach both call_dbus-session.log and call_dbus-system.log to the bug report.

thank you.

[Matthew Exon (ubuntubugs-mexon)]

Was this the only time this occurred? As I said in the original report, it also happened a week previously when the same person in New York tried to phone me. I don't have logs from that time, but there was certainly a reboot in between. Apart from that, I believe I have seen this before but I can't be sure. Those would have been local calls and I would simply have called the person back. But my SIM card doesn't allow international outgoing calls so that wasn't an option in the New York cases.

"Certain apps": I typically use gallery, dekko, terminal (which is set to never be terminated using tweakgeek), browser, camera, settings, contacts, messaging, phone, so those were probably "running" (although apart from terminal probably terminated by the OS). I was not using any of them immediately prior to taking the call: I was expecting the call and it was important, so all I did with the phone was check that it was alive, running smoothly, and that the volume was turned up.

I attached two media hub log files. Since they don't include datestamps I couldn't be sure which covers the period of the calls. It's almost certainly the 2 Jun one though. The DBus log file I'm pretty sure is right.

Note that this phone has been switched off for a week. I encountered the problems. Then I made a test call. This failed, so I tried rebooting the phone. After that a test call worked. At that point I decided this phone was too unreliable to use and I switched to my iPhone, which I've been using since. After that it wasn't switched on again until just now.

I can't use adb shell over USB. As many people have been reporting with MX4s, the USB port is too unreliable to use for more than a few seconds at a time. This is another reason I've concluded this phone is more trouble than it's worth. Please suggest an alternative. I can ssh into the phone no problems.

I've put a different SIM card in the phone and I'll leave it running for a while. Right now I can phone it no problem, consistent with me finding that it temporarily fixes itself with a reboot. The software version is the same as it was, and I will avoid upgrading anything to minimise the variables. I'll try phoning again after a few days and report back with the status. However it's not really a comparable environment. As my main phone it travels with me, connects to various wifi and cellular networks. Also, I frequently turn on and off wifi, bluetooth, and airplane mode as a work-around to other bugs. And the camera frequently mysteriously freezes so I have to terminate that. Sitting on my desk doing nothing, I wouldn't be surprised if it works fine.

Bear in mind that "this problem disappears after I upgrade to a newer version" isn't really a happy ending to this story. I need to be reliably contactable, I can't take risks there. If critical bugs are creeping into a feature so fundamental to the purpose of a phone then there's a problem with Ubuntu's development process, regardless of this particular bug. If you guys can show me how it was my mistake, or of my carrier, or even of Meizu, then that's different, but at the moment I consider Ubuntu Touch too unstable to use.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

syslog traces show calls are all are > 15 secs:

Jun 2 09:32:29 ubuntu-phablet powerd[762]: incoming call
Jun 2 09:33:04 ubuntu-phablet powerd[762]: call removed

Jun 2 09:33:09 ubuntu-phablet powerd[762]: incoming call
Jun 2 09:33:33 ubuntu-phablet powerd[762]: call removed

Jun 2 09:33:37 ubuntu-phablet powerd[762]: incoming call
Jun 2 09:34:10 ubuntu-phablet powerd[762]: call removed

Jun 2 09:40:36 ubuntu-phablet powerd[762]: incoming call
Jun 2 09:41:33 ubuntu-phablet powerd[762]: call removed

Jun 2 09:48:14 ubuntu-phablet powerd[762]: incoming call
Jun 2 09:48:31 ubuntu-phablet powerd[762]: call removed

This implies the issue lives somewhere in the services that handle the notifications to the user. The traces that Tiago suggests to take would help here.

[Tiago Salem Herrmann (tiagosh)]

Thanks for the logs,
could you also grab the dbus logs using the steps I provided on comment #6 using adb?

[Tiago Salem Herrmann (tiagosh)]

sorry, I just read your comment where you say you're not able to use adb.
Can you access the phone over ssh somehow?

[Tiago Salem Herrmann (tiagosh)]

you just need to ssh the device and run the same commands:

$ dbus-monitor > call_dbus-session.log
$ dbus-monitor --system > call_dbus-system.log

then attach the files to the bug report.
Thank you.

[Tiago Salem Herrmann (tiagosh)]

I am seeing timeout from the approver while trying to create an instance of media-hub in the dbus.log file.

Media-hub is a telepathy observer (it watches telepathy to stop music when there is an incoming call), and telepathy by design won't forward the incoming call to the approver (to display the snap decision) until all observers confirm receiving the incoming channel first.

If media-hub is really stuck for some reason, that would explain the issue, since after a dbus timeout trying to deliver the channel to media-hub, telepathy would still try to deliver the channel to the approver, which would make the snap decision appear, and quickly disappear (since the incoming call is already gone).

This is a guess, but seems to match what Matthew described, and what I see in the logs:

-----

virtual QMediaService* AalServicePlugin::create(const QString&)
"org.qt-project.qt.mediaplayer"
Failed to start a new media-hub player session:
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible
causes include: the remote application did not send a reply, the
message bus security policy blocked the reply, the reply timeout
expired, or the network connection was broken.
Failed to create a new media player backend. Video playback will not function.

Could not finish contructing new AalMediaPlayerService instance since
m_hubPlayerSession is NULL

----

[Matthew Exon (ubuntubugs-mexon)]

Is there some way to force media-hub to get stuck in this way? Or even better, perhaps write a test application that observes telepathy and deliberately fails to confirm. Then I could check that the results are the same as what I was seeing.

"telepathy by design won't forward the incoming call to the approver ... until all observers confirm receiving the incoming channel"

This means that a rogue application can block incoming calls by simply observing telepathy? That doesn't seem like a good design. In particular, media-hub is a very complicated piece of engineering with innumerable dependencies on other software and the wider network, and whose requirements are constantly in flux. Answering phone calls is so important, media hub should be treated as if it was actively malicious rather than depended on for cooperation.

That said though, in my case I did see the approver (I assume that means the green/red slider answer call widget), and there was one ring, which sounds like it could rule out your guess.

Anyway, thanks very much for your investigations!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.