@jezek On Volla RC test OTA-22, after reactivating the disabled cellular data (not flight mode), I was unable to download two MMS: endless spinning wheel.

I wrote a bug report here, but can also be a different cause for your case:
https://github.com/ubports/nuntium/issues/18

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

telepathy-ofono had a bad last changelog version number which makes CI not increment the correct version digit i guess.

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?

IMO yes core services should have the debian changelog updated , but i never know what version digit to update.
But not sure for messaging-app because it has not been updated since long time ago.
IDK what would be the best practice.
I would say that it should be the maintainer responsability

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

Yes, i think we should keep "Dowload" and modify the text before, but next OTA i guess

@domubpkm I know about the occasional problem with the spinning download button. The problem is, that sometime nuntium crashes (& restarts) due to some race condition (that was already there when I first touched the code). Also, when there are problems with mobile signal & re-connection after flight mode, such troubles may occur. And I also have forgot to check the dbus result, when attempting message (re)download. That's why it sometime misbehaves.

For now, if you want to get rid of the pending state, you'd have to edit the message database by hand and change the state back to temporary error state.

Next week I will try to get a detailed look at it.

@emphrath said in MMS users: call for testing:

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

I've tried halium-devel on FP2. The tool for testing MMS messages nuntium-inject-push gave me an error, when I tried to push an message, cause it didn't found dbus addres in nuntium logs. I checked and in there were no logs for nuntium added, which is weird, because there should be. So I restarted nuntium (using command initctl --user restart nuntium). After that the mms testing tool worked and mms notification and (re)download too.

• 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>

• 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

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

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

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

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