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.

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.

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

@opolork

...the old French inscription pour féliciter, or "P.F.", together with the number of an upcoming year, standing for "wishing you all the happiness in the new year".

https://en.wikipedia.org/wiki/New_Year_card

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

Hello.

In Q&A 143 you tried to answer my question a search was done, but after you forgot about it. The question was:

Hi, in some recent Q&A, there was a mention about Focal working on FP2. I've checked OTA updates on the phone (I'm on rc), but there is no update to Focal. When is it planned to roll out? Thanks.

The recent Q&A, I'm talking about in the question is Q&A 139 and the mention was:

Fairphone 2
Flo reported that Focal is at last working on FP2. It is still a very dated device and there will not be any stunning performance improvement. For those whose top concern is sustainability, it is however a great example of how the latest UT can run on ancient hardware. Thanks to Mohammed for persisting with this work. Nexus 5 may follow but that hardware really is showing its age.

Could you say more about focal on FP2, please?

Thanks.

@Timespansoul said in No MMS with Wifi ON:

Could you verify that it also works via Messaging app?

MessagingApp is basically just an app that reads/writes to a sqlite db. Everything about MMS (checking, downloading, storing into db) is done in background and is handled by more processes. So your question about Messaging app is kind of irrelevant. And yes, I used the Messaging app to see if the MMS message was successfully delivered.

I've already did some research and written somewhere about this already. If I recall correctly, I didn't find the cause, but narrowed it down to some package. Try to search this forum and/or gitlab/github.

Hello, I must oppose the claim that receiving MMS message is not possible while WiFi on is a global issue.

At least on FP2, which still runs xenial UT, I can receive MMS message, when WiFi on. Just tested it right now. Turned on WiFi & mobile data, telegramed someone to send me a MMS message and received the message without problem.

Hi, in some recent Q&A, there was a mention about Focal working on FP2. I've checked OTA updates on the phone (I'm on rc), but there is no update to Focal. When is it planned to roll out? Thanks.

Hello, in the blog, you write:

Fairphone 2

Flo reported that Focal is at last working on FP2. It is still a very dated device and there will not be any stunning performance improvement. For those whose top concern is sustainability, it is however a great example of how the latest UT can run on ancient hardware. Thanks to Mohammed for persisting with this work. Nexus 5 may follow but that hardware really is showing its age.

First, thanks for a wonderful information and to all that made that port possible.

My question is, how can I install it? Will it be like an OTA update, or do I need to install fresh using installer? Or something else?

@danfro said in tedit development and design discussion:

My only idea would be to constantly keep reading a copy and comparing that. But I don't think that would be good for performance and very reliable. So I am afraid there is not much I can do about it.

Pardon my intrusion.

Just a suggestion. You don't need to keep the whole text. You can make and store just a hash of the original text (before edited) and compare to a hash of current text (edited) at exit (to see if save is needed).

I don't know any malicious app in OpenStore, but...

Can OpenStore be hijacked like Snapstore with malicious apps, like in the SnapStore case with malicious bitcoin wallets?

They had to switch to manual review.
https://linuxiac.com/snap-store-now-requires-manual-review-for-the-apps/

From what I read/saw about the apps, they were all web-app like apps, that gave the (only) possibility to import a wallet and then sent all private data to attacker. Isn't this possible to do within a coffined app in Ubuntu Touch too?

The FP2 I own, has no focal port. In this post there was a claim, that it is possible to run focal on FP2, but no one told how. If there was an focal port, I would probably run it.

"...AppLee commented that he has never gone into flight mode by mistake."

To me it happened numerous times. Many times during calls I accidentally triggered flight mode with my ear. I figured it happened cause of proximity sensor not working, sometimes the phone boots and the sensor don't works. But even with working proximity sensor I happened to accidentally trigger flight mode (I'm more clumsy with my disability). It would be nice, if flight mode toggle (from the notification bar) would ask before turning on. But it is not critical.