Failed MMS redownload progress report:

This week only nuntium PR got updated.

There was a problem with redownload after nuntium got restarted. After nunium restarted (on crash, or phone reboot), the redownload button from messaging-app didn't work. This was because of the button sends the redownload request to nuntium through dbus. And after nuntium restart, there was no one listening on dbus for the redownload signal. I've fixed this by spawning listeners for messages on modem identification. So the redownload now works even after phone restart.

Also the nuntium-inject-pust testing tool got update. It can now autodetect the end-point flag from nuntium logs using grep & sed commands.

Failed MMS redownload progress report:

There are now 3 drafts on github:

• https://github.com/ubports/nuntium/pull/8
• https://github.com/ubports/telephony-service/pull/20
• https://github.com/ubports/messaging-app/pull/260

This is the first working version, where you can initiate re-download of failed MMS by clicking a button in messaging-app. This version is quirky and will be improved further.

What needs to be done?

• make it possible to report failed message using status, not an empty message.
• refactoring, tests, documentation, changelogs, etc...

Will report again on any noticable progress.

I the banner. Also kudos to everyone who participated and made this possible.

@krogoth I like @dobey 's answer. Cause it's not a simple 'no'. It is accompanied by some hints, how you can try to approach the problem, if you want to solve it. Keep going @dobey , excellent work.

Failed MMS redownload progress report:

Because of unsafe apt operations, which makes crossbuilder & ubports-qa unsafe too, I've redirected my attention to nuntium, resulting in some commits to https://github.com/ubports/nuntium/pull/8. (Note: I can easily deploy nuntuim to phone without apt)

What was done?

My operator (and other?) resends multimedia message notifications ever 10 minutes, if notification is not marked as received. This resulted in new error message (when download fails) and notification sound every time. These new commits prevents this behavior.

Every notification comes with transaction-id, which is stored on download error and if new notification comes with the same transaction-id and there was a download error again, the error message will not be sent to telepathy again.

The only caveat is, that if the second download fails on another error as the first, then the second error will not be communicated (however no error description is communicated now, this will be added in future). I'll see, if this will need attention later.

To test these changes easier, I've added an transaction-id flag to nuntium-inject-push testing tool.

That's all for this week, see ya next time.

Failed MMS re-download progress report:

The progress is slow, but steady. Two PR drafts got updated:

• https://github.com/ubports/telephony-service/pull/20
• https://github.com/ubports/messaging-app/pull/260

What was updated:

1. Some refactoring was done in telephony-service in redownloadMesage pathway (the function now needs 3 string parameters instead of a string map).
2. The redownload (in telephony-service) changes message status to pending before sending a redownload request to nuntium.
3. The redownload (in telephony-service) sends redownload request to nuntium only if message status is unknown (later it will be other status) to not request redownload more times than needed (if function is called more times)
4. Redownload buton gets disabled if message status is other than unknown (will be other status later), to indicate hat redowload is in progress.

Failed MMS re-download progress report:

Number of drafts on github is now 5:

• https://github.com/ubports/nuntium/pull/8 - saves info about failed download, adds error & delete-event parameters (if needed) into dbus message for thelepathy-ofono and incoming re-download request.
• https://github.com/ubports/telepathy-ofono/pull/20 - for received mms (from nuntium), parses additional parameters ("Error", "DeleteEvent") and sets Telepathy message headers accordingly ("x-ubports-error", "supersedes").
  The "supersedes" header indicates, that the current message replaces the one stored in the header and is currently handled by history-service without any change. (Note: during injection testing, history service fails to delete the supersedes message, if it is in another conversation)
  The "x-ubports-error" header should indicate an error message when message propagates through telepathy-qt to history-service. Maybe the error propagation could be done via "delivery-status", "delivery-error", "delivery-error-message" headers and no changes in history-service will be needed (theory needs testing).
• https://github.com/ubports/history-service/pull/35 - the code here does nothing new yet, just adds some logging. The idea is to change status if "x-ubports-error" is set. It's possible, that this PR will be unnecessary.
• https://github.com/ubports/telephony-service/pull/20 - adds methods to propagate re-download request to nuntium.
• https://github.com/ubports/messaging-app/pull/260 - adds re-download button to error message.

The redownload should work after these PRs. The new thing is, that after hitting redownload the old error message bubble should be deleted when the new message arrives (as successfully received message or new error message).

What needs to be done:

• improve error mms logic (currently: when delivered message is empty, without attachments). The idea is, that a delivered message is an error message when message is empty (historical reasons) or status is one of MessageStatusPermanentlyFailed, MessageStatusTemporaryFailed or MessageStatusPending. The message, which can be re-downloaded will have temporaryFailed status and will show the re-download button. Upon re-download clicked the state will be changed to pending (the re-download button is disabled). When re-download is not possible (expired, some other error) the status will be permanentlyFailed or empty message (current).
• set status in history-service (if needed)
• refactoring, tests, documentation, changelogs, etc...

