@ezst036 Sorry to hear those things haven't worked. I assume that if restarting nuntium didn't fix the problem, it's just a different issue than I was having.

I hope you're able to resolve it somehow without a full backup and re-install. I presume that in the past when this has happened to you, flashing without wiping data didn't fix the issue?

I have only found backing up and using the UBPorts installer to start fresh as a resolution.

It's working again now, wiped and now have OTA-5.

EDIT: (3/10/25):

I marked the discussion as solved, and wanted to make a few notes for reference.

I updated to OTA-8. This is important compared to other OTA-x because there was an update commit made to the apns-conf.xml in the source tree after I made some requests on Gitlab. My cell provider's APN by default was out of date. Now when I do a fresh UBports install I do not have to change the APN information, the default is correct.

Hopefully that prevents the software from getting confused between my "custom" APN setting and the "default" outdated APN contained in the source xml file. I only need the default.

I will create a new discussion or Gitlab bug request should the issue come back.

I hope you're able to resolve it somehow without a full backup and re-install. I presume that in the past when this has happened to you, flashing without wiping data didn't fix the issue?

@wally said in Why does picture messaging stop functioning after a few months?:

@ezst036 Can I ask what device you're using?

I currently have a Fairphone 4. I started out with a Pixel3a though and it happened on that one once too.

I followed the steps you provided as best as I could:

change my MMS APN to something incorrect, disable MMS, restart phone, correct the MMS APN, enable MMS again, restart phone again, and then it works.

This did not work, but I could not follow the steps as typed. It seems that on 20.04 OTA4 when the phone restarts all APNs are enabled, not the disable as I left it. I thought I might get around this by shutting off all mobile data in its place within these steps, but the icon still only spins and spins.

Yes, just remove the provided APN, recreate a new one, try just one with Internet to see if cellular data is working first, then add the MMS one.

@ezst036 Can I ask what device you're using?

I currently have a Fairphone 4. I started out with a Pixel3a though and it happened on that one once too.

I followed the steps you provided as best as I could:

change my MMS APN to something incorrect, disable MMS, restart phone, correct the MMS APN, enable MMS again, restart phone again, and then it works.

This did not work, but I could not follow the steps as typed. It seems that on 20.04 OTA4 when the phone restarts all APNs are enabled, not the disable as I left it. I thought I might get around this by shutting off all mobile data in its place within these steps, but the icon still only spins and spins.

systemctl --user restart nuntium.service

Thanks for helping sort this out!

Sadly though, this did not do anything appearing to resolve the issue. The nuntium logs used to be located at: ~/.cache/upstart/nuntium.log

Do you know where they are located at now due to systemd?

In that case, it is not a combined APN setting. Only works if APN has the same name.

Thank you for clarifying that. I will try resetting the APNs, rebooting and ensuring no wifi, but having done these a few times already I don't expect much of it.

Hopefully I can collect more info on how to actually troubleshoot this instead of doing a re-install, I would need to put in some kind of bug report that amount to more than just "it's broken" as that won't help me nor anybody else.

I wonder if there's a way to get that command back. After a quick bit of searching I tried "apt-install upstart" without success.

Anything involving apt is a bad idea as a quick fix.

16.04 used upstart for managing services. 20.04 uses SystemD. The equivalent command to yours is:

systemctl --user restart nuntium.service

In case it's useful, here's what I used to do before I found the nuntium command. I have no idea whether it's all needed, but this fix also worked reliably, the restart nuntium command was just a lot faster.

"I have a weird process that fixes it, some of which is probably unnecessary/superstition: I change my MMS APN to something incorrect, disable MMS, restart phone, correct the MMS APN, enable MMS again, restart phone again, and then it works."

full post in
in https://forums.ubports.com/topic/8145/mms-status-on-the-oneplus-5-cheeseburger/3

Except, when I type in that command or just when I type in initctl I get:

bash: initctl: command not found

Whoops indeed. Looks like that command doesn't exist in 20.04. Sorry for the bad advice, I'm still running 16.04 on my daily driver, as I have some need for video calls.
I wonder if there's a way to get that command back. After a quick bit of searching I tried "apt-install upstart" without success.

wouldn't this nuntium be restarted if I do a phone shutdown or reboot?

