Comment 4 for bug 1235138

After some more testing, I noticed that I can reproduce the bug whenever the phone loses coverage. If you start ubuntu-download-manager in that situation, QNetworkInfo (class from library libQt5SystemInfo.so) sends 20 GetModems message each 2 seconds to ofonod via D-Bus. The explanation is as follows:

1.- QNetworkInfoPrivate::onTimeout() is called each 2 seconds

2.- onTimeout() calls QNetworkInfoPrivate::getCurrentNetworkMode(), where QNetworkInfoPrivate::networkStatus() is called for different technologies.

3.- The calls related to the bug are for technologies LteMode, WcdmaMode, CdmaMode, GsmMode, TdscdmaMode: each one is called for the cases of HomeNetwork and Roaming: that makes 10 calls to networkStatus()

4.- networkStatus() calls to QNetworkInfoPrivate::getNetworkStatus(), which in the case of the mentioned technologies calls QOfonoWrapper::allModems() twice. That makes 20 calls to allModems(), which calls to QOfonoWrapper::getAllModems(), which finally makes the D-Bus call. Once we have the path to the modem (that's the data used from GetModems), QOfonoWrapper::networkStatus() is called.

That is certainly much more calls than needed. Modem data should be cached in QOfonoWrapper as is network status data, and wait for signals from ofono for changes. QOfonoWrapper::watchAllModems is set to false when radio is disconnected. Besides, we can half the number of calls to GetModem simply using the local variable "modems" in getNetworkStatus().

And the calls for different radio technologies/registration types also seems overkill, as those can be retrieved as properties from ofono interfaces. Even onTimeout() can be avoided if we wait for signals instead.

The code for the library is in package libqt5systeminfo5 in the case of Ubuntu Phone. The files containing the related code are qnetworkinfo_linux.cpp and qofonowrapper.cpp