I'm sorry, I'm so slow with progress, have only cca a hour a day for coding/testing. And building, deploying, phone restarting and log/code studying takes too much time. I hope it'll get faster.

@lduboeuf said in The MMS lost story:

How do you manage to propagate error or deferred status as Telepathy Message object to Telephony-service and History-service ?. By using the messageType , e.g: ChannelTextMessageTypeNotice ?

I'm afraid, that propagating via messageType (declaring new type) could break some other logic, which handles message type. So I decided to go with custom header "x-ubports-error". Or maybe using other headers (see above).

Questions, ideas or critics are welcome.

Edit: https://github.com/ubports/telepathy-ofono/pull/20 and https://github.com/ubports/history-service/pull/35 fail to pass checks. Does anyone know why?

Failed MMS redownload progress report:

I've fixed the issue I found last week, but haven't tested it fully yet (so no commits). I will continue the cleanup, to start review process and inform you here on any progress.

Failed MMS redownload progress report:

During cleanup I found a small issue. During nuntium initialization I start dbus listeners to listen to redownload or read/delete requests for messages in storage, but telepathy didn't spawn listeners for these. It's not a big issue, redownload still works, but read/delete requests from messaging-app don't come through to nuntium and that leads to polluted storage. I've tried to fix it, but today I broke something, so no new commits until I fix and test. I hope this is the last issue, that needs to be solved before reviews starts.

Failed MMS redownload progress report:

This week nuntium and messaging-app pull request drafts got update. @lduboeuf added code to messaging-app to not be able to initiate redownload of expired messages. And I fixed a bug in nuntium, wich I previously introduced. I've also made more work on nuntium localy, got rid of some TODOs, but I haven't fully tested the added code yet, so I'm not confident to push into PR draft right now. Will continue to work on this, see ya next time.

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

@capsia said in New Devices Page Now Online:

@jezek Good! Can you make a pull request at https://gitlab.com/ubports/infrastructure/devices.ubuntu-touch.io/-/merge_requests to change that?

Done.

@capsia said in New Devices Page Now Online:

@jezek Good! Can you make a pull request at https://gitlab.com/ubports/infrastructure/devices.ubuntu-touch.io/-/merge_requests to change that?

Change that into what? Working, or partialy working? For me it's working (halium 5.1), but there is the not closed issue, so maybe for somebody (on halium 7.1) it is not working. How could we figure out? Mak an "Is here someone with FP2 with battery life less than 24 hours" thread?

And I would like to bring attention to fairphone 2 device page. There is a statement that "Battery lifetime > 24h from 100%" is not working. But I've shown in the linked github issue, that the battery lasts more than 24 hours. So I think, that the battery lifetime statement should be changed.

Hello,

after yesterdays update to 0.17.3 the Notes app crashes, when trying to sync with Evernote account. This means, when network is available, it crashes on startup.

Does anybody experience the same problem?

Note: I'm on FP2 with latest RC (2021-W37).

So I red the OTA-19 call for testing and after browsing though the github QA page I have come to the conclusion, that I've been definitely wrong about the patch landing in RC and maybe in OTA-19 update. I'm sorry for putting your (and my) hopes up. Maybe next time.

Does anyone know how to be in the next OTA update?

@lduboeuf Or am I wrong? Is there a possibility that the patch is not in RC (and dev) and the applied ubports-qa changes persisted 2 RC upgrades and I drew a bad conclusion? Can anyone answer this conundrum, or do I have to do full reinstall to check?

I've discovered, that the patches are already in RC, so if you are on RC channel (and dev channel too), there is no need to apply the above mentioned ubports-qa commands. This also means that the patches will probably be in the next OTA. Just saying. I'm happy. Thank you all.

I've been wrong. Read furher, why.

@lduboeuf said in MMS users: call for testing:

For the use case "cellular data off", it is working nicely except when i'm with bad signal ( see issue above ) .
This is already a huge step for MMS users, in its worst case scenario we will have the same state as it is today on Devel/RC/Stable ( just ask user to resend)

I think it is not a showstopper for deploying to next OTA. It's working better than before and there are no regressions. Also it will motivate me more to fix the bad signal issues, when the changes land to stable. I will definitely tackle the issues, but I had to change my HW and installed manjaro on it and now I have a little fight with crossbuilder and the lack of apt and dpkg[-architecture,-parsechangelog] commands on the system.

Thank you all for support.

I needed to test something on halium-devel on FP2, so while I switched to version 161 I made some observations. As mentioned in this thread before, automatic brightness, flaslight and camera-app are not working. Screen rotation (accelerometer) doesn't work too. Calls & messaging are working as expected, but the irritating loud beeping when the other person hangs the call is still there. I can't use the phone as daily driver like this, going back to halium 5.1 (rc).

@Flohack As @TobsEnd claimed, there is a lineageOS for FP2, so it would make more sense to skip the 7.1 and go for 9 instead. The Waydroid project, which works on halium 9 looks very promising.