Develop Bugs

[UTIL][DISCONT'D] CFLagFix 1.90 (ext2+ext3+resize+uninst support)

THIS TOOL HAS BEEN DISCONTINUED. IF YOU REALLY NEED A LAGFIX, USE VOODOO. HOWEVER, WITH LATEST ROMS I DONT PERSONALLY FEEL A LAGFIX IS STILL NEEDED, THUS I DON'T USE ONE, AND WILL NOT CONTINUE DEVELOPING ONE
About
Here it is, yet another LagFix tool. It's certainly not the first, but it does offer some things others do not (at the time of this writing).
This patch uses the ext2/ext3 image in /data method.
IMPORTANT NOTICE FOR FROYO USERS
(1) Use ext2. ext3 is NOT supported on Froyo, only Eclair
(2) The installation will fail if you apps installed to SD. Go to Settings -> Applications -> Manage -> On SD card. Click each app and click "Move to phone". In the end, the "On SD card" list should be empty. Reboot. Install CFLagFix. When the fix is installed, you can move apps back to the SD card if you wish.
Features
- Lots of checks to make sure the fix is possible
- This is not just based on a script, but a lot of commands are performed and their results rigorously checked to be what is expected
- You can select (from a set of presets) which folders you want to lagfix
- You can select how big the image should be (between 128mb and all the free space in /data minus 250mb, to prevent low storage space warnings)
- The actual moving of data from RFS to the image is done in a boot loop, while the files are not in use. This minimizes the chance of corruption during move (settings being lost, etc)
- Comes with e2fsprogs, and e2fsck is performed each boot to fix a corrupted image
- Comes with it's own busybox, so no need to install it, and no chance for conflicts
- If an ext2 image is used, it is tuned to not reserve any blocks
- If an ext3 image is used, it is tuned to not reserve any blocks and use journalling
- Also moves databases (safely)
- Uninstall option
- Resize option, resize your partition whenever you want, to whatever (possible) size you want
- "Full automatic" option, this will max out the image size while still preventing the low storage space warning, and will also reclaim the space from the backup folders and automatically resize the image to max again after that space is reclaimed. This generally results in an image of about 1.5 GB. It'll also leave some space in case the system still needs to write in /data but not in the image.
- Progress monitor ("educated guess" about progress, not exact, but pretty close, usually!)
A fair number of these seem to be unique at the time of this writing.
Notes
- e2fsck result is stored in /data/cflf/e2fsck_result.txt
- list of mounted directories is stored in /data/cflf/mountlist.txt
- if ext3 is used /data/cflf/imageisext3 file will be present
- my own test rom is JM2+root-with-update.zip+ClockworkMod
Known issues
- In case the image is heavily corrupted, e2fsck may take longer to fix it than the rest of the boot process. Theoretically this could result in data loss
- ext3 does not seem to be supported on Froyo ROMs JP1/JP2/JP3
Credits
- mimocan, ykk_five, RyanZA, and all others who have chipped in for various lagfixes
- cynogen, e2fsprogs built for ARM
- kalpik, busybox APK
- ofcourse the original authors of those tools as well
- myself, this is all based on ADB Magic code
Donations
Please feel free to donate: http://www.jongma.org/dx.php
Requirements
- Windows
- Microsoft .Net 3.5 framework
- Phone in USB debugging mode
- SuperUser
Before using ...
I strongly recommend using ClockWorkMod and making a backup of your ROM. Just in case Also, during any operation, I advise having your phone hooked up so I can draw power from the computer.
Usage
- Unzip the attached file somewhere
- Make sure your phone is connected in USB debugging mode
- Make sure you have SuperUser installed
- Run CFLagFix.exe
There are three tabs:
Install LagFix
This tab allows you to install the LagFix, and lets you configure some options.
I recommand leaving the "Full automatic" option turned on, if you do, just press "Install !" and everything will be arranged for you. If you turn this option off, you can configure some settings manually, but note that using this does not reclaim wasted space of the backup files.
Note that you can still select to use ext3 instead of ext2, even if in "Full automatic" mode.
When you press "Install !", the program will be finished quickly, but your phone may continue working for 30 minutes or so, and keep rebooting very often. If you have a lot of data installed, it may take even longer.
Do NOT even touch your phone until Android boots up again!
A lot of things are checked before the install will start. You will need about 50% free in /data for the operation to work, but it will check this before making any modifications on your phone.
Resize Partition
This tab allows you to change the current ext2/ext3 partition size. The slider will only let you select values that are actually possible, i.e., bigger than your current data usage and smaller than the total space that could be occupied by the image.
Clicking "Resize !" will reboot your phone and resize the partition. Again, this can take an awfully long time! Don't panic, just wait it out.
Uninstall LagFix
This will uninstall the LagFix. It will completely remove it. Before removing it, however, it will move all files out of the image and back into the normal filesystem again, so no data is lost.
Clicking "Uninstall !" will reboot your phone and perform the uninstallation. Again, this can take an awfully long time! Don't panic, just wait it out.
Note that uninstallation will only work if you are using less than 50% of the device's capacity, but again the program will check this before making any modifications on your phone.
You can only uninstall installations of CFLagFix 1.20 and newer !!
BETA
This is very beta, use at your own risk!
WARNING
This patch is NOT compatible with ANY other lagfix tools. Either undo those completely, or just don't use this. If you were using one of those, I'd personally recommend a complete reflash of the firmware before using this patch.
WARNING #2
Before trying 1.80, please see this post.
Download
<< 1.70: 632

Changelogs
1.80, 15-08-10
- Redone some crucial parts of the patching procedure (for all install, resize and uninstall). Should fix all remaining issues!
1.70, 13-08-10
- Added /data/app-private/ folder
- Added progress monitor (estimates.... not exact)
- Moved /dbdata/databases to it's own partition, much faster for smaller read/writes
1.60, 12-08-10
- Updated codebase to ADB Magic 0.9, fixes issues with some weird pre-existing installations of busybox
1.50, 12-08-10
- Added "full auto" mode, "one click" solution for beginners
- Added ext3 support
- Added resize support
- Added uninstall support
- Fixed some issues
- Update scripts
1.20, 11-08-10
- Everything has been moved to /data/cflf/ , this - amongst other things - fixes issues with JP3
1.01, 11-08-10
- Adusted a permission error which could cause the system to be unable to create any new databases
Fix for 1.00 users: there isn't any yet. This is *beep* to fix manually. I would advise this "unpatch" method posted here: http://forum.xda-developers.com/showpost.php?p=7616676&postcount=29, then repatch with the latest version.

CFLagFix.exe doesn't even run for me.
"The application failed to initialize properly (0xc0000135). Click OK to termiate the application."

lyno said:
CFLagFix.exe doesn't even run for me.
"The application failed to initialize properly (0xc0000135). Click OK to termiate the application."
Click to expand...
Click to collapse
You sure you have MS .Net 3.5 framework installed ?
http://www.microsoft.com/downloads/...fd-ae52-4e35-b531-508d977d32a6&displaylang=en
The error message is a DLL initialization error... as CFLagFix doesn't explicitly use any DLLs, my guess would be the .Net framework.

Chainfire said:
You sure you have MS .Net 3.5 framework installed ?
http://www.microsoft.com/downloads/...fd-ae52-4e35-b531-508d977d32a6&displaylang=en
The error message is a DLL initialization error... as CFLagFix doesn't explicitly use any DLLs, my guess would be the .Net framework.
Click to expand...
Click to collapse
Ah yes! I removed all .net frameworks on this works laptop to be able to install some old COM files. Will re-install and test.

This looks so awesome! Thank you!
Any chance for open sourcing this?

installing now
Well im gonna give this a shot, have just installed the african jg8 and rooted,am doing this fix now.
Then ill try the 1.2 overclock on top, ill post a score shortly .

Not bad though i see one problem... it's windows only ^^

select which folders you want to lagfix
Click to expand...
Click to collapse
Sorry, bit of a noob here - what exactly do you mean by this? Why would we only want to 'lagfix' certain folders and not the whole thing?

just tried out your tool on my stock DXJF4 (with apps in it, not clean condition). With default size as well (around 1200 mb)
Actually I used mimocan's fix before but everything was wiped by mistake and everything went to default condition.
After the process finished, the Android displayed information about damaged internal SD, but everything was working. Is that expectable?
Now I got 2260 using Quadrant, leap from 1700 with mimocan's fix.
Nice job Chainfire!!
Can't wait to use JM2 / DDJG4
btw, can I post this on my blog?
:update :
whenever I open gallery, it always says no sdcard detected... do you know how to fix this? -> it doesn't recognize both my internal & external sd, but i can browse them properly in Estrongs/astro

veenone said:
After the process finished, the Android displayed information about damaged internal SD, but everything was working.?
Click to expand...
Click to collapse
That sounds scary, think I'll wait a while before trying!

RyanZA said:
This looks so awesome! Thank you!
Any chance for open sourcing this?
Click to expand...
Click to collapse
Not at the moment, but maybe in the future
Tayutama said:
Not bad though i see one problem... it's windows only ^^
Click to expand...
Click to collapse
Can't be helped. Not going to release a non-Windows versions. Perhaps wine/mono will make it work, though I doubt it
danamoult said:
Sorry, bit of a noob here - what exactly do you mean by this? Why would we only want to 'lagfix' certain folders and not the whole thing?
Click to expand...
Click to collapse
You can't really lagfix all folders, as the process where the image is mounted is run asynchronously with the rest of the boot process. There will be havoc if the system can't load certain files because the image is not mounted yet. This is why you can't just lagfix the entire system, but only certain parts.
In the presets I have only added those folders that I feel are mostly safe to lagfix AND would actually benefit the speed of the phone.
Also, for some folders there is some discussion to whether or not it is beneficial to have them in the image, like /dbdata/databases. I personally feel it should be lagfixed, but not everyone agrees.
veenone said:
just tried out your tool on my stock DXJF4 (with apps in it, not clean condition). With default size as well (around 1200 mb)
Actually I used mimocan's fix before but everything was wiped by mistake and everything went to default condition.
After the process finished, the Android displayed information about damaged internal SD, but everything was working. Is that expectable?
Now I got 2260 using Quadrant, leap from 1700 with mimocan's fix.
Nice job Chainfire!!
Can't wait to use JM2 / DDJG4
btw, can I post this on my blog?
Click to expand...
Click to collapse
I have not seen the "damaged internal SD" message before in any of my tests. It might be ROM specific (I'm personally using JM2). I would recommend rebooting (using the "hold power button + press power off" method) and see if the message still comes up. Let me know what happens.
And yes, feel free to post about it in your blog.

veenone said:
just tried out your tool on my stock DXJF4 (with apps in it, not clean condition). With default size as well (around 1200 mb)
Actually I used mimocan's fix before but everything was wiped by mistake and everything went to default condition.
After the process finished, the Android displayed information about damaged internal SD, but everything was working. Is that expectable?
Now I got 2260 using Quadrant, leap from 1700 with mimocan's fix.
Nice job Chainfire!!
Can't wait to use JM2 / DDJG4
btw, can I post this on my blog?
:update :
whenever I open gallery, it always says no sdcard detected... do you know how to fix this?
Click to expand...
Click to collapse
Replying to the same message again, hehe.
Now that I'm thinking about, how exactly did your device got wiped ? Anything less than an actual firmware flash does not completely remove mimocan's fix, AFAIK. To completely undo it you'd have to completely reflash (and get stock kernel back), and possibly remove the ext partition from your SD. In other words, if you "wiped" from recovery, this is not a removal of mimocan (AFAIK).
Gallery is working fine for me, by the way, and as stated above, I have not seen that message in my tests with JM2 (neither with a lot of apps installed nor a clean flash).
(Then again, this is the first release, so there might be issues )

Is it possible to do this onto an external SD card (provided one has one that is fast enough) so we do not risk any possible further damage to the internal card due to excessive IO.
I believe it would be quite difficult to replace the internal SD card, and in order to load custom roms (with update.zip) it must be mounted to the internal SD.
I'd much rather replace external SD cards if I had to choose between the internal and an external.

well everything was restored to factory state when I went to CSC menu. I think mimocan's fix also removed since I got 800 in quadrant score.
Update: after I rebooted the sgs for a couple times, now it recognize both sd cards.. weird.. But that's fine since the issue is solved now!

Daemos said:
Is it possible to do this onto an external SD card (provided one has one that is fast enough) so we do not risk any possible further damage to the internal card due to excessive IO.
I believe it would be quite difficult to replace the internal SD card, and in order to load custom roms (with update.zip) it must be mounted to the internal SD.
I'd much rather replace external SD cards if I had to choose between the internal and an external.
Click to expand...
Click to collapse
This fix is using exactly same space that is already reserved for user data and programs. And it is on the internal SD. So I really can't think how this fix could cause any damage at all. Thoughts?

I selected maximum Space, and now i have low internal memory. How to remove this fix or change the Space?

Daemos said:
Is it possible to do this onto an external SD card (provided one has one that is fast enough) so we do not risk any possible further damage to the internal card due to excessive IO.
I believe it would be quite difficult to replace the internal SD card, and in order to load custom roms (with update.zip) it must be mounted to the internal SD.
I'd much rather replace external SD cards if I had to choose between the internal and an external.
Click to expand...
Click to collapse
Use mimocan's fix if you want to use external SD - it is especially made for that! His thread is a sticky (at the top) in this forum.
veenone said:
well everything was restored to factory state when I went to CSC menu. I think mimocan's fix also removed since I got 800 in quadrant score.
Update: after I rebooted the sgs for a couple times, now it recognize both sd cards.. weird.. But that's fine since the issue is solved now!
Click to expand...
Click to collapse
Mimocan's fix uses Odin. Like update.zip's, a "factory reset" does not remove patches made in this way, only a real flash does.
Either way, happy to see your problem is solved

I think the problem was the system didn't mount sd cards properly after several boots from CFLagFix. So it needs more reboots to mount the sdcard with structure change properly...

Chainfire said:
Not at the moment, but maybe in the future
Can't be helped. Not going to release a non-Windows versions. Perhaps wine/mono will make it work, though I doubt it
Click to expand...
Click to collapse
It's a shame you can't open source this.
Personally, there is no way I'm going to run something like this without source - I believe you are just trying to help us out, but there is always the chance that you could be doing something damaging by mistake, or even installing a trojan on purpose.
I'll be following release though, looks awesome and hopefully you'll be able to open source this soon!

[IDEA] Android rescue.zip project..

So i am here with a new idea. A rescue.zip which can be used to rescue any android device which have a recovery like the famous cwm.
So here is it..
Some times we people screw up our android os like hell, and to reboot the device we usualy do a recovery flash of a new os, flash back our nandroid backup ( both on worst conditions) or even do permission fix, clean cache or dalvic cache( those in 'not that worse' conditions) . So thats are all the options we got. Rit?
Although flashing recovery backups, new roms can fix all, it will also eatup our apps, current setups, contacts, msgs, etc( in case we dont have backups) and will probably screw us. All we can do is say " WTF..WTF..WTF.."
SO here is my idea,
Find out the causes of what causes a reboot, non-boot, hang,fc etc.
And keep a zip that can be flashed through recovery, that has a solution for our problem. They may be including..
1) fix permission of system, data, and user data.
2) zipalign the apps
3) fix the default clock speed of processor
4) defragment memory
5) flash a new copy of su and busy box
6)wipe data or system or ext or cache or dalvic cache
7) flash a new copy of framework.res, system-ui.apk, settings.apk with default permissions( those files are kept in separate "custom" folder on the zip, so that end user can put their own files to that "custom" folder for flashing., the reason behind it is known to all, yap. Not all devices have them in common, every device have its own files)
These are all i got for now, pls post ur ideas and knowledge for any possible cure about any problem u faced/ cured. So that we can make it an ultimate rescue.zip that have a cure for 99% problems android os have. The rest 1% will go with a clean flash.( well we cant avoid that if we did something that bad).
So my plan is to use aroma installer( now on hard learning to find how it works). Throw in some scripts, files etc. Into the zip.
And since its not a device specific .zip file, i want to know how and why any problems are caused in any device( there are many common problems, but that is not what i ask for. I ask for device/os specific problems, and not for a problem that we can cure after booting, but for a problem that can make the device un-bootable) . So u people may help me to find those problems and cures for it. For my knowledge i have experience with wildfire and hd2.
Well i will keep this thread for a week or two, so that u can post ur knowledge, and info. after that i will release the file for u.
To the admin. Of the forum, pls keep this thread as announcement so that all can take a look.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.

