Related
The current lag-fixes optimize application load times by changing the filesystem for "/data", and with that fix the phone does become a lot more responsive.
With /data optimized, I still notice a pretty bad lag when opening anything database related or cache related, for example: Adding a shortcut to the homescreen takes a good 15 seconds to load the list, I tried the same thing in a Droid X and it's instant... LauncherPro stalls everytime you do something for the first time, and then works ok, it loads animations to the cache so... (write times to cache maybe?)
Any thoughts on this? I haven't done all the research, so these are just my observations. (I've seen this with OneClick lagfix ext2, chainfire's 1.80 ext2 and ext4, and Tayutama's ext2 and ext4, on JM5, 6 and 7).
Another problem I have seen is the low ram lag, as soon as the phone dips under ~70MB of ram it becomes extremely sluggish, I haven't used a single firmware where I don't need autokiller with aggressive settings, again comparing to a nexus one or droid x, those phones work flawlessly with ~30MB free...
I haven't tried the Vooodoo lag fix, does that or any other lag-fix address this issues?
When I was running mimocan, I also moved/symlinked /dalvik-cache and /media to the external ext4 partition. Don't know how much it improved things, though.
Seems like running autokiller really is enough to address the memory management issue, maybe we'll see those settings tweaked in future firmwares.
aeo087 said:
The current lag-fixes optimize application load times by changing the filesystem for "/data", and with that fix the phone does become a lot more responsive.
With /data optimized, I still notice a pretty bad lag when opening anything database related or cache related, for example: Adding a shortcut to the homescreen takes a good 15 seconds to load the list, I tried the same thing in a Droid X and it's instant... LauncherPro stalls everytime you do something for the first time, and then works ok, it loads animations to the cache so... (write times to cache maybe?)
Any thoughts on this? I haven't done all the research, so these are just my observations. (I've seen this with OneClick lagfix ext2, chainfire's 1.80 ext2 and ext4, and Tayutama's ext2 and ext4, on JM5, 6 and 7).
Another problem I have seen is the low ram lag, as soon as the phone dips under ~70MB of ram it becomes extremely sluggish, I haven't used a single firmware where I don't need autokiller with aggressive settings, again comparing to a nexus one or droid x, those phones work flawlessly with ~30MB free...
I haven't tried the Vooodoo lag fix, does that or any other lag-fix address this issues?
Click to expand...
Click to collapse
aeo087 said:
The current lag-fixes optimize application load times by changing the filesystem for "/data", and with that fix the phone does become a lot more responsive.
With /data optimized, I still notice a pretty bad lag when opening anything database related or cache related, for example: Adding a shortcut to the homescreen takes a good 15 seconds to load the list, I tried the same thing in a Droid X and it's instant... LauncherPro stalls everytime you do something for the first time, and then works ok, it loads animations to the cache so... (write times to cache maybe?)
Any thoughts on this? I haven't done all the research, so these are just my observations. (I've seen this with OneClick lagfix ext2, chainfire's 1.80 ext2 and ext4, and Tayutama's ext2 and ext4, on JM5, 6 and 7).
Another problem I have seen is the low ram lag, as soon as the phone dips under ~70MB of ram it becomes extremely sluggish, I haven't used a single firmware where I don't need autokiller with aggressive settings, again comparing to a nexus one or droid x, those phones work flawlessly with ~30MB free...
I haven't tried the Vooodoo lag fix, does that or any other lag-fix address this issues?
Click to expand...
Click to collapse
Nope, Voodoo doesn't address it either. /dbdata acts strangely if you try to mess with it and seems to cause some strange issues, which is why it has been left out of fixes so far. Plus, /dbdata is on very fast NAND which doesn't suffer so much as the sdcard from RFS.
Low ram lag is probably touchwizz related, or if not touchwizz, than some other badly done Samsung modification. Unfortunately that kind of thing is very hard to find. It could be something completely unrelated though, like a badly made driver that behaves badly when RAM is low.
RyanZA said:
Nope, Voodoo doesn't address it either. /dbdata acts strangely if you try to mess with it and seems to cause some strange issues, which is why it has been left out of fixes so far. Plus, /dbdata is on very fast NAND which doesn't suffer so much as the sdcard from RFS.
Low ram lag is probably touchwizz related, or if not touchwizz, than some other badly done Samsung modification. Unfortunately that kind of thing is very hard to find. It could be something completely unrelated though, like a badly made driver that behaves badly when RAM is low.
Click to expand...
Click to collapse
Am I right to say that that lag when adding a shortcut or accessing the list of apps comes from dbdata? why is the phone so slow at pulling up that information? Also, have you seen any performance benefit from optimizing the cache partition?
Given that the samsung froyo update has been delayed another month from what i have heard, i've decided that i might as well use a lagfix until froyo comes along.
Given that there are so many lagfixes, some old some new, and i have no idea which is good and which is new.
Could someone tell me which lagfix works the best?
and if possible also point me to a guide here or out there in the www.
thanks
Voodoo if you are on Eclair. OCLF if you are on Froyo.
But I am not running any from yesterday on my JPH. So far so good. Quadrant 1008.
Trust no one of them fixes... <insert mysterious music>
All the so called Lag Fixes do really work, BUT you might ruin your internal SD card in the process.
If you are willing to take the chance, then by all means go ahead and DO iT the speed increase is really amazing
However... expect your internal SD to die quickly as a result of that.
It's like a drug you know, just the same stuff some athretes takes to get an energy boost at the cost of their health.
AllGamer said:
Trust no one of them fixes...
All the so called Lag Fixes do really work, BUT you might ruin your internal SD card in the process.
If you are willing to take the chance, then by all means go ahead and DO iT the speed increase is really amazing
However... expect your internal SD to die quickly as a result of that.
It's like a drug you know, just the same stuff some athretes takes to get an energy boost at the cost of their health.
Click to expand...
Click to collapse
How is it destroying internal sd card ?
Sent from my GT-I9000M
if you search for SD problem here in the forum, all the topics that comes back states they were either using lag fix for a while, installing lag fix, or something else to do with lag fix
So you're trying to say that rfs file system which is reading and writing on sd also isn't destroy the internal sd?
Sent from my GT-I9000 using Tapatalk
what ever it's the slow rfs used by Samsung is at least less invasive than the methods we are currently using for the Lag Fixes
i'm not a developer, but if i were to fix what is wrong right now, i'll go with a virtual RAM drive solution.
that's how i configured old win2k servers and Win9x/XP machines
by avoiding write to a real disk it prevented delay, and that improved speed drastically even on low end machines
back in the SGS phone we are stuck with 512 RAM, so wasting more ram on a virtual drive might not be a good idea, but if we even setup a "cache" drive of 128 MB RAM instead of writing to the partitioned internal SD, that will kill 2 birds at once
improve speed and prevent SD write exhaustion
I'm still not yet at the point of being annoyed by the lag, else it would have been a big motivation to implement the idea mentioned above.
the only time i get lag is when i install 2 ore more Android Apps from Market simultaneously, like when there are updates for 5 or more products and you click OK on all of them.
normal daily operations has not shown any delay at all.
my only trick is i prevent any unwanted background services from starting with the phone.
i use the original lag fix that adds a logical link from /data/data to /dbdata.. have not read this causing any problems with corrupt sd cards as it is not changing partition type or anything.. the only drawback is the size is limited.. but as long as you dont install huge games i have over 100 apps with no problems ie..
not as high benchmarks as some of the others (but i belive they are artificial anyway) and the phone is fast and hardly ever lags..
try running k9-mail without it and it takes about 5 minutes to go through all my mailboxes versus about 30 sec.
C:\galaxy>cat speedtweak.sh
#!/system/bin/sh
## this script is made by deckcard##
## clean up csc folder
echo
echo Speed tweaks that move data from mmc to nand
echo
echo busybox cp -rp /data/data /dbdata >> /sdcard/1.sh
echo mv /data/data /data/data.bak >> /sdcard/1.sh
echo ln -s /dbdata/data /data/data >> /sdcard/1.sh
echo reboot >> /sdcard/1.sh
su</sdcard/1.sh
rm /sdcard/1.sh
theres tons of different fixes, some are better than others, but its all personal preference...and also, some of them just improve your quadrant score and not real life performance.
Would any dev or anyone who knows a bit about compiling be able to do this? I've tried some other kernels, and generally love some of the features and performance they bring, but none of them has been 100% stable for me. Stock kernel is 100% stable, but lacks the 5 point multitouch which I do use for emulators, and GPU+ which makes a noticeable difference in 3D graphics smoothness.
The closest I found was HeyItsLou's #8 (I might have the number wrong) which runs great, has the multitouch, but no GPU+ Lou's has some other good features that seem to help smoothness and battery life too.
Maybe Lou or someone could throw GPU+ into that kernel? Or just take the stock kernel and add GPU+ and multitouch? Would anyone else be interested in this?
Um what about the. 32 incredikernel?
Sent from my ADR6300 using XDA Premium App
That's what I'm running now but it will randomly peg the CPU (system panel shows Android System as maxed out) and slow the phone to a crawl, requiring a reboot. And no, I'm not running SetCPU. That is the ONLY problem I have with that kernel, but I've never had that happen on the stock kernel. I don't want to deal with the random lockups anymore.
Ziggy's kernel doesn't have the lock ups, but doesn't run as smooth either, and I notice a lot of stutters while gaming.
I don't know why that would be. I compiled it for someone a few days ago and he loves how it runs.
Sent from my ADR6300 using XDA Premium App
what is 5pt multi touch?????
jdog94 said:
what is 5pt multi touch?????
Click to expand...
Click to collapse
Just that, you are able to use five fingers (or "points") simultaneously.
From my understanding, multitouch is affected by the touch panel you have, and also the way it is flashed. There was a compatible recovery floating around a while ago, but it's no longer maintained.
Yeah not all phones support 5pt
Sent from my ADR6300 using XDA Premium App
Phydo - I've actually been running your undervolted version of Chad's kernel for the last few days. I'm still having the same issue. In Chad's thread, there were actually a few people having the exact same issue. It was thought that SetCPU was somehow to blame, but again, I don't even have that installed.
From a performance standpoint, Chad's kernel is the one I've had the best results with and keep going back to, but this issue with the CPU getting stuck at 100% load happens regularly, every 24-48 hours.
bast525 said:
Phydo - I've actually been running your undervolted version of Chad's kernel for the last few days. I'm still having the same issue. In Chad's thread, there were actually a few people having the exact same issue. It was thought that SetCPU was somehow to blame, but again, I don't even have that installed.
From a performance standpoint, Chad's kernel is the one I've had the best results with and keep going back to, but this issue with the CPU getting stuck at 100% load happens regularly, every 24-48 hours.
Click to expand...
Click to collapse
I'd be willing to bet your problem is the ProcessStats.java bug documented in Issue 9733. It is exacerbated by kernels that add extra frequencies. Some ROMs work around the issue by making the time_in_state file unreadable, but SetCPU undoes this workaround every time you open it. 24-48 hours seems about right for the time it was taking for me to run into this problem. I'm now running with an init.d script that redoes the chmod 600 every 5 minutes just in case I open SetCPU and the problem has gone away.
Aweaver33 - would this be something I could easily incorporate into my own ROM? I'm running a mostly stock ROM that I customized by adding an earlier Evo framework and taking out some stuff I didnt want. Would I be able to flash your init.d script? Or since I don't run setcpu, could you explain or point me somewhere I could figure out how to make time_in_state unreadable?
EDIT: nevermind.... aweaver you are awesome for posting that link. I will try to chmod the time_in_state file as outline in that thread and see if I can make it 48 hours without it making the cpu.
Do you know how specifically this is kernel related? I've had this issue with Chad's kernel, and the old KingKlick kernels. I have NOT had the issue on the very old Hydra kernel or any of the stock kernels. I guess its just the number of frequencies they enable? Man if chmod'ing that file is all it took to fix that bug.... you are my friggin hero dude. I've been mostly using Chad's kernel since December and love it but MAN I hated the phone locking up every two days!
bast525 said:
Do you know how specifically this is kernel related? I've had this issue with Chad's kernel, and the old KingKlick kernels. I have NOT had the issue on the very old Hydra kernel or any of the stock kernels. I guess its just the number of frequencies they enable?
Click to expand...
Click to collapse
Yeah, it's mostly just the number of frequencies they enable. Also a potential, but smaller, contributor would be governor settings that result in a more even distribution of frequencies, which would result the overall file size getting larger more quickly. I first noticed this issue when I was doing stability testing that intentially created an even distribution of frequencies and made it less than a day before triggering the bug.
Well, I'm at 36 hours of running now, so far no issues. I did open the time in state file and noted it is still updating, though the permissions were correctly changed.
My only problem now is the leaked GB roms that popped up today... I want to flash one but I REALLY want to see if after six months of dealing with this very annoying bug, if it is finally fixed. I gonna TRY to resist flashing til tomorrow.
Any way to make the change in permissions to the time in state file stick? It undoes the changes on reboot
bast525 said:
Any way to make the change in permissions to the time in state file stick? It undoes the changes on reboot
Click to expand...
Click to collapse
That's where the init.d script comes in. Put the following in a file in /etc/init.d/ and set permissions to 755:
Code:
#!/system/bin/sh
while [ 1 ]; do
chmod 400 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
sleep 300
done
If there is no /etc/init.d folder, and I create and throw that file in there will it work?
EDIT: nevermind... tried it, didn't work. Created the folder, put the file I'm there, rebooted. Let phone sit five mins, looked at permissions for time in state file, they were still at default. Does it need to have an extension? I just named it "fix".
Sorry, it looks like the /etc/init.d/ directory is not standard Android. The following is the last line in my /bootcomplete.inc.rc file, which looks like what enables running the scripts in the /etc/init.d directory:
Code:
/system/xbin/busybox run-parts /system/etc/init.d
I'm not sure if that line was automatically added when I installed busybox, or if something else put it there.
It's cool, I found an alternate method. There's a very small app in the market simply called "Autostart", to use it you create a script, name it autostart.sh, drop it in a folder you create in /data/, and it runs at boot same as if it were in init.d. I took your script and modified it a bit to make it not repeat every 300 seconds. I don't run SetCPU so I only need it to run once at start up.
I still haven't let the phone run for 48 hours straight to verify this fixed it, but still man thank you for the info, it is greatly appreciated. After reading that Google bug thread you linked, I have very high hopes that this is the fix I've been looking for for six months now.
Thanks again man and I'll report in a day or two as I have no more reasons to reboot for a while.
48 hour mark just passed and still running like a champ
If anyone could help me out here I will love you LONG time:
I am wondering id I should set up a swap partition and use it with this script (apps/data 2 ext, supports swap). I am starting fresh on my Nexus One installing a Gingerbread MIUI ROM using this script for the first time. I was wondering if I should use a SWAP with my class 4 16gig sd card. I will have a 1gb EXT partition. If anyone could state simple pros/cons I would MUCH appreciate it. I have heard good but mostly bad about swap on gingerbread saying that it is not needed and can cause bad.
Does the N1 really need SWAP with Gingerbread? I'm shaking in my pants posting this but I have not seen any related articles, let alone for the N1. I have done a Google search but that doesn't help, it confused me more if it is worth it.
Thanks again. Deuces.
There are some comments from experienced users here on swap, most are against. Here is a link that has a lot of comments--
http://zerocredibility.wordpress.com/2009/08/24/why-android-swap-doesnt-make-sense/
I am no android tech, but never used and don't have issues. I run a lot of apps over a hundred from the Market alone
Thanks! Exactly what I needed. No SWAP for me!
Glad to help--
I'm no expert either. But I do have a 256MB swap partition.
Swap *should* only be used when physical memory is low, and more is still needed by the system. If you're low on memory and need more, then swap might be useful then.
There's a kernel setting called "swappiness". I have this set to a low setting "5", which I believe means that swap should only be used as a last resort i.e. more importance is put on using physical memory over swap.
Yes swap is slower. If a system is swapping out, then it's logical to add more physical memory to the system. However as we cannot upgrade physical memory on our phones, so I suppose swap is the next best thing.
Anyhow that's just my personal thinking. My Nexus is running sweet and I don't notice any considerable slowdowns. However perhaps my swap has never really been required?!
Swap is made for desktop OS, where there is such thing as "lack of memory".
Such thing doesn't exist on Android, mobile OS of completely different design.
The reason is - desktop OS can't kill the tasks you've left running. Mobile OS can, and will, once it senses that it needs more memory. And the tasks themselves are built to be killed.
Adding SWAP is fooling Android that it has more actual memory than there really is - and the OS is using it like it was real memory, not killing tasks when it should. And while doing that, SWAP is far slower than just killing and reloading tasks - because it requires writing to and reading from the SWAP partition the whole app, while when killing and loading it, only reading is required - making the process MUCH faster.
I believe that's the essence of the earlier reference.
Shortly, unless there is severe lack of RAM (and on N1 there isn't by any parameters) - SWAP will make things worse, not better.
By activating compcache (~18% should do), and kernel samepage merging, there is no need for swap. I think texasice confirmed this, although I am not sure.
Sent from my Nexus One using Tapatalk
I would never use swap for GB. Tough there is discussion of using it on ICS, the few times I have tried it I did not use it.
I used swap a long time ago on CM6 or early 7 and there was absolutely no benefit in my opinion. Doesn't swap force more read/write times on SD which can decrease the life as well? That's just my $0.02.
TheAndroidStop said:
I used swap a long time ago on CM6 or early 7 and there was absolutely no benefit in my opinion. Doesn't swap force more read/write times on SD which can decrease the life as well? That's just my $0.02.
Click to expand...
Click to collapse
Swap isn't useful when it's not being used, and FroYo or Gingerbread hardly uses that much RAM. ICS, however, with its full hardware acceleration, is a real memory hog. Now, though, if we enable kernel samepage merging and a zram amount of like 18%, we wouldn't need a swap partition. Like it's been said before, swap is very slow, much slower than actual RAM.
Sent from my Nexus One using Tapatalk
Swap seems as use full as a taskiller in Android....
Sent from my Nexus One using xda premium
Hello, does not swap hard Android phone for auxiliary memory damage the hard?
Hello everyone,
I was pretty tired of the eMMC error, and I created a script that completely annihilate this error.
This error is due to the phone heating up, and the fact that custom kernels (maybe even the original kernel) don't read the sensors correctly and throttle the phone correctly. This script monitors the battery and all the CPU sensors and when it is higher than 82°C, throttle the phone.
It was tested on AEL Kernel that supports « Hard limit » command, but this script can be adapted on any other kernel. You may need busy box. You must root to run this script.
Must be placed in init.d folder.
You simply copy each script, and for example with Kernel Audiutor, create a new init.d and paste the script with the correct title.
script called cpu_temperature_daemon :
Bash:
#!/system/bin/sh
argu=$1
sleeptime=15
if ! [[ $argu = start ]] then exit ; fi
lock=0
while true;
do
maxnumb=0
cpuiscool=0
temp=$(cat /sys/class/thermal/thermal_zone*/temp)
tempbat=$(cat /sys/class/power_supply/battery/batt_temp)
if ((tempbat>410)) then if [[ $lock = 0 ]] then lock=1 ; sleeptime=7 ; chmod 644 /sys/devices/system/cpu/cpu1/online ; echo 1 > /sys/devices/system/cpu/cpu1/online ;chmod 444 /sys/devices/system/cpu/cpu1/online ; echo 65 > /sys/module/msm_thermal/parameters/core_limit_temp_degC ; echo 65 > /sys/module/msm_thermal/parameters/limit_temp_degC ; fi ; fi
for line in $temp; do if ((line>78)) then if ((line<120)) then if [[ $lock = 0 ]] then lock=1 ; sleeptime=7 ; chmod 644 /sys/devices/system/cpu/cpu1/online ; echo 1 > /sys/devices/system/cpu/cpu1/online ;chmod 444 /sys/devices/system/cpu/cpu1/online ; echo 65 > /sys/module/msm_thermal/parameters/core_limit_temp_degC ; echo 65 > /sys/module/msm_thermal/parameters/limit_temp_degC ; fi ; fi ; fi ; if ((line>10)) then if ((line<110)) then maxnumb=$(($maxnumb+1)) ; fi ; fi ; if ((line>10)) then if ((line<75)) then cpuiscool=$(($cpuiscool+1)) ; fi ; fi ; done
if [[ $maxnumb = $cpuiscool ]] then if ((tempbat<411)) then if [[ $lock = 1 ]] then lock=0 ; sleeptime=15 ; chmod 644 /sys/devices/system/cpu/cpu1/online ; echo 1 > /sys/devices/system/cpu/cpu1/online ;chmod 444 /sys/devices/system/cpu/cpu1/online ; echo 82 > /sys/module/msm_thermal/parameters/limit_temp_degC ; echo 82 > /sys/module/msm_thermal/parameters/core_limit_temp_degC ; fi ; fi ; fi
sleep $sleeptime ;
done
script called cpu_temperature_daemon_start to place in the same directory /system/etc/init.d/ :
Bash:
#!/system/bin/sh
numb=$(pgrep -lf cpu_temperature_daemon | wc -l) ; if [[ $numb = 1 ]] then exit ; fi
echo 75 > /sys/module/msm_thermal/parameters/core_limit_temp_degC ; echo 75 > /sys/module/msm_thermal/parameters/limit_temp_degC
nohup /system/etc/init.d/cpu_temperature_daemon start &
There is absolutely no more eMmc errors on the Note 4 that I tested. Of course, if you already have the error, script will not fix it. It will simply prevent a clean phone from having it by preventing overheat in monitoring all sensors. No big battery hog (insignificant). The script works by monitoring the all the sensors and reducing slightly CPU performance when the phone CPU is to hot (CPU > 82°C), or battery temp > 41°C.
If you don't game then the emmc thing won't happen right?
It will happen eventually, it is due to the phone overheating (it is not just heating, it is overheating due to the sensors not correctly reporting temperatures) so even opening Facebook will make it overheat
juandante said:
It will happen eventually, it is due to the phone overheating (it is not just heating, it is overheating due to the sensors not correctly reporting temperatures) so even opening Facebook will make it overheat
Click to expand...
Click to collapse
How do i fix a phone that has it? The "put cardboard under EMMC" fix lasted for like a week, my phone still works thanks to that Fix by using WakeLock (already it's been 8 months i think), but i don't want to use WakeLock anymore because it drains the battery a lot, plus since the eMMC is faulty the writing speeds are like 40MB/S so the phone is significantly slower.
I heard that this error was caused by Android 6 and immediately after i got the phone i flashed Android 5 stock, still i got like 6 months of use before this error (mostly only using Youtube and Discord).
Can i get the eMMC replaced to fix this? or i need an entire new motherboard? this phone is still really fast and usable even in 2023 with Android 5, but this error is really annoying and it makes the phone almost unusable, thanks.
juandante said:
It will happen eventually, it is due to the phone overheating (it is not just heating, it is overheating due to the sensors not correctly reporting temperatures) so even opening Facebook will make it overheat
Click to expand...
Click to collapse
If i end up getting another used Note 4 i will downgrade to LL and immediately apply your script
jonnyprogamer said:
If i end up getting another used Note 4 i will downgrade to LL and immediately apply your script
Click to expand...
Click to collapse
Yes, you simply have to copy paste each script in the /system/etc/init.d/ directory
I have put the correct tags and the script is now correctly highlited in my first post so you can easily see what it does.
Maybe for some kernels, you will need to adapt it.
Anyway, I can confirm to you that this limits dramatically the eMMC errors because the phone doesn't anymore overheat.
juandante said:
Yes, you simply have to copy paste each script in the /system/etc/init.d/ directory
I have put the correct tags and the script is now correctly highlited in my first post so you can easily see what it does.
Maybe for some kernels, you will need to adapt it.
Anyway, I can confirm to you that this limits dramatically the eMMC errors because the phone doesn't anymore overheat.
Click to expand...
Click to collapse
Ok thanks, but is there anyway to fix this error on a Note 4 that already had it? maybe reballing the eMMC?
I don't think it's worth to me to get another used Note 4, because i don't know what the previous owner might have done with it and it might already be dead to be honest.
I think that reballing the eMMC / swap the motherboard is the only way to truly fix this (and then use your script or downclock the CPU to keep the phone safe)
jonnyprogamer said:
Ok thanks, but is there anyway to fix this error on a Note 4 that already had it? maybe reballing the eMMC?
I don't think it's worth to me to get another used Note 4, because i don't know what the previous owner might have done with it and it might already be dead to be honest.
I think that reballing the eMMC / swap the motherboard is the only way to truly fix this (and then use your script or downclock the CPU to keep the phone safe)
Click to expand...
Click to collapse
You must have high end specialized soldering tools to fix the problem. Anything less than that will just fix the issue couple of weeks only if you are very lucky. You will be more lucky to buy a second hand Note 4 because most people generally speaking sell it because they bought a new phone, not because of the eMMC error due to heavy phone usage... If you really want to save money, just buy a new motherboard (it's somewhat cheap today).
Also, I think I had a eMMC symptom once (slow phone and the Note 4 was hardly booting), I managed with luck to boot the phone then applied the script, waited 1 day with the phone keeped on, and next the phone stayed somewhat fully usable for 12 months (with some random reboots now and then). So I think if you apply the script enough early when you get the first bad eMMC sign it is somewhat enough early to "revert" the issue if I could say so. I. E. The soldering is somewhat damaged and provoke random reboots but the script will prevent the phone from heating and damage even more the soldering.
juandante said:
You must have high end specialized soldering tools to fix the problem. Anything less than that will just fix the issue couple of weeks only if you are very lucky. You will be more lucky to buy a second hand Note 4 because most people generally speaking sell it because they bought a new phone, not because of the eMMC error due to heavy phone usage... If you really want to save money, just buy a new motherboard (it's somewhat cheap today).
Click to expand...
Click to collapse
Thanks, i guess i will try to find another Note 4, i might know someone that knows how to do BGA reballs, but even then i think that the issue are not the solder balls under the E-MMC.
Because it doesn't make sense, un-leaded solder melts at about 215C, and the EMMC isn't a big chip (so it's not like a GPU which can ""stress"" the solder balls when it gets hot and then cold).
For this reason alone it can't cause any cracks in the balls (unless you drop the phone but then again it's pretty unlickely to happen), what im thinking is that the EMMC chip just dies, it's not the solder beneath it, it's either a fault in the chip itself or a bug which gets triggered by something (like the Note 1 Superbrick).
Maybe we should take apart our phones with the issue, check the model number and report it here, probably those will be the fauly chips (this issue happened on the 360 and PS3 as well, everyone saying "it's the solder" and instead it was the GPU itself which dies because of the heat-cooling cycles).
You have a video tutorial on how to do this ?
Also the stock rom doesn't have init.d support.
dave678 said:
Also the stock rom doesn't have init.d support.
Click to expand...
Click to collapse
I know that PimpMyRom adds init.d support (tested on old chinese Android ICS tablet), i don't know if it works with Lollipop tough.
I just got my emmc reballed, when i get my phone back im gonna reflash latest 5.1.1 Or CM and use this script.
We will see if it lasts since the reball has been done with leaded solder, if it does not then it means that the fault was (and still is) the EMMC chip all along :=>
jonnyprogamer said:
I know that PimpMyRom adds init.d support (tested on old chinese Android ICS tablet), i don't know if it works with Lollipop tough.
I just got my emmc reballed, when i get my phone back im gonna reflash latest 5.1.1 Or CM and use this script.
Click to expand...
Click to collapse
Oh I have a brand new Sprint Note 4 running Kitkat and a Tmobile Note Edge running Kitkat
dave678 said:
Oh I have a brand new Sprint Note 4 running Kitkat and a Tmobile Note Edge running Kitkat
Click to expand...
Click to collapse
I have the unlocked international Europe version (SM-N910F) from italy (ITV CSC)
Android 4.4 stock uses the less resources of all but it's not smoother / faster than LL
Android 5.0.1 IS faster / smoother than 4.4, but uses more resources and it isn't optimized + very bad battery usage
Android 5.1.1 is the best stock from what i tested, less resources than 5.0 and good battery usage, also compatible with most apps from today.
Android 6.0.1 stock runs the worst (and according to a lot of people it was making the Emmc quickly because of the new hibernation when you turn off the display)
My reccomendation would be to either use stock Samsung 5.1.1 ROM or a Custom ROM (Cyanogenmod, Lineage, etc...)
jonnyprogamer said:
Android 4.4 stock uses the less resources of all but it's not smoother / faster than LL
Android 5.0.1 IS faster / smoother than 4.4, but uses more resources and it isn't optimized + very bad battery usage
Android 5.1.1 is the best stock from what i tested, less resources than 5.0 and good battery usage, also compatible with most apps from today.
Android 6.0.1 stock runs the worst (and according to a lot of people it was making the Emmc quickly because of the new hibernation when you turn off the display)
My reccomendation would be to either use stock Samsung 5.1.1 ROM or a Custom ROM (Cyanogenmod, Lineage, etc...)
Click to expand...
Click to collapse
You have the F model which is hard to find on Ebay and you can yo yo between different firmware. The closest model to the F would be the W model which can also yo yo between different firmware. My model cannot do that as once you go up to 5.1.1 you can kiss goodbye the ablity to downgrade to Kitkat. I have it as a collector's item basically. It's not my daily driver as it wouldn't work on my carrier anyways.
dave678 said:
You have the F model which is hard to find on Ebay and you can yo yo between different firmware. The closest model to the F would be the W model which can also yo yo between different firmware. My model cannot do that as once you go up to 5.1.1 you can kiss goodbye the ablity to downgrade to Kitkat. I have it as a collector's item basically. It's not my daily driver as it wouldn't work on my carrier anyways.
Click to expand...
Click to collapse
Ah i see, well i got mine from a local online marketplace here in Italy (Subito), before i bough it on Ebay and it was "brand new", but it turns out it was just the SM-N910V version with the F firmware (found out quickly because US bands aren't the same in Italy, so i had connection issues) so i did a refund.
If you're in US yea i think it's going to be pretty hard to find an Europe model.
I use mine as daily driver, SD card, removable battery, IR blaster, easy to take apart, it's still a really good phone.
jonnyprogamer said:
Ah i see, well i got mine from a local online marketplace here in Italy (Subito), before i bough it on Ebay and it was "brand new", but it turns out it was just the SM-N910V version with the F firmware (found out quickly because US bands aren't the same in Italy, so i had connection issues) so i did a refund.
If you're in US yea i think it's going to be pretty hard to find an Europe model.
I use mine as daily driver, SD card, removable battery, IR blaster, easy to take apart, it's still a really good phone.
Click to expand...
Click to collapse
I'm curious as to why the S5 doesn't suffer from the emmc issues as the Note 4 Snapdragon models since it also uses Emmc 5.0 like the Note 4.
dave678 said:
I'm curious as to why the S5 doesn't suffer from the emmc issues as the Note 4 Snapdragon models since it also uses Emmc 5.0 like the Note 4.
Click to expand...
Click to collapse
No idea, either it's actually the solder (doubt it, unleaded solder is more prone to cracks and breaking but melting temp is much higher than what the phone will allow) or buggy firmware / bios from samsung (already happened with Samsung Galaxy Note 1 with the Superbrick bug)