MMS users: call for testing

domubpkm

@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 reboot

Is it always that ? Can i do the procedure on OTA-19 ? I have an OTA-19 already patched for an other MMS issue

BlueFroggie

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

Keneda

@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.

lduboeuf

@domubpkm yes the procedure doesn't change

jezek

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-push tool 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 20 command (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-ofono package. The PR was merged, so if the telepathy-ofono libraries 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.

flohack

@jezek Well that sounds bad. Everything should work in RC as expected, as everything was merged.

jezek

@flohack said in MMS users: call for testing:

@jezek Well that sounds bad. Everything should work in RC as expected, as everything was merged.

So I tested again.
Switched to stable.

phablet@ubuntu-phablet:~$ apt list | grep -P 'nuntium|telepathy-ofono|history-service|messaging-app|telephony-service'
history-service/now 0.3~0ubports4+0~20210526173549.20~1.gbp17c341 armhf [installed,local]
messaging-app/now 0.1.3~0ubports0+0~20210927064939.80~1.gbpdcb599 armhf [installed,local]
nuntium/now 1.4+ubports1+0~20210315192859.11~1.gbpb182b1 armhf [installed,local]
telepathy-ofono/now 0.3+ubports+0~20200930080735.3~1.gbpdb5e35 armhf [installed,local]
telepathy-ofono-ril-mc-plugin/now 0.3+ubports+0~20200930080735.3~1.gbpdb5e35 armhf [installed,local]
telephony-service/now 0.4+0ubports3+0~20210817080913.31~1.gbpaae257 armhf [installed,local]

Then switched to rc.

phablet@ubuntu-phablet:~$ apt list | grep -P 'nuntium|telepathy-ofono|history-service|messaging-app|telephony-service'
history-service/now 0.3~0ubports4+0~20211216130156.4~1.gbp88201f armhf [installed,local]
messaging-app/now 0.1.3~0ubports0+0~20211220103430.85~1.gbp654469 armhf [installed,local]
nuntium/now 1.4+ubports1+0~20211215170043.12~1.gbp054848 armhf [installed,local]
telepathy-ofono/now 0.3+ubports+0~20200930080735.3~1.gbpdb5e35 armhf [installed,local]
telepathy-ofono-ril-mc-plugin/now 0.3+ubports+0~20200930080735.3~1.gbpdb5e35 armhf [installed,local]
telephony-service/now 0.4+0ubports3+0~20211220103455.35~1.gbp61321e armhf [installed,local]

As you can see, the telepathy-ofono package didn't get updated to new build. It's still from year 2020.

lduboeuf

@jezek same for me on devel. Strange because i received a MMS notification without issue

jezek

@lduboeuf said in MMS users: call for testing:

@jezek same for me on devel. Strange because i received a MMS notification without issue

Remember the time when I thought, that the stack was merged (and was not), because after my RC update error notifications still worked? It turned out, that the incremental updates didn't reinstall packages after the ubports-qa script updates. I think this is your case too. It works because binaries after the ubports-qa script are not updated/downgraded when doing incremental update (original package was not changed, so no need to be in incremental update). Try to update system to stable and than back to devel and you should not receive error notifications (Edit: I mean, the ones with re-download button).

rik

@jezek Good explanation. I think you are right because at this time the devel and rc images both have the same package versions, so switching between them would not change those bits.

Previously when rc didn't have the new packages this technique of going between rc and devel would ensure you would get them installed when going to devel, but now as you note going to stable then to rc or devel is needed.

jezek

@lduboeuf @Flohack
I've been thinking, why the telepathy-ofono package didn't got updated. The last build (according to apt) was 2020-09-30. When I look at commits, that includes the sentdateempty MR. After this commit, no new builds of xenial branch are updated in debian packages. The next MR after this date are some debian/changelog changes. I remember we had troubles with debian packaging in nuntium, caused by my forgotten TODO in debian/changelog. I'm not really sure, but i think I read somewhere, that the debian/changelog updates are made automatically and not by hand by users. Could this be the case of this? Does anyone has more insights to debian packaging?

lduboeuf

@jezek this should be ok now. At least on devel telepathy-ofono has been updated

jezek

@lduboeuf said in MMS users: call for testing:

@jezek this should be ok now. At least on devel telepathy-ofono has been updated

Ahaaa, I see, they updated the changelog and bumped the version to take effect. I will test soon and tell results.

However, I wonder, why the other changelogs (nuntium, history-service, messaging-app, telephony-service) didn't needed to be updated?

This brings me to another question. Shouldn't the other changelogs (and the telepathy-ofono too) be updated with the description of changes, my credentials, version, etc... too? @lduboeuf , you are the maintainer of messaging app, what do you say to the debian/changelog changes in the app?

domubpkm

@jezek

.... and just a problem a few minutes ago. I can't download my image and I can't stop the wheel from spinning. Is it possible to stop the spinning wheel, to restart the download without deleting the MMS? Volla RC 45 of today. No problem in RC 44 redownload for me (Volla).

flohack

@domubpkm Also the button is called "Download" and not "redownload" @lduboeuf

flohack

@domubpkm Yeah probably the download attempt needs a timeout when it would become available again

Emphrath

On halium-devel (376) for bacon, at the moment mms seems to be broken. No notification whatsoever, while the former build gave me the standard mms error. So sth has changed, just not as intended it would seem

domubpkm

Confirmed, for me does not work/ no longer in RC.
For checking that :

I sent an MMS to myself after exiting the flight mode and reactivating my MMS settings : MMS received/works.
Then, I tried to download (redownload) the MMS of somebody and still this wheel turns endlessly...

But about

The download (redownload) works !

Best wishes 2022 to the whole UT UBports community

rik

@emphrath and @domubpkm have you confirmed your APN settings? With all the changes it is good to confirm those, there may have been something reset in them? I am re-installing RC now to check myself.

rik

@domubpkm @Emphrath I just re-tested and things seem to be working for me:

Reset to current "RC"
Re-configured APN entries
Wifi ON: sent a MMS photo to UT from Google Voice (Web)
Ooops message with download link received on UT
Turn OFF wifi on UT: wait 2 minutes, retried download. Successfully received picture.
Wifi ON: sent a MMS group photo to UT from Google Voice (Web)
Oooops message with download link received on UT to individual sender thread
Turned off wifi: wait 2 minutes, retried download. Not successful a few times (maybe was too fast), then tried again, and was successful in getting the group MMS photo (to a group already created in messaging app). NOTE that the "spinning download" button did NOT remove itself, but kept spinning even though the photo was downloaded. I think this is a bug but is somewhat understood because the group MMS "ooops" message comes to the individual sender thread, but the group MMS message when downloaded goes to the group thread so it is confused how to clean it up.

@domubpkm was your "spinning download" MMS by chance a group MMS?

So in summary, I do sometimes see the message not get received after 1 minute, but eventually by trying again (and again) it does come. I don't see any regression since the recent updates from a few days ago, this matches the experience I was seeing on "Devel" over the past weeks.

My specifications:
Pixel 3a XL
US Mobile (T-Mobile USA MVNO)
APN Settings:

Used For: Internet
Name: T-Mobile Internet
APN: epc.tmobile.com
<User Name and Password BLANK>

Used For: MMS
Name: US Mobile MMS
APN: pwg
MMSC: http://pwg.mmsmvno.com/mms/wapenc
<Proxy, Proxy Port, User Name, Password ALL BLANK>