MMS users: call for testing
-
I've tried the new RC v133 upgrade (switched to stable and than RC) and now the (re)download works.
@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-pushgave 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 commandinitctl --user restart nuntium). After that the mms testing tool worked and mms notification and (re)download too. -
@jezek Thank you, you confirm that there is a problem. For your temporary solution thank you again but it's a bit of gibberish for me so I'll wait
-
@flohack said in MMS users: call for testing:
@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
-
@jezek I'll try your nuntium workaround tomorrow if the last devel update doesn't fix it. Thanks for the tip
-
L Lakotaubp referenced this topic on 2 Jan 2022, 14:25
-
@jezek well after installing the 377 update, I tested again and failed. So i tried ur workaround. The command informs me that nuntium is a running process with such PID... But I want to restart it don't I ??? A sudo before that command gives me an error: upstart is not set in this environment and therefore the command cannot locate the upstart instance... Can I test again or did the command fail ?
-
-
@jezek said in MMS users: call for testing:
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 -
@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.
-
@domubpkm said in MMS users: call for testing:
@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 -
@lduboeuf Maybe/probably. After my failures, I immediately asked someone to send them back to me and I received them.