Hey guys,
So I'm enjoying my note 10+ so far, but I'm having an issue when trying to send live messages. The messages come out very compressed and after doing some research, it was advised to send them as mp4s instead of gifs. So I tried that, but it was even worse.
So I said forget it and that I would just send gifs like I did on my lg v30. But the same issue persists, even with tiny gifs. The gifs are severely compressed and washed out. I tried using the stock messenger, signal and textra, but they all seem to be exhibiting the same issue. Whereas on my v30, textra never gave me any issues and I could send very large gifs even with no problem.
My phone is an n975u1 us model that I purchased and imported into Canada, running xaa firmware and not xac. My apn settings are all fine, I can send and receive calls, etc. Does anyone know what's going on or have the same issue?
Here is a screenshot of the issue:
https://ibb.co/qd6zhgB
crushdancexz said:
Hey guys,
So I'm enjoying my note 10+ so far, but I'm having an issue when trying to send live messages. The messages come out very compressed and after doing some research, it was advised to send them as mp4s instead of gifs. So I tried that, but it was even worse.
So I said forget it and that I would just send gifs like I did on my lg v30. But the same issue persists, even with tiny gifs. The gifs are severely compressed and washed out. I tried using the stock messenger, signal and textra, but they all seem to be exhibiting the same issue. Whereas on my v30, textra never gave me any issues and I could send very large gifs even with no problem.
My phone is an n975u1 us model that I purchased and imported into Canada, running xaa firmware and not xac. My apn settings are all fine, I can send and receive calls, etc. Does anyone know what's going on or have the same issue?
Here is a screenshot of the issue:
https://ibb.co/qd6zhgB
Click to expand...
Click to collapse
There are limits to how big of a file you can send via MMS (or via RCS)... If the messaging application is compressing the image then the size of the file you tried to send exceeds the limit. With larger sized images/files the compression will probably be more aggressive (and more noticeable).
On my phone looks like the limit is 105mb file size for RCS messaging
I know that there are file limits. But I've never had an issue with this using the lg v30.
crushdancexz said:
I know that there are file limits. But I've never had an issue with this using the lg v30.
Click to expand...
Click to collapse
I can't tell you why brand X works and brand Y doesn't. Also in the same token it's not really conducive to finding out why your having (solving and/or identifying the cause of) image quality issues on a Note 10+ using a Note 10+ to send a mms image.
Try this to see if the file size limit is being enforced:
Reduce your image size to less then 105 megabytes and try again. Save the file and compare file size (refer to note 1 below)
Create an image file a little larger then 105 megabytes.. If the image appears normally then save it and compare file sizes (refer to note 2 below)
Create an image file like what you had before and send it. Save the file and view the file size (refer to note 3)
~Notes~
Compare the file size of what you received (with that of what you had sent) to see if it is the same size.
You are trying to see if anything a little over 105mb gets reduced in both quality and file size. Compare what you sent with what you received. If the file size of what you received is smaller then what you sent, then file size limits are being enforced
Again like above you are trying to see if the file size is reduced to 105mb or less. If the file size of what you received is smaller then what you sent file size limits are being enforced.
If file size limits are being enforced I am not aware of any method or way to remove or disable said limit set by the carrier. If you have a larger image you wish to send then you may want to consider alternative file transfer methods (Facebook messenger, email, etc)
scottusa2008 said:
I can't tell you why brand X works and brand Y doesn't. Also in the same token it's not really conducive to finding out why your having (solving and/or identifying the cause of) image quality issues on a Note 10+ using a Note 10+ to send a mms image.
Try this to see if the file size limit is being enforced:
Reduce your image size to less then 105 megabytes and try again. Save the file and compare file size (refer to note 1 below)
Create an image file a little larger then 105 megabytes.. If the image appears normally then save it and compare file sizes (refer to note 2 below)
Create an image file like what you had before and send it. Save the file and view the file size (refer to note 3)
~Notes~
Compare the file size of what you received (with that of what you had sent) to see if it is the same size.
You are trying to see if anything a little over 105mb gets reduced in both quality and file size. Compare what you sent with what you received. If the file size of what you received is smaller then what you sent, then file size limits are being enforced
Again like above you are trying to see if the file size is reduced to 105mb or less. If the file size of what you received is smaller then what you sent file size limits are being enforced.
If file size limits are being enforced I am not aware of any method or way to remove or disable said limit set by the carrier. If you have a larger image you wish to send then you may want to consider alternative file transfer methods (Facebook messenger, email, etc)
Click to expand...
Click to collapse
I sent a static jpeg and it went from 881Kb to 351Kb on the Note. On the V30 it was still 881Kb.
I really don't think this has anything to do with my network because the v30 on the same network does not do this. With *any* text program.
crushdancexz said:
I sent a static jpeg and it went from 881Kb to 351Kb on the Note. On the V30 it was still 881Kb.
I really don't think this has anything to do with my network because the v30 on the same network does not do this. With *any* text program.
Click to expand...
Click to collapse
What your LG can or can not do is not conducive nor helpful for what the Note 10+ is or isn't doing (and why). For example here's why it doesn't help...
What if a toggle exists on the LG phone that doesn't exist on the Note 10+? - You can't root the Note 10+ variant you have so you can't make a toggle appear without either the carrier enabling it (or an app that has it added).
What if the LG phone was provisioned differently then the Note 10+? - You can't make changes to the Note 10+ variant your using within regards to carrier provisioning...
What if an LG app allows larger files? - That's not gonna be of any help with a Samsung Note 10+
I did some research today on the subject and what I found across different providers support forums as well as Samsung support forums is that the issue is related to MMS limitations on image size. Yes some people mentioned that there "LG phone could do it" but it isn't exactly as simple as that. In some cases (whether phone, stock applications or within 3rd party apps) a setting exists which allows one to choose the quality of the image being sent. In your stock apps or 3rd party apps your gonna want to see if you can find this setting. If you can't find the setting then this means it isn't something you can change, and if this is the case then nothing can be done.
In my Note 10+ case I don't see this on Google Messages app nor my stock messaging app, so when I send a MMS of 240kb in size (or a test image that was over 2mb in size) it gets compressed. Again this isn't a phone issue, it is something that is set and controlled by my carrier... Which in your case I imagine your being effected by the same limitations.
Thank you for looking deeper into it. I read the same thing on the Samsung boards and across reddit as well during my research. It's just very frustrating because I really enjoy mms and sharing content with my friends. I was going to sell the v30 and keep the note, but now I'm not sure what to do. Even the edge lighting for the phone is broken and there's no real solution for that either based on my research. Yes they're different phones, but using the range app didn't even resolve the issue, on the same carrier. So what's the difference if not the phones? It just seems like Samsung likes saying this and that, but the features are half baked. I'd even trade gifs for live messages, but that's even more broken. Thanks again though for trying to help. You're a pretty cool person.
Hey, Crush. Just curious - what app were you using on the LG? If the same one on Samsung, was it the same version? If not, you could try exporting the APK from the LG and installing it on the Samsung.
Related
I know this has been discussed before as an issue with the 3G Slide but I'm wondering if anyone wants to try to get magenta to do something about it. With how much they advertise this phone and used it in everything that had to do with them why did they either not set a user agent for mms messaging, resulting in the server to default to the lowest setting or, why did they set it so low for our phone? My Blackberry 8900 sent pics well over 1MB just fine with no resizing (with EDGE at that) as many other phones do.
I've had enough of the 1KB - 25KB mms messages, sending and receiving. I know a few apps attempt to fix this but even with CM6 having that option built in - it still does it, as I'm sure many of you notice for large pics. So maybe we should do the same thing that was done with the source code and bluetooth code issue. Anyone up for it?
On a secondary note: In the mms.apk the UA is listed as: http://www.htcmms.com.tw/Android/common/mytouch3g/ua-profile.xml which has a max height/width of 480x640 and max size of 307200 (300K). If I replaced that with say: http://www.htcmms.com.tw/gen/HTC_HD2_T8585-1.0.xml with a h/w of 1600x1600 and size of 600K, would it work? Yes I know it's windows but that shouldn't effect the mms aspect.
mikechannon - if you will, please keep this open for a while and delete it at your discretion.
Yesterday I stumbled across a curious error. Zune told me that I had reached the maximum allowed amount of media on my HD7. It's not that my SD card was full or so, there's still 15 GB left on it. I had about 3 GB of music, 2 GB of videos, 400 MB of podcasts and 5 GB of pictures on it. I removed the media and am currently synchronizing again, since I can't believe that WP7 limits the amount of media in any way. Did anybody else ever experience such an error?
Just in case somebody else may face the same situation as I did:
there doesn't seem to be a limit for the total amount of media on a device. The issue I had was caused by a folder containing about 12000 pictures. Apparently WP7 can't handle or doesn't allow that many pictures in one single folder. I solved it by making several child folders containing 3000 images each.
dkp1977 said:
Just in case somebody else may face the same situation as I did:
there doesn't seem to be a limit for the total amount of media on a device. The issue I had was caused by a folder containing about 12000 pictures. Apparently WP7 can't handle or doesn't allow that many pictures in one single folder. I solved it by making several child folders containing 3000 images each.
Click to expand...
Click to collapse
Hello old friend ...
I see you find the solution ...12.000 files in one folder ??? wowwww.
Thanks for the tip anyway
colossus_r said:
Hello old friend ...
I see you find the solution ...12.000 files in one folder ??? wowwww.
Thanks for the tip anyway
Click to expand...
Click to collapse
Hi mate
Well, seems I was wrong. There really appears to be a limit to how many images you may have stored on the device. Even though I splitted the folders, it synchronized only 1300 images back to the phone. So around 10700 pictures remained unsynced. I'll try and contact winphonesupport via twitter. Maybe there's some workaround. I have tons of images of my family I use to carry around on my device. And I want to keep it that way.
I had a nice chat with the WinPhoneSupport on Twitter. It appears that Zune uses a database on each device which is quite limited concerning the amount of media it can handle. That means that - totally independent from the storage space left - it's possible that you just cannot sync anymore files if you have a huge amount of pictures on your device. I can't exactly tell what that limit is, but I had the error at about 35000 files. The support told me they'll escalate my report to the team, whatever that may mean. Let's hope they simply increase that limit.
dkp1977 said:
I had a nice chat with the WinPhoneSupport on Twitter. It appears that Zune uses a database on each device which is quite limited concerning the amount of media it can handle. That means that - totally independent from the storage space left - it's possible that you just cannot sync anymore files if you have a huge amount of pictures on your device. I can't exactly tell what that limit is, but I had the error at about 35000 files. The support told me they'll escalate my report to the team, whatever that may mean. Let's hope they simply increase that limit.
Click to expand...
Click to collapse
yes!! please get back to us with what transpires! what device are u using?
professorwol said:
yes!! please get back to us with what transpires! what device are u using?
Click to expand...
Click to collapse
I use a HTC HD7.
Btw, here is the error code: C1010032 (8004A211)
dkp1977 said:
Hi mate
Well, seems I was wrong. There really appears to be a limit to how many images you may have stored on the device. Even though I splitted the folders, it synchronized only 1300 images back to the phone. So around 10700 pictures remained unsynced. I'll try and contact winphonesupport via twitter. Maybe there's some workaround. I have tons of images of my family I use to carry around on my device. And I want to keep it that way.
Click to expand...
Click to collapse
Put your images on skydrive. Smartphones aren't media PCs, and I simply cannot even fathom a reason why anyone would want that many on a phone nevermind waste support's time dealing with a non-issue...
N8ter said:
Put your images on skydrive. Smartphones aren't media PCs, and I simply cannot even fathom a reason why anyone would want that many on a phone nevermind waste support's time dealing with a non-issue...
Click to expand...
Click to collapse
First of all it's my decision whether I want to carry my pictures with me on my device or put them somewhere on the net. Secondly having all those images stored on a server would require a fast internet connection if you want to quickly browse through the (sorted) images if you're looking for something specific. Sadly you don't always have such a fast connection. Third and last: I consider it an issue when the amount of media - whatever kind it may be - is limited by a database with a too low capacity rather than the storage.
N8ter said:
Put your images on skydrive. Smartphones aren't media PCs, and I simply cannot even fathom a reason why anyone would want that many on a phone nevermind waste support's time dealing with a non-issue...
Click to expand...
Click to collapse
If he has enough space on the phone then why not keep the pics there? skydrive is not always accessible and could end up costing you if you don't have an unlimited data plan...
OK, so for some reason our builds happen to be hardcoded with a UserAgent Profile pointing to http://www.google.com/oha/rdf/ua-profile-kila.xml. This is reported to the MMS server whenever our MMS client tries to download something, it's stuck in the x-wap-profile: header of the HTTP request.
If you read thru that file you'll see that it's the spec for a Samsung SGH-T429 with 320x480 screen. While looking into MMS receive issues on Sprint we discovered that the MMS server actually reads these profiles, and sizes the output that it sends you based on these profiles. So even if your buddy sends you a nice high-rez photo by MMS, when you receive it, it will be scaled down to 320x480.
[edit: that's not quite true. I think this only affects the size of the image as presented in the Messaging app. The actual attachment is whatever size was originally sent. Of course, most media is scaled down for sending anyway.]
We checked to see what profile the Sprint RHOD400 was sending under Winmo and found this http://device.sprintpcs.com/HTC/PPCTP7380SP/2046514.rdf which seems to have the correct screen dimensions. (I can't seem to download it now though.)
I also checked to see what my phone was using with T-Mobile, and got this
http://www.htcmms.com.tw/gen/RhodiumMR-1.0.xml which also has the right stuff, but a lot of winmo-specific details too. It seems to me that we're going to need to patch the framework to make this profile URL a settable property instead of hardcoding it like it's currently done, to get the most out of MMS.
We should probably start taking an inventory of profiles that are in use on all the MSM devices. In Winmo you can find them in the registry at HKLM\Software\Jataayu\MMS\SP - according to this thread: http://forum.xda-developers.com/showthread.php?t=795343
For example, here's the request for a Sprint RHOD400:
Code:
GET /?msgid=XXX&userId=YYY HTTP/1.1
Accept: */*, application/vnd.wap.mms-message, application/vnd.wap.sic
x-wap-profile: http://device.sprintpcs.com/HTC/PPCTP7380SP/2046514.rdf
Accept-Language: en-US
Host: mms.sprintpcs.com:80
Connection: Keep-Alive
User-Agent: T7380
Here's the request all of our phones are currently using to retrieve MMSs:
Code:
GET /?msgid=XXX&userId=YYY HTTP/1.1
Accept: */*, application/vnd.wap.mms-message, application/vnd.wap.sic
x-wap-profile: http://www.google.com/oha/rdf/ua-profile-kila.xml
Accept-Language: en-US
Host: mms.sprintpcs.com:80
Connection: Keep-Alive
User-Agent: Android-Mms/2.0
I've got this one in the registry:
http://www.htcmms.com.tw/gen/HTC_Touch_Pro2_T7373-1.0.xml
( Rhod100 / AUO )
Mine reads:
http://www.htcmms.com.tw/gen/HTC_Touch_Pro2_T7381-1.0.xml
Also worth noting it was in the registry key:
HKLM\Software\SIE\AutoVer\Opera\User Prefs
and HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Raa_1 said:
Mine reads:
http://www.htcmms.com.tw/gen/HTC_Touch_Pro2_T7381-1.0.xml
Also worth noting it was in the registry key:
HKLM\Software\SIE\AutoVer\Opera\User Prefs
and HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Click to expand...
Click to collapse
What model RHOD is that?
This was a setup.xml I made for people running custom roms on boost mobile. Everything should be the same for sprint except the "pcs-boost-mmsc" server address. Maybe helpful?
I changed it to .txt for posting. It seems to be the same that you have.
I know this is probably way to early to be asking this, but I have a Rhod400, where can I input this info (into what file or terminal emulator?) so that I can get MMS working on my phone so I can test it until the patch is ready for the public?
slickdaddy96 said:
I know this is probably way to early to be asking this, but I have a Rhod400, where can I input this info (into what file or terminal emulator?) so that I can get MMS working on my phone so I can test it until the patch is ready for the public?
Click to expand...
Click to collapse
Kinks are being worked out, to my knowledge nothing usable has surfaced yet. Sending works like a champ with the new RIL, and reception works - just gives a useless download link. Trying to make that link work, is what we're trying to do!
We checked to see what profile the Sprint RHOD400 was sending under Winmo and found this http://device.sprintpcs.com/HTC/PPCTP7380SP/2046514.rdf which seems to have the correct screen dimensions. (I can't seem to download it now though.)
Click to expand...
Click to collapse
I appreciate all the work that you've been doing, and especially for Sprint (even though you're on a GSM device ).
That site doesn't hit (I was hoping it was user-agent dependent, but it didn't work on my phone either).
Also, this thread (http://forum.ppcgeeks.com/htc-touch-pro-2/101286-native-htc-messaging-mms-fix-collaboration-31.html) says that there's no 1st P in the PPCT7380SP string, so it looks like http://device.sprintpcs.com/HTC/PPCT7380SP/%CDMA_ROM_VERSION%.rdf. Is anyone else able to download this .rdf file?
edit: and the 2046514 corresponds to the ROM version (found in Device Information/Software), which (for me at least) is 2.04.651.4
I don't get the download button on my RHOD500. Well it's there for a split second then downloads on it's own. Originally set the APN before all the ril changes so after setting the carrier ID it just worked with the new ril.
eww245 said:
I don't get the download button on my RHOD500. Well it's there for a split second then downloads on it's own. Originally set the APN before all the ril changes so after setting the carrier ID it just worked with the new ril.
Click to expand...
Click to collapse
Wait so Verizon CDMA MMS works?
rpierce99 said:
Wait so Verizon CDMA MMS works?
Click to expand...
Click to collapse
If I'm not mistaken, Verizon has been working ever since highlandsun's amazing work on the RIL originally.
manekineko said:
If I'm not mistaken, Verizon has been working ever since highlandsun's amazing work on the RIL originally.
Click to expand...
Click to collapse
If that's the case I really need a kind verizon user to provide me a download link for a MMS attachment. It's in mmssms.db, probably easiest for that person to hop on IRC so we can chat about it. Basically I need to figure out what is different about the Sprint payload than the Verizon payload to see why Sprint doesn't work.
rpierce99 said:
Wait so Verizon CDMA MMS works?
Click to expand...
Click to collapse
For me yes, no issues at all
rpierce99: you didn't get my note on IRC I guess. I'm pretty sure the attachment isn't the problem; pretty sure the problem is the original SMS PDU. You can grab that from the radio logcat when the MMS arrives. Decoding it is a bit more of a hassle; my code in the RIL only decodes the first 6 headers then passes the rest to Android to decode. Get me a sample PDU from your radio log...
I take that back. Now I see what the parser is doing...
Is this what you need?
The pdu table has some other info but connectbot isn't being nice
GSM_PDU=000002100402070295EA216506000601FC087600031257E0016703280010099199897B9B2B93B3632BA3997B6B6B99FB6B2B9B9B0B3B296B4B21E9820A19CA099989C9899A21C9818181821A19A1818181818981880448B401A9B981C1C1A9C9A189C17AA2CA8229EA82626A7004B233BB21D10233BB21D102A32B9BA34B7338000306110516223640
Click to expand...
Click to collapse
Sprint MMS receive is now working.
Yes, thanks. But I don't need it now, already got a copy.
We actually identified the problem several days ago, there's even a fix for it already in the Gingerbread source tree. But backporting the fix to Froyo was messy. I've now made a new fix that applies cleanly to Froyo and doesn't rely on the stupid compile-time settings that Google's fix uses. rpierce99 helped to verify that it works.
Basically the MMS server software that Sprint uses is mis-formatting what it sends out. The official specification for MMS/WAP says to do one thing, Sprint's MMS server does something completely different / wrong. The Android MMS parser would just die with an exception when trying to parse these things. The fix makes it ignore the improper header. There are other things that Sprint's server does that are also questionable. Even with this fix, if you want someone to send you an image or video in an MMS, make sure they don't type any text into the message body, otherwise it will still arrive messed up.
OK, the issues with displaying MMS image+text messages are resolved now too. And I've made the uaProfURL a settable property in case you want to override the compiled-in setting. set the ro.product.uaprofurl property to the URL you want to use.
Of course, you need to be running my patches to the Mms.apk for this to work. The source code is here https://gitorious.org/hycdroid/packages_apps_mms/commits/froyo
Full description of the Sprint bugs and the fixes: http://lists.xdandroid.com/pipermail/xdandroid-dev/2011-May/000288.html
So what was the initial problem here?
*scratches head*
MMS always physically worked fine for me. (your RIL)
Was it just an issue displaying the contents I never picked up on or...?
ryannathans said:
So what was the initial problem here?
*scratches head*
MMS always physically worked fine for me. (your RIL)
Was it just an issue displaying the contents I never picked up on or...?
Click to expand...
Click to collapse
Did you read his post? It's a Sprint-only issue. Always was (after his RIL).
Might want to look at this section of his post...
highlandsun said:
Full description of the Sprint bugs and the fixes: http://lists.xdandroid.com/pipermail...ay/000288.html
Click to expand...
Click to collapse
/facepalm...
Had a few late nights and unknowingly started reading from page 2.
Hello,
Does anyone know if there is a way to change the standard name format Google gives images: IMG_20160101_121728.jpg to something else like N5X_01Jan16_12.45.11.jpg? I found one app that seems to do this after the fact here: https://play.google.com/store/apps/details?id=ro.ciubex.dscautorename
I was just wondering if there was another native way in-camera phone to do it? Or is there another app some recommend?
Lastly, does anyone know what the last set of digits represent in the name? I know the first represent the date.
Thanks,
Derek
dereksurfs said:
Lastly, does anyone know what the last set of digits represent in the name? I know the first represent the date.
Click to expand...
Click to collapse
The time, in 24-hour format.
I doubt there's any way to change the name format. You could whip up a shell command to change them.
the standard camera app does not have an option for that.
also, as crachel pointed out, the second set of digits is the time of recording in 24h format.
this way the values are all ordered from largest to smallest (Y/M/D_H:M:S) and therefor will always be in chronological order.
as you see the file names include already everything you want (apart from the N5X part), just in numerical form, and in an order that is at least for machines easier to work with.
if you still want another format i'd be curious of what you would expect from that.
Interesting, when I looked at the last set of numbers, they did not match the timestamp of the file system. So I thought they were just random unique numbers. But if I look at EXIF data on Google Photos, the time looks correct. So, at least they provide more meaningful information than I initially thought. I would still prefer a more reader friendly format like the one I posted above for my own archival purposes. IMG is too generic as I have many cameras along with their associated images. I could care less what Google or anyone thinks is machine friendly. I program for a living and know user experience trumps whatever someone assumes is easiest on a computer. Plus, a computer can read any format since its simply a date pattern. I just prefer another pattern.
I've looked into the last 6 numbers too. In my findings it's the second when the photo/video was taken/started recording. Same for exif. The filesystem contains the second when it was finished written to "disk".
Also sometimes you get _1, _2, ... after that if more photo was recorded in the same second.
After doing hours of searching and reading I found I'm not the only person that faces this issue, but many have solved this issue by editing the mms_config.xml inside res/xml/.
I've changed the "maxMessageSize" and also "maxImageHeight" and "maxImageWidth" to a variety of different numbers (up from stock 640x480), and it HAS made some difference, however neither max image size nor image resolution is being reached and my resulting MMS is still somewhat blurry. I recall fixing this issue fully for my S4 back in the day with 0 resulting blur but I must be missing something else in the apk here.
I'm thinking the uaProf and UserAgent strings may have something to do with it, but any strings I've managed to find via google make no difference at all to the size/quality of the outgoing MMS.
Looking for a native solution and not "use handscent/gosms instead" alternatives, seen these suggestions as "fixes" in almost every thread related to this.
If anyone is aware of anything else I can test or a different xml file in the apk that can be tweaked would appreciate it.
Carriers max MMS is 1.2MB but even 300-400kb images are being compressed to 70kb but like I said it has made a difference, just that the numbers I'm entering aren't being respected fully
Thanks
Meanwhile a friend of mine on the same carrier can send me a crystal clear image in almost 2k resolution from an iphone. Just standard MMS nothing 3rd party, if they can do it why should Google's official Android messaging app be so terrible to such an extreme degree. 640x480 found in the stock mms_config.xml is almost unbelievable when the network is capable of transmitting over 3x that resolution