If you plan to do this available to any android device, the file size will be so big that it will become useless. Every phone has different apk, and not only that, but those apk are different in different version of os. For example, CM9 framework should not work on google release. Worst, older CM9 framework might not work on newer CM9 and newer framework might not work on older. Also, one of the cause of bootloop that i have been experiencing since i have my GNexus is data corruption of apps. The only way i had was to wipe data. I dont think there is a way to know if your app are corrupted with script. I also seen a lot of strange problem on SGS II like the kernel being erased. Well, in this case this package would be useless. So i guess that having this package would be awesome, but wont happen. My best advice is that you could create a universal guide on how to recover from bootloop/fc/hang with the minimum of impact on the phone. This is just my opinion tho.
Sent from my Galaxy Nexus using xda premium

You could add using flags in the updates filename, see some roms or themes for the lg optimus 2x for more information. It uses sed. For example, "update-wc-wd.zip" would wipe /data and /cache.
You could also merge these features in a customized clockwork mod recovery, the up side would be that you could automatically make a backup of the last flashed full ROM's systemui etc. this would also allow usage of the touch screen/volume keys to choose an repair option. You could even allow users to backup specific applications along with their data, and let users restore it later on after a fresh flash. I have some basic knowledge in modifying the recovery so I might help you out a little if you're interested.

