I see, thanks for the update. If you want, I can see what it'd take for
jmmsto support reading files that Chatty has downloaded and discarded.
I'm still getting SMS normally. I've received a few today.
That's great news and it's the most important sign the phone's unclogged. Can you confirm you've gotten MMS messages, i.e. with
jmms --readyou've looked at a group or multimedia message?
mmcliso at least for now it's tied to ModemManager. It shouldn't be too difficult to adapt to another tool, though.
~montyhouse any news on whether a fresh install fixed the conflict?
I have no mobile data through my carrier (talk and text only). Is that a problem?
This seems like it might be a problem; the way MMS works is an SMS is sent containing a URL where the MMS data can be downloaded. Depending on how literal your carrier is about no data plan, this could stop you from getting the messages.
Are you running
jmmswith wifi enabled? Can you try with wifi turned off and report back if it works?
To answer your other questions:
What is "receiving" vs "received"?
These terms come from ModemManager. Receiving, in general, is somewhere in the vague state before being fully received.
Can a message be stuck in "receiving"?
Yes, though often this doesn't indicate a problem, i.e. a missing message. Restarting the phone will get rid of these.
Is this what people mean by a "clogged" modem?
I think generally a clogged modem is messages in "received" state that the SMS app (e.g. Chatty) doesn't know what to do with, eventually blocking receipt of other SMS messages.
If a message is already "received", why does jmms attempt to, er, receive it?
When it's in "received" it means we've received the SMS with the URL to the MMS; jmms then gets the linked MMS and parses it.
Why does it fail to get the message?
Usually it's because the web request is going via wifi instead of via the user's data plan. I haven't yet had reports of a user without a data plan; I'm not sure what happens in that scenario.
Why do I keep getting the same messages? Are they floating around in the ether?
jmms will keep trying to download the MMS until it succeeds.
How do I read these files that end up in my sms folder?
The files in the SMS folder are generally just URLs; the interesting bit is in the linked data. If you do want to parse them for some reason, though, check out
getURLin jmms.hs (it's not very sophisticated)
I'm pretty sure I can ignore the noise from git. It's just complaining that I haven't configured my user name and email.
Yes, that's right. You can
git config --localfor
user.nameif you just want to silence the messages.
A couple other questions:
- What OS are you running? Mobian? Something else?
- Do you still receive normal SMS? Is Chatty your client?
Re: the message you expected to see today, can you post the output of
git initif needed automatically on startup (https://git.sr.ht/~amindfv/jmms/tree/master/item/jmms.hs#L68-73).
Anecdotally, I've occasionally seen "couldn't create file: SMS has no data" errors, and I think - but am far from sure - that jmms has seen SMS messages before they were picked up by Chatty, but by the time it tried to fetch them they were gone.
jmmsworks is fairly simple:
- An MMS message is recieved via SMS (the process basically starts as an SMS containing a URL to fetch the MMS)
jmmsthen looks for any received SMS messages with
jmmsthen downloads them, parses them, etc
This works on the theory that all SMS messages in the received state contain MMS URLs, since if they weren't MMS, Chatty would have fetched them then deleted the receipt such that they'd no longer appear in
However, there's a possible race condition:
- A message comes in
jmmssees the message with
- Chatty sees the message, fetches it and deletes it
jmms, assuming the thing it saw was was an MMS, attempts to read the message, but it's now empty.
This is my running theory on why I occasionally see "couldn't create file: SMS has no data" messages. However, that should only occur once. If, for example, you ran
jmms --gettwice in a row and both times saw that error, my theory of the cause is incorrect.
~luther is this resolved?