Looks like a download doesn’t even trigger any event in MMS logger, as shown in scroot 1.
true, although since except we’re talking about MMS, a typical user would expect it to be animated there, and not have to open a different program, especially since non-animated GIFs are supported.
that is really good to hear! note, however, that this is NOT a general “mms is not working” thread. it is a SPECIFIC bug, one that you have not tested, and probably DO have (since i have not heard of ANY user not having this specific bug, and a bunch of folks who do). if you feel like it, you can test it easily by setting auto-download=no, or by interrupting like you said.
for me, MMS works perfectly, and more or less always has, EXCEPT for this horrible bug. this bug is especially bad for me, because i have an Xperia 10 III in the USA, and there is no LTE band 12 on the mark3, so i get frequent brief interruptions of service.
its also especially bad because it is a DATA LOSS error, and is NINE MONTHS OLD, and should be EASILY bisected since the app that causes it (jolla-messages) is known, and a very close known good version (1.1.48.3) and known bad version (1.1.55) exist.
that logger just takes the output of mms-engine, presumably using journalctl or by changing mms-engine init script to log somewhere else.
there is probably no point in logging all different states, as all the states work correctly, EXCPET this one state where NOTHING is logged at all (mms-engine app isnt even started if its not running already).
i suspect that the problem is permissions, or a typo in the dbus api, etc, and that sailjail will somehow be the culprit.
Thanks for checking the steps I asked about @teleshoes. We do have an internal bug covering those steps, and since this looks the same I’ve now marked it as tracked.
If there’s progress to report on fixing this we’ll do our best to report it back here. Thanks also for all of the useful help and input so far.
Well, it was you who digressed into animated GIFs, I merely responded to it.
Fully agreed, did I question it? I only corrected that in fact it is supported, just not implemented in the GUI.
Not true. I’ve had failed MMS downloads and attempts to retry resulting in spinning wheel / Waiting very often prior to 4.4.0.68, and not a single time on the 4.4.0.68. So in my specific case the 4.4.0.68 update - so far - seems to have fixed it. And that’s all I wrote. I’m sorry if it bothers you, but that’s just how it is.
first, friend, im sorry if i’m coming across confrontational or annoyed. im disagreeing with you, even still, but hopefully still in a friendly way. (if not, just to tell me to get out of your hair and i will)
so: no, this bug is ONLY about RETRY (and tap-to-download) failing, NOT about the mms failing initially (which can happen for a million reasons, including downloadAuto=no). it is not, in fact, fixed for you, you just stopped encountering the use case that is broken (presumably because ANOTHER, separate, bug was fixed).
i’m making this pedantic point, not to annoy you, but to clarify that, to the best of my knowledge, literally NO ONE has this issue fixed for them at this time.
hooray! thanks flypig!
Thanks all for your reports! I encountered the issue 3 days ago on my SFOS 4.4.0.68 XA2. I was wondering what parts of my MMS settings were wrong. Luckily the search engine directed me toward your bug report. Fortunately, after two days, Bouygues Telecom sent me two SMS, one with a link to a web portal, and a second one with a password, allowing to consult the MMS the phone could not retrieve.
FIXED! confirmed fixed, for me at least, in 4.5.0.16
HOORAY! missed messages are no longer permanently lost
Good for you! Mine is still as broken as ever, no sending and no receiving…
does MMS work normally for you, but retry always fails? if so, then you still have the bug.
(this bug is ONLY for MMS retry permanently failing. if MMS does not work at all for you, that is not this bug, and likely is either a carrier-specific issue, an ip routing issue, or a dns issue, or a combination)
afaict, this bug is solved, and the problem was apparently permissions for jolla-messages app (apparently not ofono or mms-engine related). probably one more victory for the utterly useless sailjail.