chadouming said:
If you plan to do this available to any android device, the file size will be so big that it will become useless. Every phone has different apk, and not only that, but those apk are different in different version of os. For example, CM9 framework should not work on google release. Worst, older CM9 framework might not work on newer CM9 and newer framework might not work on older. Also, one of the cause of bootloop that i have been experiencing since i have my GNexus is data corruption of apps. The only way i had was to wipe data. I dont think there is a way to know if your app are corrupted with script. I also seen a lot of strange problem on SGS II like the kernel being erased. Well, in this case this package would be useless. So i guess that having this package would be awesome, but wont happen. My best advice is that you could create a universal guide on how to recover from bootloop/fc/hang with the minimum of impact on the phone. This is just my opinion tho.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
I told it already, the "custom" folder is not filled. It will be kept empty. The user can put a file, which ofcourse is the file of the device he/she have or want to get repaired. All he has to do is copy and paste the file from the working zip( zip file of his currently installed rom, that encounter the problem) of his rom to the custom folder inside the rescue.zip.
And the things that are common will be scripts, but those too will contains device specific mound points, paths, etc. I think that will be common( ie, the working of script, once the mound is done). Am i right?
So all i have to figure out is mount points, paths etc.. i got a couple of them, about 15 or so. And pls help me to find the rest.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.

a good idea to add is a file system chech like windows systems has. By installing a rom the installer should first check for bad sectors and mem blocks before installing the rom. After all blocks and sectors are scanned and the bad ones marked as "bad or corrupt" it should run something like defrag and place the bad blocks at the end of the file table. When all is done .. then the true rom install should start.
This will prevent heaps of problems since the curent installs just write over a bad block or sector creating the most weird problems. A fault checker/repair will take away a lot of strange forced closes and othere software/hardware failures.
Most phones wont last that long so that bad blocks or sectors can occure. But for the flashing junkies among us its a serious problem what can occure. I guess after 1000 or more installs bad sectors or blocks will occure and not all are being able to be repaired
Sent from my Galaxy Nexus using XDA App

Mikevhl said:
You could add using flags in the updates filename, see some roms or themes for the lg optimus 2x for more information. It uses sed. For example, "update-wc-wd.zip" would wipe /data and /cache.
You could also merge these features in a customized clockwork mod recovery, the up side would be that you could automatically make a backup of the last flashed full ROM's systemui etc. this would also allow usage of the touch screen/volume keys to choose an repair option. You could even allow users to backup specific applications along with their data, and let users restore it later on after a fresh flash. I have some basic knowledge in modifying the recovery so I might help you out a little if you're interested.
Click to expand...
Click to collapse
I am totaly newbee to lg. I have experience with htc, few samsung, etc. So can u pm me the details? Also is it usable to create recovery? I think a zip file with selectable options is more friendly. The thing is building a recovery wont make it universal( or atleast common for a couple of devices) and we will have to port them for each and every device. Thats the problem.
But any way i want ur help in building it. Can u pm me an example for mounding script in lg devices? And any thing that may become useful. Thank you.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.

wilwilwel said:
a good idea to add is a file system chech like windows systems has. By installing a rom the installer should first check for bad sectors and mem blocks before installing the rom. After all blocks and sectors are scanned and the bad ones marked as "bad or corrupt" it should run something like defrag and place the bad blocks at the end of the file table. When all is done .. then the true rom install should start.
This will prevent heaps of problems since the curent installs just write over a bad block or sector creating the most weird problems. A fault checker/repair will take away a lot of strange forced closes and othere software/hardware failures.
Most phones wont last that long so that bad blocks or sectors can occure. But for the flashing junkies among us its a serious problem what can occure. I guess after 1000 or more installs bad sectors or blocks will occure and not all are being able to be repaired
Sent from my Galaxy Nexus using XDA App
Click to expand...
Click to collapse
Pls pm me the idea how to make the checking script. Or links that have info in this. Thank u in figuring out such a prob. I am unaware of that.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.

