Some MMS not visible in Google messages app due to `m_type` attribute being `0` instead of `132`

[EarthDaniel]

I found a bug when using this feature --exporthtml [DIRECTORY] ./signalbackup-tools /signal-2023-11-16-08-40-05.backup 835511984345317204956386847025 --exportxml hania was the exact command I run. I did it on Ubuntu run in Termux run on Android.

After importing these using SMS Backup & Restore some messages were not visible in Google messages app. When viewing these using other SMS apps everything was visible, that was weird, I thought there was something wrong with the google app. After some trials & dead ends I exported the problematic conversation & looked into the xml. I gave GPT sample of message that was displayed properly & one that didn't. In response I got.

The primary difference between the two messages is the value of the m_type field:

The message that is displayed correctly has m_type="132". The message that is not displayed in the Google Messages app has m_type="0". In the context of MMS messages, m_type values typically indicate the type of the message. Here are some common values for m_type:

132 typically corresponds to a received MMS. 128 typically corresponds to a sent MMS. 0 is unusual and might indicate a special or unsupported type. The m_type value of 0 could be causing the Google Messages app to fail to recognize or properly display the message.

I changed this value accordingly in my entire xml & imported the conversation again. Now everything works as intended.

I believe I have all the files needed to find the source of this issue if needed, but I won't attach them here as it's a private conversation.

[bepaald]

Thank you for your report. The m_type value is actually also present in the Signal database, so the export function simply uses the value available. However, after reading your message I have inspected my own backups and can confirm that Signal in some cases does not set m_type correctly (for reasons unknown).

Since Google's messages app can not deal with this, and it is an often used app, I have just added some code to always set the m_type to 128 or 132 manually if it is not set in the database. So the problem should now hopefully be fixed.

I also fixed a few other issues I noticed, which I think you did not experience because you were using a slightly old backup (exporting attachments would fail on current backups, but that should also be fixed now).

If it is not too much trouble, could you test the update? No need to actually import the file if you don't want, maybe just quickly inspect the XML file to confirm all the m_types are now set correctly.

---

Even though this function is probably the oldest one this program supports, I have not ever had any feedback on it to confirm it is actually working. I'm actually quite pleased to hear importing with SMS Backup & Restore appears to work correctly. Could you just confirm (most) messages look good and include attachments (pictures and such)?

Thank you so much!

[EarthDaniel]

m_type="0" was in 88/356 messages of the first xml your program generated. Now after update, no matches found in file.

All pictures send in conversation seem to display properly after being converted to MMS.

As I was digging into the topic I saw that the new standard RCS actually supports reactions & replies, although there's still a ton of complications. Maybe in near future we'll be able to do lossless conversion of these backups. For now I saved reactions & replies from this chat in an Excel spreadsheet in a folder "For someday" 😁

[bepaald]

That's good to hear, thank you for the feedback.

As I was digging into the topic I saw that the new standard RCS actually supports reactions & replies, although there's still a ton of complications. Maybe in near future we'll be able to do lossless conversion of these backups. For now I saved reactions & replies from this chat in an Excel spreadsheet in a folder "For someday"

As soon as synctech updates the specification for SMS Backup & Restore, I'll start work on it. Hopefully "someday".

Thanks again!