I would have thought so too, but I had this problem many times, far more often than once every six months. Restarting/shutting down never fixed it, and that command always did.

I lack technical knowledge, and really just poked at things a bunch without always understanding. Lionel knows 1000 times more than me and has actually worked on a bunch of this stuff, so please defer to his advice over mine. I just happen to have had the same (or a similar sounding) issue as you.
Before I discovered that terminal command, I did have a more convoluted fix, which I'll go look for.

@lduboeuf

If you confirmed that you toggled On Cellular Data ( and toggled Off Wifi ) when sending MMS and it still don't work, then 99,9% chance is a APN setting issue. Depending of your provider, but for mine ( La Poste Mobile in France ), even if it is shown that 2 APN need to be set ( one for Internet, the other for MMS) , i had to create a "combined APN setting Internet & MMS", it means removing the current setup and recreate one.

Thanks, is this a semi-common thing that proper APN settings are working and then, just, one day no longer working that they should require this kind of removal procedure?

I don't know, never had that issue. Once setup, works perfectly for me and doesn't change with OTA updates.
If not working, maybe provider have changed things, or is doing weird things that our services don't understand. In that case, logs might help. ( e.g with LogViewer app, look at nuntium logs )

That's really what I want to wrap my mind around. When OTA5 was announced, I specifically didn't upgrade because I figured the phone worked, and since then I have sent a few more MMS messages and it was working.

How do you deal with combining your APN setting when your web APN is different than your MMS APN and the phone only has one line? Which one do you choose?

In that case, it is not a combined APN setting. Only works if APN has the same name.

If you confirmed that you toggled On Cellular Data ( and toggled Off Wifi ) when sending MMS and it still don't work, then 99,9% chance is a APN setting issue. Depending of your provider, but for mine ( La Poste Mobile in France ), even if it is shown that 2 APN need to be set ( one for Internet, the other for MMS) , i had to create a "combined APN setting Internet & MMS", it means removing the current setup and recreate one.

Thanks, is this a semi-common thing that proper APN settings are working and then, just, one day no longer working that they should require this kind of removal procedure?

That's really what I want to wrap my mind around. When OTA5 was announced, I specifically didn't upgrade because I figured the phone worked, and since then I have sent a few more MMS messages and it was working.

How do you deal with combining your APN setting when your web APN is different than your MMS APN and the phone only has one line? Which one do you choose?

Here's something to try. I can't say whether it will definitely fix things, but it's quick and it won't break anything.

Open Terminal
type "initctl --user restart nuntium"

Thanks, this sounds promising.

Except, when I type in that command or just when I type in initctl I get:

bash: initctl: command not found

Whoops. Best I can tell initctl ought to have been installed already and just be there. So maybe something somehow got damaged. Just so it is asked, wouldn't this nuntium be restarted if I do a phone shutdown or reboot?

I seem to be having this issue where after about six months, sending and receiving picture MMS messages no longer works. The icon just spins in txt messaging but the image never gets sent. If someone sends to me, I'll never know about it unless I'm told.

Is my only option to make a backup of my text messages and photos and do a full/system reinstall? That seems excessive to do every six months.

I've checked my MMS APN, reset the settings, rebooted, but non functionality stays the same.

If you confirmed that you toggled On Cellular Data ( and toggled Off Wifi ) when sending MMS and it still don't work, then 99,9% chance is a APN setting issue. Depending of your provider, but for mine ( La Poste Mobile in France ), even if it is shown that 2 APN need to be set ( one for Internet, the other for MMS) , i had to create a "combined APN setting Internet & MMS", it means removing the current setup and recreate one.

Open Terminal
type "initctl --user restart nuntium"

It should return something like "nuntium start/running, process " and then a short string of digits.

I used to have an identical sounding issue, occurring unpredictably, every so often. Wheel spinning forever on outgoing MMS, nothing to indicate an incoming MMS even happened. For me the above fix always worked.
I never figured out what made the problem happen, or how to know when it HAD happened besides manually testing. I always worried a client had texted me without me knowing.
It hasn't happened since I changed cell providers, and it's now been long enough that I think it just doesn't happen any more.

This may be provider specific, but I'm able to text photos to myself, which was always a good test of whether or not things were working.