showlyshah said:
I am totaly newbee to lg. I have experience with htc, few samsung, etc. So can u pm me the details? Also is it usable to create recovery? I think a zip file with selectable options is more friendly. The thing is building a recovery wont make it universal( or atleast common for a couple of devices) and we will have to port them for each and every device. Thats the problem.
But any way i want ur help in building it. Can u pm me an example for mounding script in lg devices? And any thing that may become useful. Thank you.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.
Click to expand...
Click to collapse
I'll send this as a PM as well, but people might learn from this. I am not talking about any specific mount points for LG phones, I just pointed out that there are some roms which use sed to check the filename of its update.zip and do tasks according to that, you need to have one line in your updater script to run the script which detects what to do. That way a user of a Galaxy Nexus would rename it to update-maguro.zip and it would know to use mount points for the maguro, while if the exact same update.zip was to be named update-p990.zip, it would know to use the mount points for the LG optimus 2x. This way you could easily keep the zip up to date for any device, because they all use the same update.zip
About the recovery, you would need to build it for every phone once, but you could make one change to the recovery source and easily compile the recovery for all phones which are capable of running CWM. I believe this method to be more user friendly, as a recovery image has support for actually choosing what you want to do, instead of having to rename the file. A recovery image also has a better way of communicating with the user. Where a update.zip can only say "Hey, I had an error and I'm quitting now, I won't give you any details what the problem was because that's just how update.zips roll", a recovery image would be able to give more advanced outputs, like "An error occurred when trying to mount /data." And then give you the option to either try again, manually fix it by using a computer with adb, or quitting.
But that's just my personal opinion. The recovery would be way harder to make, but I was the original porter of CM6, CM7 and HTC Sense to the xperia mini pro and mini back in the days. I also made a custom recovery and roms for the HTC desire Z, maintain a CWM port for the HTC Chacha which I don't even own and have used the LG optimus 2x before. (currently a maguro owner) but I'm trying to say that I've been experimenting a lot with different phones and know what the possibilities of Android are. you could even make a live Android build, tailored for recovering your phone, which is ran by an update.zip! How cool is that? That would be VERY device specific though..
let me know what you think is the best way to do this. I was thinking of making a mobile time machine app for some time so it's good I saw this thread.

[Q] android media process high cpu

com.android.process.media (Android Media Process is (ab)using CPU)
so, I've tried:
Settings -> Apps -> ALL -> Media Storage -> “Force stop” & “Clear data”
That didn't really help at all(((
community's users suggests following:
* its due to corrupted music/pictures (I don't have any music/pictures on my phone).
* suggestion to reformat sdcard, but toro doesn't have SD card, although through recovery I was able to check filesystem of /userdata mount point (see below):
~ # e2fsck -n /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata
e2fsck 1.41.11 (14-Mar-2010)
/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata: clean, 53630/1875968 files, 1921615/7493115 blocks
~ #
Click to expand...
Click to collapse
aside the fact that phone works extremely slow upon boot (due to com.android.process.media) all that high CPU eating a lot of battery (battery life isn't that great to begin with) but thanks to this bug I get to use even less.
after deleting nanodroid's backup (ROM manager), I'm seeing following (through logcat):
D/MediaProvider( 6784): object removed 71054
D/MediaProvider( 6784): object removed 71055
D/MediaProvider( 6784): object removed 71056
D/MediaProvider( 6784): object removed 71057
D/MediaProvider( 6784): object removed 71058
Click to expand...
Click to collapse

i read that if you have folders with a lot of media/picture files, it will sometimes hang while scanning. start fresh, factory reset/reflash google factory images.

bk201doesntexist said:
i read that if you have folders with a lot of media/picture files, it will sometimes hang while scanning. start fresh, factory reset/reflash google factory images.
Click to expand...
Click to collapse
i dont want to loose my /data so doing factory reset won't work for me

I had an issue with this at the beginning of the week.
I had read that it was corrupted media files, so I began investigating. I was able to fix the problem by browsing through my pictures and deleting some images that had somehow become corrupted. The corrupted files were just washed out black squares. No SD format / factory reset was needed.

t3h_g3n3r4l said:
I had an issue with this at the beginning of the week.
I had read that it was corrupted media files, so I began investigating. I was able to fix the problem by browsing through my pictures and deleting some images that had somehow become corrupted. The corrupted files were just washed out black squares. No SD format / factory reset was needed.
Click to expand...
Click to collapse
i thought that would be a problem) i found one and i delete, restarted my phone and still android media process is at least 20% cpu(

I had about half a dozen across several folders that were corrupt. I was looking at the android media process consuming my battery in about 3 or 4 hours until I deleted the bad images. I can now make it through most of a day without any problems.
Somewhere in your phone, a corrupted file lurks. It may not be where you're thinking, but it's there. And it's hungry.

t3h_g3n3r4l said:
I had about half a dozen across several folders that were corrupt. I was looking at the android media process consuming my battery in about 3 or 4 hours until I deleted the bad images. I can now make it through most of a day without any problems.
Somewhere in your phone, a corrupted file lurks. It may not be where you're thinking, but it's there. And it's hungry.
Click to expand...
Click to collapse
i went through all of my gallery and deleted those, yet after restart still doing something and by the time it's done something whatever it was doing i have 90%-70% left!!! AAAAA
is there a way to find those files some other way? can i see some debug information of gallery/android media process and see where hiccup is?
it really kills my battery( anyone has any ideas?

So yesterday I've had it and copy ask of my pictures from my phone to computer and delete them from my phone...
Reboot... and guess what?
It's still using 40/50% of cpu for about first 15 min after I reboot my phone which kills my battery big time(
I need help, anyone??
Sent from my Galaxy Nexus using Tapatalk 2

is there a way to turn on some detailed debug to figure out what's causing this exactly?!

a1exus said:
com.android.process.media (Android Media Process is (ab)using CPU)
so, I've tried:
Settings -> Apps -> ALL -> Media Storage -> “Force stop” & “Clear data”
That didn't really help(( Any other ideas? I keep reading that users saying its due to corrupted music (I don't have any music on my phone).
People are also suggesting to reformat sdcard, but we don't have SD card. Please advise, as one thing it uses CPU the other thing it uses battery and battery life isn't that great to begin with. Is there a way to do fsck or something to make sure there is no corruption of any kind?
*** UPDATE ***
I went into recovery and using adb shell got into a system can I do something like this?
Click to expand...
Click to collapse
I am having the same issue. I found this article but it says the same as the others here.
http://www.transformerforums.com/fo...help/24279-solved-media-using-94-battery.html
If I find anything else out or if you figure something out, let me know also.

a1exus said:
i dont want to loose my /data so doing factory reset won't work for me
Click to expand...
Click to collapse
Your pics and stuff are not in the /data folder. You won't really lose anything important. That is the directory a factory reset/data does. It just basically gets rid of the apps that you had installed. If you are already rooted just get titanium backup to restore. I assure you, I had the same problem up until yesterday. The factory reset was the only thing that fixed it.
The /data wipe is not going to get rid of your pics taken with the phone.
If you do a backup first you have nothing to lose by trying.
On a side note, your Galaxy Nexus does have an "sd card" it's just an internal partition.
Hope you get this resolved.

rushter said:
Your pics and stuff are not in the /data folder. You won't really lose anything important. That is the directory a factory reset/data does. It just basically gets rid of the apps that you had installed. If you are already rooted just get titanium backup to restore. I assure you, I had the same problem up until yesterday. The factory reset was the only thing that fixed it.
The /data wipe is not going to get rid of your pics taken with the phone.
If you do a backup first you have nothing to lose by trying.
On a side note, your Galaxy Nexus does have an "sd card" it's just an internal partition.
Hope you get this resolved.
Click to expand...
Click to collapse
I deleted manually all of my pictures/music yet I still having this issue((
I do have Titanium Backup and I backup my phone regularly, I may try do that...

Do the wipe, trust me. A few installs of programs is not an issue. Your personal data is not lost. Just reinstall your shops that you need and if the days is missing restore with titanium backup.
You will keep having these issues until you do.
Sent from my Nexus 7 using Tapatalk 2

Im having the exact same problem.. Media is 50% CPU, and my S3 gets hot until I stop the Media process after each reboot.
I would like to find a fix before going threw a wipe.
rushter said:
Do the wipe, trust me. A few installs of programs is not an issue. Your personal data is not lost. Just reinstall your shops that you need and if the days is missing restore with titanium backup.
You will keep having these issues until you do.
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse

I was having the same problem and the phone was burning a hole in my pocket.
I found that the problem only seemed to occur on a reboot with android.process.media consuming 96% of the CPU for approximately 40minutes.
I attempted to add a .nomedia file to every single directory on the root of my internal SDCARD. - This made no difference.
I discovered that if I killed the process via the terminal it was eventually restarted by zygote and the same issue occured.
I found the only way to stop this from occuring was to Freeze the "Media Storage" app using Titanium Backup. But (not surprisingly) other things did not work - eg being able to capture a screenshot.
I also discovered that if I went into Titanium Backup and issued a "Clear Cached Data" for the Media Storage app, this resulted in the process ceasing it's CPU consumption - useful - but hardly a silver bullet and an annoying step to take after every reboot. (Additionally I do not know if the scan process might of kicked off automatically at some later stage anyway).
Interestingly I discovered that the phone did not overheat when it was plugged into a power supply - completely unrelated but none the less I found this interesting cause I always thought it was the CPU causing the overheating - when in actual fact it was the battery being emptied - unrelated to the issue at hand but none the less a nice tangent
Now this is what I discovered:
I have an application called NZ Topo Maps, it creates a absolutely massive directory structure to download all the tiles of NZ and cache them locally. Each directory can have many sub directories which in turns has many more and can have many many files in each.
So I deleted the entire tilecache. The result - after a reboot android.process.media consumed 5seconds of CPU.
Not convinced I browsed some maps and "cached" ~64MB of tiles - rebooted - 2:33mins of CPU time consumed... hmmmm.
So I cached ~128mb of tiles - 7:44mins of CPU time consumed after a reboot - diffidently onto something here....
Of interest - every single directory which the NZ Topo Maps program creates has a ".nomedia" included and all of the files are labelled with a *.jpg_ suffix.
So I decided to do some more research - Under the structure I had 425 sub-directories and 10615 files that ended with the suffix .jpg_
Out of curiosity I deleted all the files (including the .nomedia) and left the directory structure completely intact.
After a reboot the media process consumed 32sec of CPU time.
For the final test I deleted the directory structure:
CPU consumed: SIX seconds!!!!
Solved: Why android.process.media is consuming so much battery.... for me atleast.
So in conclusion it seems that:
1) The .nomedia directive applies only to the current directory - android.process.media will still recurse into sub directories
2) The .nomedia does not make any difference to the time it takes media to process the contents of a directory - eg - it was still doing "something" with the files in the directory.
3) The naming of files .jpg_ does not make any difference either, the process will still look at them - not sure if it is supposed to or not.
Where to from here - I would really like to find the source for this process and have a look at it's logic, but right now I just don't understand the android internals enough to be able to determine where the source is located in the source tree! I have posted another thread about this - http://forum.xda-developers.com/showthread.php?p=34326153#post34326153 hopefully someone will give me an answer because this situation is less than ideal.
Hopefully this helps someone else and sends them in the right direction?
Rowan

All,
I found this link. I would post a click-able link but I am not allowed as I am a new forum member - so I am afraid you'll have to type it in the old fashioned way from the image below.
Please head over and "STAR" the bug and/or add your own comments / experience, the more visibility it gets the more likely it is to be fixed.
Cheers.
-Rowan

I have a new HTC One X+ running JB 4.1.1 Sense+. I noticed this happens off and on that the phone gets hot and battery plummets. Using Android Task Manager, realtime process viewer and showing system processes setting turned on, I discovered also it is android.process.media consuming the CPU.
I have over 2,800 mp3 files, most are highquality high bitrate, 16GB worth. They are all put into a directory structure based on artist and album name. I'm sure this is what the process is choking on.
The question is, is it some sort of indexing that just takes days or is it going to happen every time I reboot the phone? The USB charge can't even keep up with the batter drain when it is doing this.

every reboot, so don't reboot your phone)

jazee said:
The question is, is it some sort of indexing that just takes days or is it going to happen every time I reboot the phone? The USB charge can't even keep up with the batter drain when it is doing this.
Click to expand...
Click to collapse
It happens every reboot. The following workarounds are available:
a) not reboot
b) reboot only when you are connected to power
c) use TitaniumBackup to Freeze "Media Storage" (requires root)
d) Settings -> Apps -> ALL -> Media Storage -> “Clear data”. NB: A Force Stop will result in the process being restarted by Zygote at a later time.
e) delete the large directory structure and directories with 1000's of files.
(c) works indefinitely but things stop working - eg - screenshot fails
(d) seems to work until the next reboot but all of your media is gone from the native library - but this may not effect third-party players/apps
If you're using too much power when charging via USB, you might want to get a plug in wall adapter which can supply more current.
It's a really bad situation and seems to be effecting every build of JellyBean - it's a defect in the core software.
Things which do not work:
.nomedia - placing .nomedia files in all directories, some of the directories or the root directories has no noticeable effect.
renaming files - renaming media to an unknown extension (e.g., picture.jpg -> picture.abc) has no effect
-Rowan

