this is STILL broken in 4.4, by the way.
only now you cant downgrade because they changes the DBUS method for sending an MMS (downgrading breaks ‘Share (MMS)’)
this is STILL broken in 4.4, by the way.
only now you cant downgrade because they changes the DBUS method for sending an MMS (downgrading breaks ‘Share (MMS)’)
(f5121 Xperia X, SFOS 4.4.0.58)
This isn’t retricted to broken settings. It works (for me) if “Download Automatically” is active, and, as described by others, the initial download succeeds, otherwise, no luck.
So, (@flypig) why is this not tracked by Jolla?
also, problem appears to be 100% in jolla-messages, not in ofono, which is bizarre.
in 4.4, the problem is worse (or at least different), so it seems they may have tried (ineffectually to fix it)
There are unfortunately still untracked bugs, usually because they’ve not been picked up by someone, or because they’re incorrectly tagged.
However, with the help of the Community Bug Coordination Team we’re doing our best to tidy things up, with the aim that eventually all high quality bug reports will get tracked. Amongst other things the Team randomly selects ten high quality bug reports to add to our internal issue tracker each fortnight.
what can i do to help ensure this issue is randomly selected?
there is NO WORKAROUND for 4.4. downgrading the jolla-messages app doesnt work anymore (for me, at least).
that means these messages are just LOST FOREVER
this is still a (CRITICAL) bug in 4.4.0.68
receiving MMS works only if you first receive it. it is never retried, no matter what you do. messages are lost forever.
@flypig still untracked, as far as i can tell, and MMS are still disappearing forever.
there is no longer any functioning workaround as of 4.4
also, afaict, this affects all users in all countries on all devices, and is a regression as of 4.3
For me it’s even worse since the 4.4.0.68 update. I have not been able to send or receive MMS since the update.
It is HORRIFYING that this critical bug still hasn’t been fixed and - what’s even worse - it doesn’t even seem to be of any special interest.
As teleshoes wrote, if MMS reception fails, as there’s no way to retry, the message is actually lost. Which is unacceptable.
Is there a way to skew that RNG to include this in the next group of ten that will be selected? Pretttttty pleeeeeease?
@slava Could you please make an aarch64 build of your “MMS Settings”? In my case changing some of its settings allows sending larger images via MMS. Sadly, there’s no aarch64 build for the 10 III.
Thank you.
Doesn’t Settings → Apps → Messages → Maximum message size do the trick?
Well, this is really strange. In Settings → Apps → Messages - Maximum message size I have the largest size (1 MB) selected and it is persistent. In your MMS settings I also select “Extra large (1 MB)” but on the XA2 (4.4.0.68) now it persists only until I try to send an MMS. Then (and only then) it automatically changes to Medium (300 kB). And indeed, I can no longer send anything above 300 kB anymore.
What may be causing your MMS Settings to automatically revert to 300 kB? Does it query the network for MMS size limit and automatically changes it?
P.S. As it now also automatically changes the user agent and user agent profile back to “Jolla”, maybe it has something to do with Sailjail, i.e. inability to persistently store the settings and it simply reverts to the defaults?
Earlier, on older OS releases when I was setting the 1 MB limit in your app, it was persistent and allowing me to send messages > 300 kB (which the system setting didn’t allow despite being set to 1 MB). Something has changed…
P.S.2 The good news is that now receiving messages from the iPhone (with or without the “Subject” text) works perfectly fine. Thank you for that!
After playing some more with MMS support on the 4.4.0.68, I must say that it is a GREAT IMPROVEMENT vs previous OS versions. The “empty Subject field” issue has been entirely solved. Which not only permits receiving MMS from iPhones (where the Subject field, albeit optional, is enabled but rarely used, resulting in messages that previous SFOS releases weren’t accepting), but also my operator’s voicemail messages. Also, I haven’t yet experienced any problems with sending MMS, as long as the image is small enough to fit operator’s limits.
Two problems remain:
it looks that SFOS doesn’t have codecs to play MMS audio attachments (.amr files), which is strange because AMR is a standard in MMS. I’ve already submitted a bug report here. Currently, i need to use an Android version of VLC to play back MMS audio attachments…
it looks that there is no proper automatic resize of images to fit the configured operator’s size limit (e.g. 300 kB). I need to manually resize each image in a 3rd party image editing app prior to sending, or else sending MMS fails. Which is extremely cumbersome and time consuming.
Other than those two issues, everything else seems to finally work fine!
Thanks for double checking and letting me know @teleshoes. I’d be grateful if you’d be willing to try the following test for me as well. If you complete the following steps, do you get the same result, and does this look the same?
Resulting in the same “Waiting” spinner, but the MMS never arrives?
done. confirmed, stays waiting forever (so far, ‘waiting’ for 23min)
i also tested alternating download-auto=YES/NO, 3x each, and i have 3 'waiting’s interleaved with 3 pix.
if i cancel+retry a ‘waiting’, it remains waiting.
similarly, if i have download=auto, but i set airplane mode while its downloading, the download fails, and will never succeed ever again on retry.
hitting download-mms instantly does not help. once the mms has failed or been pending, it will never download, ever.
mms-engine never produces any output at all after clicking ‘download’ or ‘retry’. (it produces normal output when sending, and when receiving the pending-mms envelope). if mms-engine has shutdown for inactivity already, it never starts back up.
automatic resize works for me. the setting is in settings=>apps=>messages
or dconf write /imsi/$SIM_IMEI/mms/max-message-size $SIZE_IN_BYTES
the part that does jpeg resizing (mms-engine) is open source and the impl looks like it makes sense to me.
lol, SFOS doesnt even play animated GIFs. MMS is only very very basically implemented, because its not important to most users in the supported markets.
except, you know, THIS bug. actually, i have yet to see a single person claim that download-auto=NO works for them at all, since 4.3, so it could literally be broken for everyone.
I’ll play with it some more to test it more thoroughly. As for now, quite often I face problems with sending a picture that, after manual resizing, can be then sent without issues.
Actually, it does. It’s just that it isn’t enabled. There is a very simple modification of the Gallery app that enables it (there is a thread about it on this forum).
Actually, for me the 4.4.0.68 update fixed MMS support to the point that since then I haven’t had a single message that failed to download (which was common prior to 4.4.0.68). So I couldn’t test retry. Maybe I’ll try to enforce it somehow (e.g. interrupt downloading a message by disabling Internet access in the process) so that it fails.
Same for me, spinning forever on Xperia 10 II, 4.4.0.68.
But the other issue is that it is nearly impossible to send a MMS. Had to toggle WiFi On/Off, play with the IP/Dual/IPv6, tried with VoLTE enabled/disabled, to be able to send. As of now no clue off the proper setting. This is way worse since the .68 update, have not been able to receive a single MMS since the update.
Do what I did: use @slava’s MMS Logger to capture logs while trying to receive some MMS and see what’s causing the message reception to fail…