MMS users: call for testing
-
Well there is always a next OTA
If you want to make sure your stuff is in, best is at the beginning of a cycle to drive this topic forward. We have reduced personnel these days, its easy that stuff slips...My languages: 🇦🇹 🇩🇪 🇬🇧 🇺🇸
-
@jezek Such your personal investment in the essential MMS reliability mechanism
is worth this very usefull nechanism be incorporating as soon as possible. -
-
@flohack said in MMS users: call for testing:
Well there is always a next OTA
If you want to make sure your stuff is in, best is at the beginning of a cycle to drive this topic forward. We have reduced personnel these days, its easy that stuff slips...OK, the OTA-20 cycle starts around these days. Where to push, to land the MMS patch in OTA-20? Thanks.
-
-
@flohack the initial issue ( amongst others ) is here:
https://github.com/ubports/ubuntu-touch/issues/17The top related PR is in messaging-app https://github.com/ubports/messaging-app/pull/260 and you can see other pre-required
PRs in the comment in the correct order.[Edit]:
Well the very first issue post is here https://bugs.launchpad.net/ubuntu/+source/messaging-app/+bug/1603957
I think you can add it to your tweet :)...
That time please thanks @jezek -
Hey everyone, I am confused at the state of this? In my Pixel 3a XL MMS is working if wifi is off and if NOT a group MMS. So this is good, but I don't remember if that is due to @fredldotme incorporating the fixes only for the P3a or if it is in "mainstream" UT Dev / RC / Stable?
I am wondering about the status of these patches first.
Then I would like to start at least looking at the issue of needing wifi to be OFF for MMS to work. My thought would be try and determine how we could "force" MMS to always use the cellular data connection and "ignore" wifi. For me this seems like a better beginning point than currently where MMS will fail if wifi is enabled. Would I look into ofono or nuntium or other for this? If anyone had a link to the existing issue report for this it is a good start. Pointers? I can also add this to a new thread if it is best.
-
@rik Yes, that is another story and better on another topic.
From what i understand, nuntium call lomiri-download-manager ( https://github.com/ubports/nuntium/blob/b182b1a4ff41910dd3d1a4b064df2f56505be923/mms/download.go#L34 )
see project https://gitlab.com/ubports/core/lomiri-download-manager
But i don't get where we can force using cellular data instead of wifi -
Why do we need cellular data instead of using any kind of internet connection (other SIM or wifi) for fetching the content of the MMS? Is there a special reason why?
In my case my main SIM-card does not have a mobile-data-volume, for this I have a second SIM-card in my E4.5. So I'm using only the second card for internet-connection or wifi at home. From this point of view it's not possible for me to receive a MMS.
If I remember it right, on my old Nokia's the was no need of a mobile-data-volume or a datapass. If there was an incoming MMS the phone build up a internet-connection only for downloading the content of the MMS and then stopped the connection. There was no payment needed for this kind of connection (AFAIR). -
@kristatos This is because the Multimedia Messaging Service protocol is processed by the operator via cellular data.
It is not possible to handle mms via WiFi currently on Ubuntu Touch without VoWiFi relay.
Maybe this will be the case in the future...(?)
-
@lduboeuf said in MMS users: call for testing:
@rik Yes, that is another story and better on another topic.
From what i understand, nuntium call lomiri-download-manager ( https://github.com/ubports/nuntium/blob/b182b1a4ff41910dd3d1a4b064df2f56505be923/mms/download.go#L34 )
see project https://gitlab.com/ubports/core/lomiri-download-manager
But i don't get where we can force using cellular data instead of wifiAlfred suggested I file an issue at the general Ubuntu Touch github repo until we sort out where exactly changes may be needed. I found this one already listed here: https://github.com/ubports/ubuntu-touch/issues/1753 so I think we can keep following the "need to turn wifi off for MMS to work bug there" but my ignorant thought was to somehow use iptables / routing rules somehow to force using the cellular data network interface? Not sure if possible at all.
About group MMS messages not working, I see an old issue related to the OPO there, not sure if I should add to it or start a new issue? OPO uses legacy canonical ofono etc that may not overlap with current halium 9 ports?? Here is the OPO issue for it: https://github.com/ubports/ubuntu-touch/issues/383
-
@rik said in MMS users: call for testing:
About group MMS messages not working, I see an old issue related to the OPO there, not sure if I should add to it or start a new issue? OPO uses legacy canonical ofono etc that may not overlap with current halium 9 ports?? Here is the OPO issue for it: https://github.com/ubports/ubuntu-touch/issues/383
Yes MMS group has never worked well on UT according to ticket report. Don't forget to thumb up or add a comment in the issue report.
MMS is a feature that most core developers don't use, so hard to find a motivated developer.. -
-
@emphrath All the details of how to find what is new and needs testing can be found here https://ubports.com/blog/ubports-news-1/post/ubuntu-touch-ota-20-call-for-testing-3789
-
@emphrath Unfortunately, no. Ubports Team are very busy atm, and that big feature would take quite a lot of their time. Lets give another chance for OTA-21. I live with all that PRs since 8 months now without big trouble. I don't receive/send MMS often. But with @jezek feature, when i receive a notification of an incoming MMS, i don't ask others to please send it again...
-
@lduboeuf said in MMS users: call for testing:
sudo ubports-qa install PR_nuntium_8
sudo ubports-qa install telepathy-ofono 20
sudo ubports-qa install history-service 35
sudo ubports-qa install telephony-service 20
sudo ubports-qa install messaging-app 260
And rebootIs it always that ? Can i do the procedure on OTA-19 ? I have an OTA-19 already patched for an other MMS issue
-
On my Redmi Note 7 when I have cellular data on, some MMS come normally, and some in no longer time than 24 hours via SMS from the operator informing me to log in on the website to download MMS. It is frutrating enough, that usually I keep internet data off so the useless battery drain is not that big. I wonder if the script provided here coul help with that
-
@bluefroggie said in MMS users: call for testing:
I wonder if the script provided here coul help with that
That's kind of exactly what this messaging app fix is about.
-
@domubpkm yes the procedure doesn't change
-
Hello. The whole MMS redownload fix stack (nuntium, telepathy-ofono, history-service, messaging-app, telephony-service) has been merged. So I made a test if everything is alright.
My phone was on RC channel, so I installed stable version and then RC version again to be sure the whole image is reinstalled and not only incremental updates.
Then I used the
nuntium-inject-pushtool to inject an MMS message that produces a download error, to test if the error is propagated to messaging-app and the message can be re-downloaded. The test failed, cause in mesaging-app there was no re-download button, only the error message that tells you need to ask the sender to send again.After some logs reading and some experimenting, I found out that I needed to run only the
sudo ubports-qa install telepathy-ofono 20command (and then reboot) to be able to re-download erroneous MMS messages. After that everything works as intended.I don't know why there is the need to downgrade (that's what the QA script tells me) the
telepathy-ofonopackage. The PR was merged, so if thetelepathy-ofonolibraries are compiled from the repository, everything should work automatically after upgrade.Can enyone confirm (or deny) my findings? Does anyone know what could cause this? Or am I doing something wrong?
Thanks.
Note: If anyone wants to test this and is struggling how to, cause my report here is incomprehensible, don't hesitate to write me, I'll try write step-by-step instructions.