I personally went through:
deleting broken images inside of my gallery
deleting my music
deleting my pictures
checking filesystem on my /sdcard partition
deleting some large directories that contains a lot of files
placing .nomedia inside of some directories
bloging about this: Android Media Process (high CPU) | alexus' blog
about to commit suiside #$%#&@!)
and almost every time when i (re)boot my phone and i'm not plugged in, i'll lose about 10% of battery in first 10min of my phone is doing something...
Google! fix it already!))

My Galaxy Nexus is being very laggy...

I bought my phone about a week ago, and I noticed it was pretty slow after installing some apps, even slower than my previous Nexus S.
I changed my phone from yakjuxw to yakju yesterday, and updated to 4.2. I even did a factory reset after everything was done.
It was the same, it started pretty fast but as I ran the apps from the backup I had made the phone started to slow down.
I still haven't managed to find which app is causing me problems, so I was hoping someone here could help...

Did you use Titantium Backup for apps?
As far as I know, it is recommended not to restore all apps via Titantium Backup but only the ones that have some data associated to them like games with their saves. So try installing a fresh 4.2 ROM, only restore the apps that needs their data, and download the others via Play Store
I hope you can either avoid the lag this way or at least spot the app causing it

ahmadallica said:
Did you use Titantium Backup for apps?
As far as I know, it is recommended not to restore all apps via Titantium Backup but only the ones that have some data associated to them like games with their saves. So try installing a fresh 4.2 ROM, only restore the apps that needs their data, and download the others via Play Store
I hope you can either avoid the lag this way or at least spot the app causing it
Click to expand...
Click to collapse
No, I restored it through the Nexus Toolkit (the GUI version).
I only restored normal apps and none of the system apps or data. And this has been on absolutely stock Google ROMs ever since I bought the phone.

