• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
UBports Robot Logo UBports Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

The MMS lost story

Scheduled Pinned Locked Moved OS
133 Posts 16 Posters 54.9k Views 6 Watching
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • L Offline
      lduboeuf @jezek
      last edited by 18 Jan 2021, 22:07

      @jezek Qt5.12 is devel ready since few hours, you can start update and continue to play with ubports-qa & crossbuilder.

      For the notification being resent by the provider, this is not the case for me at least.

      Thanks again for your implications

      1 Reply Last reply Reply Quote 0
      • J Offline
        jezek
        last edited by 24 Jan 2021, 22:19

        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.

        jEzEk

        J 1 Reply Last reply 31 Jan 2021, 21:05 Reply Quote 5
        • K Offline
          Keneda
          last edited by 25 Jan 2021, 12:54

          What a massive work done on this thread, @lduboeuf @jezek the masters of MMS :beaming_face_with_smiling_eyes:

          Hope for the work ready for OTA16, but no rush here, take the time you need.

          2015-2023 : Meizu MX4 ☠️⚰️✝️
          2023-2024 : Nexus 5 ☠️⚰️✝️
          2024-***** : FPOS Fairphone 5 waiting UT for freedom 😉
          🇲🇫🇬🇧

          L 1 Reply Last reply 25 Jan 2021, 13:39 Reply Quote 1
          • L Offline
            lduboeuf @Keneda
            last edited by 25 Jan 2021, 13:39

            @keneda said in The MMS lost story:

            What a massive work done on this thread, @lduboeuf @jezek the masters of MMS :beaming_face_with_smiling_eyes:

            Now you can delete my name, jezek is doing all the stuff 🙂

            Hope for the work ready for OTA16, but no rush here, take the time you need.

            I doubt it will, am i right @jezek ?

            K J 2 Replies Last reply 25 Jan 2021, 13:55 Reply Quote 0
            • K Offline
              Keneda @lduboeuf
              last edited by Keneda 25 Jan 2021, 13:55

              @lduboeuf
              What would'd be Don Quichotte without Sancho Panza :grinning_face_with_sweat:

              Not a problem if not in OTA16.

              2015-2023 : Meizu MX4 ☠️⚰️✝️
              2023-2024 : Nexus 5 ☠️⚰️✝️
              2024-***** : FPOS Fairphone 5 waiting UT for freedom 😉
              🇲🇫🇬🇧

              1 Reply Last reply Reply Quote 1
              • J Offline
                jezek @lduboeuf
                last edited by 25 Jan 2021, 16:16

                @lduboeuf said in The MMS lost story:

                @keneda said in The MMS lost story:

                Hope for the work ready for OTA16, but no rush here, take the time you need.

                I doubt it will, am i right @jezek ?

                hmm... I think I'm near end. There are 3-4 tasks to do till end. But sometimes a task is done 1-2 new emerge 🙂 My guess, if everything goes smooth, 1 month.

                jEzEk

                L 1 Reply Last reply 25 Jan 2021, 17:58 Reply Quote 1
                • L Offline
                  lduboeuf @jezek
                  last edited by 25 Jan 2021, 17:58

                  @jezek btw, can you add an empty commit or any piece of code to trigger build on telepathy-ofono and history-service ? They are still marked as failed and thus not accessible with ubports-qa

                  J 1 Reply Last reply 25 Jan 2021, 22:32 Reply Quote 1
                  • J Offline
                    jezek @lduboeuf
                    last edited by 25 Jan 2021, 22:32

                    @lduboeuf said in The MMS lost story:

                    @jezek btw, can you add an empty commit or any piece of code to trigger build on telepathy-ofono and history-service ? They are still marked as failed and thus not accessible with ubports-qa

                    Done

                    jEzEk

                    L 1 Reply Last reply 26 Jan 2021, 14:45 Reply Quote 0
                    • L Offline
                      lduboeuf @jezek
                      last edited by 26 Jan 2021, 14:45

                      @jezek Can you sync with xenial branch for those 2 repos, JenkinsFile have been updated and should fix the build issue

                      J 1 Reply Last reply 26 Jan 2021, 15:59 Reply Quote 1
                      • J Offline
                        jezek @lduboeuf
                        last edited by 26 Jan 2021, 15:59

                        @lduboeuf said in The MMS lost story:

                        @jezek Can you sync with xenial branch for those 2 repos, JenkinsFile have been updated and should fix the build issue

                        Done

                        jEzEk

                        L 1 Reply Last reply 26 Jan 2021, 16:22 Reply Quote 1
                        • L Offline
                          lduboeuf @jezek
                          last edited by 26 Jan 2021, 16:22

                          @jezek oups, still messaging-app to be built again...
                          So i am almost ready to test it 😉
                          sudo ubports-qa list:

                          PR_nuntium_8 PR_telepathy-ofono_20 PR_telephony-service_20 PR_history-service_35 PR_messaging-app_260

                          L J 2 Replies Last reply 26 Jan 2021, 17:39 Reply Quote 0
                          • L Offline
                            lduboeuf @lduboeuf
                            last edited by 26 Jan 2021, 17:39

                            @jezek so fetch your messaging-app to test. It seems to work well ;-).

                            Do you differentiate a download Error with a "Cellular-data off" state ?
                            For the "data-off", it could be a simple message like on other platforms with a "Download" button.

                            Awesome work 😉
                            screenshot20210126_183804426.png

                            1 Reply Last reply Reply Quote 0
                            • J Offline
                              jezek @lduboeuf
                              last edited by 27 Jan 2021, 02:53

                              @lduboeuf said in The MMS lost story:

                              @jezek oups, still messaging-app to be built again...

                              messaging-app updated

                              @lduboeuf said in The MMS lost story:

                              Do you differentiate a download Error with a "Cellular-data off" state ?
                              For the "data-off", it could be a simple message like on other platforms with a "Download" button.

                              In the code nuntium returns an error on first connection attempt (there are more stages), but I really don't know if different kind of trouble will cause different error type. I can assume, that if an error happens after first connection attempt, it is not cause of "Celular-data off" state. And I really don't have an idea, how to cause different cause of errors. The plan is to send the error text and/or type to messaging-app via the error message. Maybe then, we will spot the pattern. Meanwhile you can investigate (if you want) and try to cause & get some non "Cellurae-data off" error and then see the log (code producing download errors is here). Maybe, if we can't differentiate by error message, nuntium could ask someone on dbus, or see the config, what the state of cellular switch is and make a note about it in the error message.

                              Btw, I don't know how are other platforms are handling mms download errors.

                              jEzEk

                              L 1 Reply Last reply 27 Jan 2021, 10:17 Reply Quote 0
                              • L Offline
                                lduboeuf @jezek
                                last edited by lduboeuf 27 Jan 2021, 10:17

                                @jezek
                                for download error on other platforms, idk but the current error message is good enough i think.

                                For the "cellular-data" off case, it is displayed as a normal message
                                e.g:
                                Capture d’écran de 2021-01-27 11-13-29.png
                                But in that case, if cellular data is off, the click on the download should check for data on or prevent user...

                                In order to know if cellular data is off, you can query via dbus, example with command line:

                                dbus-send --session --print-reply \
                                    --dest=com.ubuntu.connectivity1 \
                                    /com/ubuntu/connectivity1/Private \
                                    org.freedesktop.DBus.Properties.Get \
                                string:com.ubuntu.connectivity1.Private \
                                	string:'MobileDataEnabled'
                                
                                1 Reply Last reply Reply Quote 1
                                • J Offline
                                  jezek @jezek
                                  last edited by 31 Jan 2021, 21:05

                                  Failed MMS redownload progress report:

                                  This week only nuntium PR got updated.

                                  I've been working on message initialization. To keep nuntium message store (located in ~/.local/share/nuntium/store) tidy, some stored messages are checked with history-service and if they are marked as read or are deleted in history-service, then there is no need to store them in nuntium storage and will be deleted.

                                  It's not a big change, cause I've been struggling with DBus calls to history-service (and with sending/receiving in general). But after some comments from @lduboeuf (with a dbus example) and reading some documentations and blog I have now better uderstanding of dbus. Thank you.

                                  See you next week with new updates.

                                  PS: If you wan to test, you have to install all PR's for this project using ubports-qa script. I'm trying to push only tested commits by myself and everything should be functioning.

                                  jEzEk

                                  L 1 Reply Last reply 1 Feb 2021, 21:09 Reply Quote 1
                                  • L Offline
                                    lduboeuf @jezek
                                    last edited by 1 Feb 2021, 21:09

                                    @jezek tests are fine ;-), awesome, still need some UI polishing, but works fine.

                                    I wonder for the "cellular-data" dbus call if an interface marked as "private“ in the namespace is something that can/should be queried in numtium or elsewhere ?

                                    1 Reply Last reply Reply Quote 0
                                    • J Offline
                                      jezek
                                      last edited by jezek 2 Jul 2021, 22:19 7 Feb 2021, 22:08

                                      Failed MMS redownload progress report:

                                      This week some work on propagating error details from nuntium to messaging-app was done, 4PR's were updated:

                                      • nuntium - Upon decoding mNotificationInd handle Expiry token (absolute/relative) and fill Expiry field as unix time. Propagate error description, expiry date and message size encoded as json to telepathy-ofono.
                                      • telepathy-ofono - forward the error message details in headers to history service.
                                      • history-service - save the error message status to messageStatus and details (encoded as json) to messageText field in db.
                                      • messaging-app - change error message detection, cause now the message can have a non empty text (with error details).
                                        Note: The branch can't be compiled, I've tracked the error and created issue. After it's fixed (fix is trivial) I will rebase the branch it should pass the CI checks (I hope, localy with crossbuilder it worked).
                                        Note: The expiry date could be wrongly encoded, haven't tested on real incoming messages. Some sources say the expiry date is encoded as Size + token + data, some Size + token + size + data. Majority and OpenMediaAssociation(?) documentation said it was the first case (s+t+d), so I've done it that way, but only tests in real world conditions will show. So keep an eye on the Expire field.

                                      @lduboeuf Now is the time to ask for some help. Could you help with the messaging-app's UI part? Error details are saved in text field, encoded as json. Currently there are 3 fields:

                                      • "Description" (string) - just a text with error description.
                                      • "Expire" (string) - time in RFC3339 format, when the message expires at MMS provider.
                                      • "Size" (int) - size in bytes (?) of the message

                                      I'm planing (as you suggested) to add a "CellularDataOn" (bool) field (have a better name) which could indicate if the cellular data was on/off at download time.

                                      If any other error detail, that could be propagated from nuntium, comes to your mind, say it, I will try to add.

                                      jEzEk

                                      A L 2 Replies Last reply 7 Feb 2021, 22:24 Reply Quote 1
                                      • A Offline
                                        AppLee @jezek
                                        last edited by 7 Feb 2021, 22:24

                                        @jezek said in The MMS lost story:

                                        "CellularDataOn" (bool) field (have a better name)

                                        Usually for boolean I use "isMyState" or "hasMyProperty", in this case I would have used hasCellularData or hasMobileData (the first one is my favorite as the toggle switch has the same label in the settings.

                                        1 Reply Last reply Reply Quote 1
                                        • L Offline
                                          lduboeuf @jezek
                                          last edited by lduboeuf 2 Aug 2021, 14:26 8 Feb 2021, 08:20

                                          @jezek said in The MMS lost story:

                                          Failed MMS redownload progress report:

                                          Note: The branch can't be compiled, I've tracked the error and created issue. After it's fixed (fix is trivial) I will rebase the branch it should pass the CI checks (I hope, localy with crossbuilder it worked).

                                          fixed, you can rebase now

                                          Note: The expiry date could be wrongly encoded, haven't tested on real incoming messages. Some sources say the expiry date is encoded as Size + token + data, some Size + token + size + data. Majority and OpenMediaAssociation(?) documentation said it was the first case (s+t+d), so I've done it that way, but only tests in real world conditions will show. So keep an eye on the Expire field.

                                          the one defined here is not working ?: https://github.com/ubports/nuntium/blob/38940464d532a145412c47d8901c1a74fb662eff/mms/decoder.go#L405

                                          @lduboeuf Now is the time to ask for some help. Could you help with the messaging-app's UI part? Error details are saved in text field, encoded as json. Currently there are 3 fields:

                                          • "Description" (string) - just a text with error description.
                                          • "Expire" (string) - time in RFC3339 format, when the message expires at MMS provider.
                                          • "Size" (int) - size in bytes (?) of the message

                                          Yes for sure , how i can commit to your PR ?

                                          Edit: For the expiry date, i just had a case where Expire field is empty in json

                                          L 1 Reply Last reply 8 Feb 2021, 14:39 Reply Quote 1
                                          • L Offline
                                            lduboeuf @lduboeuf
                                            last edited by 8 Feb 2021, 14:39

                                            @jezek said in The MMS lost story:

                                            "Description" (string) - just a text with error description.

                                            Humm, where does come from error messages, are they normalized somewhere ?

                                            J 1 Reply Last reply 8 Feb 2021, 17:22 Reply Quote 0
                                            63 out of 133
                                            • First post
                                              63/133
                                              Last post