KaiZ51 said:
I bought my phone about a week ago, and I noticed it was pretty slow after installing some apps, even slower than my previous Nexus S.
I changed my phone from yakjuxw to yakju yesterday, and updated to 4.2. I even did a factory reset after everything was done.
It was the same, it started pretty fast but as I ran the apps from the backup I had made the phone started to slow down.
I still haven't managed to find which app is causing me problems, so I was hoping someone here could help...
Click to expand...
Click to collapse
That happens when you restore rom essential apps...you only need to restore the apps you downloaded.
Sent from my Galaxy Nexus using xda premium

Maybe you have the eMMC bug/issue which may occur if your phone was produced 08/2012.
To check this install the "eMMC Brickbug Check" tool and verify if your if chip type is V3U00M and date 08/2012.
https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check
If yes check this link for a workaround for this annoying bug:
http://forum.xda-developers.com/showpost.php?p=35020486&postcount=10

KaiZ51 said:
No, I restored it through the Nexus Toolkit (the GUI version).
I only restored normal apps and none of the system apps or data. And this has been on absolutely stock Google ROMs ever since I bought the phone.
Click to expand...
Click to collapse
try to flash the image again and dont restore this time... see if that fixes your issue

navien said:
Maybe you have the eMMC bug/issue which may occur if your phone was produced 08/2012.
To check this install the "eMMC Brickbug Check" tool and verify if your if chip type is V3U00M and date 08/2012.
https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check
If yes check this link for a workaround for this annoying bug:
http://forum.xda-developers.com/showpost.php?p=35020486&postcount=10
Click to expand...
Click to collapse
Well, I've just checked it, and it seems like my phone falls within the parameters for this bug... The only difference is the date is 09/2012. But is there a way to know for sure that I'm affected by this bug? Besides, I'm going to have to root the phone, which is going to be a bit annoying since I really didn't want to do it because I may have problems with the warranty in case I need to return it...
Also, if I flash a custom ROM in the future, will I have to do that again, or do custom ROMs usually come with that fix?
k786 said:
try to flash the image again and dont restore this time... see if that fixes your issue
Click to expand...
Click to collapse
I was thinking of trying that as well, though it may be annoying because I'll lose my data... But if I have to I guess I really don't have a choice...

KaiZ51 said:
I was thinking of trying that as well, though it may be annoying because I'll lose my data... But if I have to I guess I really don't have a choice...
Click to expand...
Click to collapse
delete the userdata from the image and it wont wipe your internal storage

KaiZ51 said:
Well, I've just checked it, and it seems like my phone falls within the parameters for this bug... The only difference is the date is 09/2012. But is there a way to know for sure that I'm affected by this bug? Besides, I'm going to have to root the phone, which is going to be a bit annoying since I really didn't want to do it because I may have problems with the warranty in case I need to return it...
Also, if I flash a custom ROM in the future, will I have to do that again, or do custom ROMs usually come with that fix?
Click to expand...
Click to collapse
All people reported this bug (at least what i´ve found) have production date of 08/2012 - maybe this bug also affects newer models.
I think if your chip type is V3U00M then your'e phone is affected. But your can test this easily. Just copy a huge file (i've copied 1 hd movie ~11GB) to the internal storage. The phone should slow down extremely, even if you delete the file again. For example: my phone needed 4-6 seconds to open the contacts app - sometimes even more.
Rooting is no big issue - you can easily revert to stock image.
If you flash a ROM you will to have implement the workaround again. Custom ROMs will not include this fix in general because if you remount the data partition with the discard option on an eMMC other than V3U00M your phone will be hard bricked.

navien said:
All people reported this bug (at least what i´ve found) have production date of 08/2012 - maybe this bug also affects newer models.
I think if your chip type is V3U00M then your'e phone is affected. But your can test this easily. Just copy a huge file (i've copied 1 hd movie ~11GB) to the internal storage. The phone should slow down extremely, even if you delete the file again. For example: my phone needed 4-6 seconds to open the contacts app - sometimes even more.
Rooting is no big issue - you can easily revert to stock image.
If you flash a ROM you will to have implement the workaround again. Custom ROMs will not include this fix in general because if you remount the data partition with the discard option on an eMMC other than V3U00M your phone will be hard bricked.
Click to expand...
Click to collapse
So, I went ahead and followed the instructions on the link you gave me... And it seems to be much better so far I still haven't tested enough, but I think the problem is pretty much fixed. I just have a few more questions if you don't mind...
1- When I ran the dd command, it took a while like the instructions said, but when it finished it said something about not enough space. Could something have gone wrong, or is this normal?
2- Since it isn't likely custom ROMs implement this fix, is there any way I can "stick" this fix on the phone's system so that I don't have to worry about setting it every time I flash a new ROM?
3- Is there any way to make sure that the script I set up in Script Manager is fully working and running on boot?

KaiZ51 said:
So, I went ahead and followed the instructions on the link you gave me... And it seems to be much better so far I still haven't tested enough, but I think the problem is pretty much fixed. I just have a few more questions if you don't mind...
1- When I ran the dd command, it took a while like the instructions said, but when it finished it said something about not enough space. Could something have gone wrong, or is this normal?
2- Since it isn't likely custom ROMs implement this fix, is there any way I can "stick" this fix on the phone's system so that I don't have to worry about setting it every time I flash a new ROM?
3- Is there any way to make sure that the script I set up in Script Manager is fully working and running on boot?
Click to expand...
Click to collapse
Bumping...

KaiZ51 said:
So, I went ahead and followed the instructions on the link you gave me... And it seems to be much better so far I still haven't tested enough, but I think the problem is pretty much fixed. I just have a few more questions if you don't mind...
1- When I ran the dd command, it took a while like the instructions said, but when it finished it said something about not enough space. Could something have gone wrong, or is this normal?
2- Since it isn't likely custom ROMs implement this fix, is there any way I can "stick" this fix on the phone's system so that I don't have to worry about setting it every time I flash a new ROM?
3- Is there any way to make sure that the script I set up in Script Manager is fully working and running on boot?
Click to expand...
Click to collapse
The dd command fills the entire partition till full, therefore the not enough space message is normal.
I´ve not tested how to implemt this fix in a ROM before flashing.
In theory you only need to add the file with the script into the init.d folder of the zip before flashing.
I´ve made IO Benchmarks with AndroBench to check if the script works:
with enabled script i get for example RND WR ~135 IOPS without script 54 IOPS.

navien said:
The dd command fills the entire partition till full, therefore the not enough space message is normal.
I´ve not tested how to implemt this fix in a ROM before flashing.
In theory you only need to add the file with the script into the init.d folder of the zip before flashing.
I´ve made IO Benchmarks with AndroBench to check if the script works:
with enabled script i get for example RND WR ~135 IOPS without script 54 IOPS.
Click to expand...
Click to collapse
Apparently it isn't running, since I get my Random Write score in the 30's IOPS. Besides that, I made Script Manager output logs, and it seems like it says it could not mount.
So what can I do? I'm not sure if I've already said this, but I'm on the stock 4.2.1 yakju ROM, if it matters. I could do this the init.d way, but I'm not sure if it works fine on stock ROM...
Also, something I haven't yet understood, is the dd command for checking if the fix works temporarily, or do you really need to do it in order to prepare the phone for the script?
And do you need to have as much empty space as possible before running the command, or you don't need to care about that?
Sorry about all the trouble with this problem, it's just as you probably know the phone is barely usable with this bug so I have no choice but to ask for help... Google should really fix this in an update, it's something pretty urgent in my opinion.

KaiZ51 said:
Apparently it isn't running, since I get my Random Write score in the 30's IOPS. Besides that, I made Script Manager output logs, and it seems like it says it could not mount.
So what can I do? I'm not sure if I've already said this, but I'm on the stock 4.2.1 yakju ROM, if it matters. I could do this the init.d way, but I'm not sure if it works fine on stock ROM...
Also, something I haven't yet understood, is the dd command for checking if the fix works temporarily, or do you really need to do it in order to prepare the phone for the script?
And do you need to have as much empty space as possible before running the command, or you don't need to care about that?
Sorry about all the trouble with this problem, it's just as you probably know the phone is barely usable with this bug so I have no choice but to ask for help... Google should really fix this in an update, it's something pretty urgent in my opinion.
Click to expand...
Click to collapse
Oh, and do you think I should go to the store to replace my phone? I still haven't understood if this is a software or hardware issue, but I'm believing it's the first...

KaiZ51 said:
Apparently it isn't running, since I get my Random Write score in the 30's IOPS. Besides that, I made Script Manager output logs, and it seems like it says it could not mount.
So what can I do? I'm not sure if I've already said this, but I'm on the stock 4.2.1 yakju ROM, if it matters. I could do this the init.d way, but I'm not sure if it works fine on stock ROM...
Also, something I haven't yet understood, is the dd command for checking if the fix works temporarily, or do you really need to do it in order to prepare the phone for the script?
And do you need to have as much empty space as possible before running the command, or you don't need to care about that?
Sorry about all the trouble with this problem, it's just as you probably know the phone is barely usable with this bug so I have no choice but to ask for help... Google should really fix this in an update, it's something pretty urgent in my opinion.
Click to expand...
Click to collapse
OK. The workaround with the script needs a ROM with init.d support. I thought this was mentioned in the linked thread.
I´m using THIS one.
The real fix is the re-mounting of the /data & /cache partitions using the discard option. If you type the command in a terminal window it fixes the problem temporary.
After reboot the problem is back. So you need to make a init.d script which will be executed every boot.
I think the dd command 'cleans' the free memory but i'm not sure.
To my opinion it doesn't make any sense to replace the phone because there's a big chance to get a new one with same problem.
So it is a software bug which should be solved by google.

navien said:
OK. The workaround with the script needs a ROM with init.d support. I thought this was mentioned in the linked thread.
I´m using THIS one.
The real fix is the re-mounting of the /data & /cache partitions using the discard option. If you type the command in a terminal window it fixes the problem temporary.
After reboot the problem is back. So you need to make a init.d script which will be executed every boot.
I think the dd command 'cleans' the free memory but i'm not sure.
To my opinion it doesn't make any sense to replace the phone because there's a big chance to get a new one with same problem.
So it is a software bug which should be solved by google.
Click to expand...
Click to collapse
Hmm I see... But from what I understood, you can make the script run at boot with apps like ROM Toolbox and Script Manager, correct? Although I'm not sure if it's running on my system, I've tried both apps and the benchmarks are always in the 30's...
Or do you really need a ROM with init.d support? Also I have BusyBox installed on Google's stock ROM, not sure if that is enough to able to run init.d scripts.
But how would you run scripts with init.d? Sorry, I'm a noob to this kind of stuff, I never did stuff like this...

KaiZ51 said:
Well, I've just checked it, and it seems like my phone falls within the parameters for this bug... The only difference is the date is 09/2012.
Click to expand...
Click to collapse
Thank you for confirming chips produced 09/2012 as bad. Added this to the post linked above.
KaiZ51 said:
When I ran the dd command, it took a while like the instructions said, but when it finished it said something about not enough space. Could something have gone wrong, or is this normal?
Click to expand...
Click to collapse
This is normal as we don't give the dd command a particular file size to create. So it simply writes data until no space is left.
KaiZ51 said:
Since it isn't likely custom ROMs implement this fix, is there any way I can "stick" this fix on the phone's system so that I don't have to worry about setting it every time I flash a new ROM?
Click to expand...
Click to collapse
If you are only using ROMs that support something like init.d inside data (like CM), next time to worry about this will be when you do a full wipe.
Probably then the problem will already be fixed by Google or others as it gains more attention over time.
KaiZ51 said:
Is there any way to make sure that the script I set up in Script Manager is fully working and running on boot?
Click to expand...
Click to collapse
Jup. Type 'mount' in Terminal or adb after you rebooted your phone:
# mount
[...]
/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata /data ext4 rw,noatime,errors=panic,barrier=1,nomblk_io_submit,data=ordered,noauto_da_alloc,discard 0 0
[...]
Click to expand...
Click to collapse
=> discard option added, script ran successfully
KaiZ51 said:
Apparently it isn't running, since I get my Random Write score in the 30's IOPS. Besides that, I made Script Manager output logs, and it seems like it says it could not mount.
Click to expand...
Click to collapse
Maybe you have to check something like 'run as root' or similar in Script Manager.
KaiZ51 said:
So what can I do? I'm not sure if I've already said this, but I'm on the stock 4.2.1 yakju ROM, if it matters. I could do this the init.d way, but I'm not sure if it works fine on stock ROM...
Click to expand...
Click to collapse
Nope. Stock does not support init.d.
KaiZ51 said:
Also, something I haven't yet understood, is the dd command for checking if the fix works temporarily, or do you really need to do it in order to prepare the phone for the script?
Click to expand...
Click to collapse
You can use the script without. The phone will speed up over time as more and more data is written/deleted and therefore the eMMC chip gets some discard commands.
The dd + rm just speeds up the process as all free blocks will be told to the eMMC chip due to the discard option added beforehand.
Another possibility (after installing the script and confirming that it works) would be to copy a large file that fills almost all space on the phone and remove it afterwards. The dd command is just considerably faster.
KaiZ51 said:
And do you need to have as much empty space as possible before running the command, or you don't need to care about that?
Click to expand...
Click to collapse
You don't need to care. Just keep around 1,0-1,5 GiB of free space everytime: Benchmark
KaiZ51 said:
Oh, and do you think I should go to the store to replace my phone? I still haven't understood if this is a software or hardware issue, but I'm believing it's the first...
Click to expand...
Click to collapse
Well, you might get a replacement phone and through bringing it back the chance that Google gets aware of the problem may be higher.
But possibly they will only wipe all data which makes the phone fast again for some time and tell you there is nothing wrong with it...
You may even think about it from this point of view: If the fix works for you, you have a phone with a blazingly fast eMMC chip, faster than any GNex produced before 08/2012 (until you have less than 1 GiB of free space on /data)
KaiZ51 said:
Google should really fix this in an update, it's something pretty urgent in my opinion.
Click to expand...
Click to collapse
+1

ph4zrd said:
Thank you for confirming chips produced 09/2012 as bad. Added this to the post linked above.
This is normal as we don't give the dd command a particular file size to create. So it simply writes data until no space is left.
If you are only using ROMs that support something like init.d inside data (like CM), next time to worry about this will be when you do a full wipe.
Probably then the problem will already be fixed by Google or others as it gains more attention over time.
Jup. Type 'mount' in Terminal or adb after you rebooted your phone:
=> discard option added, script ran successfully
Maybe you have to check something like 'run as root' or similar in Script Manager.
Nope. Stock does not support init.d.
You can use the script without. The phone will speed up over time as more and more data is written/deleted and therefore the eMMC chip gets some discard commands.
The dd + rm just speeds up the process as all free blocks will be told to the eMMC chip due to the discard option added beforehand.
Another possibility (after installing the script and confirming that it works) would be to copy a large file that fills almost all space on the phone and remove it afterwards. The dd command is just considerably faster.
You don't need to care. Just keep around 1,0-1,5 GiB of free space everytime: Benchmark
Well, you might get a replacement phone and through bringing it back the chance that Google gets aware of the problem may be higher.
But possibly they will only wipe all data which makes the phone fast again for some time and tell you there is nothing wrong with it...
You may even think about it from this point of view: If the fix works for you, you have a phone with a blazingly fast eMMC chip, faster than any GNex produced before 08/2012 (until you have less than 1 GiB of free space on /data)
+1
Click to expand...
Click to collapse
Thanks, that cleared a lot of questions.
So, after having tested the phone some more time (and I do have discard enabled at boot after all), the phone still seems pretty slow to me.
Yesterday I did the discard command with the adb shell, and then rebooted with the discard script enabled, but it's still pretty slow...
I've also benchmarked the phone in AndroBench a few times after this and Random Write scores ranged from as low as 6 (yes, six) IOPS, to 60's IOPS.
Still, this isn't that good since it seems like normal scores are in the 100's.
I really don't know what I should do now... Maybe the eMMC chip isn't actually the problem? But I find that rather strange since I don't think I have any apps that I already didn't have on my old Nexus S, and the phone does seem slower than my old one.

KaiZ51 said:
I really don't know what I should do now... Maybe the eMMC chip isn't actually the problem? But I find that rather strange since I don't think I have any apps that I already didn't have on my old Nexus S, and the phone does seem slower than my old one.
Click to expand...
Click to collapse
How much free space do you have left on /data or /sdcard?
And you used the dd-rm-combination after remounting with discard, right?

ph4zrd said:
How much free space do you have left on /data or /sdcard?
And you used the dd-rm-combination after remounting with discard, right?
Click to expand...
Click to collapse
I have 1.71GB free now.
And what do you mean about your second question? If you're asking if I used those commands when I connected the phone to my PC via USB Debugging, then yes.
If you're talking about the script that runs at boot, all I have in that script is
Code:
#!/system/bin/sh
mount -o remount,discard /data
mount -o remount,discard /cache
Should I put the script like this?
Code:
#!/system/bin/sh
mount -o remount,discard /data
mount -o remount,discard /cache
dd if=/dev/zero of=/data/tmp.bin
rm /data/tmp.bin
I didn't put them there since I thought the dd and rm commands were only meant to be run when connected via USB and not at boot as well...

[Q] Tiny's CM10.1 Nightlies and bcache

Hiya Folks,
Long time listener, first time poster.
I have a few questions:
a) Tiny, thanks a lot for your CM10.1+evervolv device tree builds, these are awesome. One question for you: Is there any chance you might be willing to post a short changelog when you post new builds? I understand that's a bit of an administrative headache, but it would be really nice to be able to get a sense, at least on a coarse level, as to what's new in each build... (ie: merged new display driver, picked up CM10.1 changes from x date to x date, explicitly tried to fix x)
b) With the initial jump to these builds, I took a full backup and started over. I've found that for some of the nightlies, I can just wipe caches and install the new OS image and everything seems to work. This, of course, is largely dependent on binary compatibility between sqlite versions, etc and high level compatibility between database schemas. Is there any way you could perhaps give a sense as to whether or not anything has changed that would definitely require a full wipe versus this build contains stuff that probably won't make a difference with each build along with a big disclaimer absconding any responsibility if things go wrong?
c) The camcorder is recording at a very low framerate, this is a known issue. Is there a fix coming down the line any time soon? I'm proficient with both userland and kernel hacking, and know my way around Android's internals pretty well. Do you have any information on what's causing this bug. I might be able to hack around a bit with it, but some sense of the history and the components involved would be helpful. (I have a sneaking suspicion this has to do with the video drivers and the sync to vsync stuff that is new in 4.1)
d) I've long been fascinated by the strange situation involving the scantily documented /datadata partition. My understanding is that this is some kind of faster chunk of hardware flash that is used by application databases with the idea being that it speeds them up. I believe ext4all mod moves the stuff onto the sdcard or regular internal storage and then symlinks. Has anyone considered playing with the Linux bcache module that allows faster storage block devices to serve as a cache over slower storage block devices in the storage hierarchy? I've been thinking about hacking on this myself, but I wanted to see if anyone has considered it and if it would cause problems that I don't see now (I could see it causing a problem with the current way nandroid backups are taken, or something along those lines, for example).
In any event, thanks for listening!

I'll try to summarize a, b, and c.
A. No official change log. I don't have time to write one. I try to post significant changes when I can.
B. I almost never wipe with cm. In theory you can even upgrade from cm10 to cm10.1. Wiping is overrated and its usually only useful to troubleshoot really weird issues.
C. The camcorder lag is likely a software or codec issue. Technically its not a bug but more of optimization issue. Preview glitching I'd call a bug.
Sent from my Galaxy Nexus using Tapatalk 2

a-dub said:
Hiya Folks,
Long time listener, first time poster.
I have a few questions:
a) Tiny, thanks a lot for your CM10.1+evervolv device tree builds, these are awesome. One question for you: Is there any chance you might be willing to post a short changelog when you post new builds? I understand that's a bit of an administrative headache, but it would be really nice to be able to get a sense, at least on a coarse level, as to what's new in each build... (ie: merged new display driver, picked up CM10.1 changes from x date to x date, explicitly tried to fix x)
b) With the initial jump to these builds, I took a full backup and started over. I've found that for some of the nightlies, I can just wipe caches and install the new OS image and everything seems to work. This, of course, is largely dependent on binary compatibility between sqlite versions, etc and high level compatibility between database schemas. Is there any way you could perhaps give a sense as to whether or not anything has changed that would definitely require a full wipe versus this build contains stuff that probably won't make a difference with each build along with a big disclaimer absconding any responsibility if things go wrong?
c) The camcorder is recording at a very low framerate, this is a known issue. Is there a fix coming down the line any time soon? I'm proficient with both userland and kernel hacking, and know my way around Android's internals pretty well. Do you have any information on what's causing this bug. I might be able to hack around a bit with it, but some sense of the history and the components involved would be helpful. (I have a sneaking suspicion this has to do with the video drivers and the sync to vsync stuff that is new in 4.1)
d) I've long been fascinated by the strange situation involving the scantily documented /datadata partition. My understanding is that this is some kind of faster chunk of hardware flash that is used by application databases with the idea being that it speeds them up. I believe ext4all mod moves the stuff onto the sdcard or regular internal storage and then symlinks. Has anyone considered playing with the Linux bcache module that allows faster storage block devices to serve as a cache over slower storage block devices in the storage hierarchy? I've been thinking about hacking on this myself, but I wanted to see if anyone has considered it and if it would cause problems that I don't see now (I could see it causing a problem with the current way nandroid backups are taken, or something along those lines, for example).
In any event, thanks for listening!
Click to expand...
Click to collapse
d) The /datadata partion is just a normal partition but is formated yaffs2, which is a little faster than ext 3 which is what /data and /cache normally use out of the box. However this partition is small, and fills up quickly. The ext4 mods do 2 things, they convert /data and /cache from ext3 to the slightly faster ext4. It also moves all of the files from the /datadata partition and instead placed the files on the /data partition in a data folder. So it still ends up having the path /data/data just as it did before the mod. This leaves the yaffs2 /datadata partion empty and unused.
I havent heard of bcache, so im not sure on that question. If you could get bcache to use the old /data/data partition as cache for the other partitions it might provide better performance. It shouldn't cause backup issues as /datadat is already backed up by nandroid, so all required filed should get backed up. If you get it working, i would definitley check it out.