ARCHIVED: [DEAD ROM] ThundeROM V1.8.3 4/5/2011

[jstntp]

Ksmith, I was looking through the build.prop for 1.8.3 and did not see the changes:

Maximum events window manager can handle per second raised to 60
Proximity sensor debounce time reduced to 25

Did you work them in a different way?

Nope, accidentally put up the link to a version without those changes (that's the only difference). I changed the link out to the version with those settings in the build.prop but i dug in a little bit last night and am now 99.99% sure those are controlled by the kernel or drivers so changing them in the buildprop will have no impact. So, no harm no foul. Any "improvement" by these changes would be placebo. But if people enjoy them, eat up because they also don't cause any harm

I tested this a little bit. I changed the proximity value from 25 to 300, and I could NOT tell any difference whatsoever. So, ya placebo. LOL

Anyway, the new version runs great and gallery is fast as hell. I don't play any games, but I might try a few just to see. Thanks again.

 

[sfhub]

So I initially added the sdcard read_ahead_kb adjust in init.rc in the "on boot" section, but after boot it stayed at 128. I then added it to the post boot script and after boot it was at 2048.

I was wondering how TR got away with putting it in the "on boot" section so I installed TR1.8.3, wiped data/factory and booted. It appears for my TR1.8.3 install read_ahead_kb is still at 128, same as what I saw when I manually inserted it in stock init.rc

cat /sys/devices/virtual/bdi/179:0/read_ahead_kb
128

I rebooted once just to make sure it wasn't a first boot thing and it still says 128.

So unless I'm doing something wrong, I don't think TR1.8.3 is actually setting read_ahead_kb to 2048 in a persistent manner.

Anyway, I added my change to init.qcom.post_boot.sh to make it persistent.

 

[jondevere]

I tested this a little bit. I changed the proximity value from 25 to 300, and I could NOT tell any difference whatsoever. So, ya placebo. LOL

Anyway, the new version runs great and gallery is fast as hell. I don't play any games, but I might try a few just to see. Thanks again.

Yea.. unfortunatley I think you are right.. I have been tryin to set it to 99, shoot... today im at 999 for timeout. What I did notice tho or was thinking of.... It isnt so much the lock when your on the phone. It was that the phone wouldnt recognize that I had tilted the phone to look at the screen... Is this possible? Im tryin to understand the unexplainable possibly... Still rockin it at 999 timeout tho! Thanks again everyone

 

[jstntp]

So I initially added the sdcard read_ahead_kb adjust in init.rc in the "on boot" section, but after boot it stayed at 128. I then added it to the post boot script and after boot it was at 2048.

I was wondering how TR got away with putting it in the "on boot" section so I installed TR1.8.3, wiped data/factory and booted. It appears for my TR1.8.3 install read_ahead_kb is still at 128, same as what I saw when I manually inserted it in stock init.rc



I rebooted once just to make sure it wasn't a first boot thing and it still says 128.

So unless I'm doing something wrong, I don't think TR1.8.3 is actually setting read_ahead_kb to 2048 in a persistent manner.

Anyway, I added my change to init.qcom.post_boot.sh to make it persistent.

I just checked mine. /sys/devices/virtual/bdi/179:0/read_ahead_kb
2048

 

[sfhub]

I just checked mine. /sys/devices/virtual/bdi/179:0/read_ahead_kb
2048

So looks like I will need to investigate further why I'm seeing different results.

 

[jstntp]

Yea.. unfortunatley I think you are right.. I have been tryin to set it to 99, shoot... today im at 999 for timeout. What I did notice tho or was thinking of.... It isnt so much the lock when your on the phone. It was that the phone wouldnt recognize that I had tilted the phone to look at the screen... Is this possible? Im tryin to understand the unexplainable possibly... Still rockin it at 999 timeout tho! Thanks again everyone

It's not recognized by tilt though. There is a proximity sensor on the face of the phone. Up to the left of the earphone. While on a call slip your finger over it to see.

 

[KSmithInNY]

So unless I'm doing something wrong, I don't think TR1.8.3 is actually setting read_ahead_kb to 2048 in a persistent manner.

Anyway, I added my change to init.qcom.post_boot.sh to make it persistent.

You are, and , it is.

Anyone can check theirs. Feel free.
1) Reboot device
2) With any kind of a root explorer drive to the following /sys/devices/virtual/bdi/179:0/read_ahead_kb

result = 2048.

 

[jondevere]

It's not recognized by tilt though. There is a proximity sensor on the face of the phone. Up to the left of the earphone. While on a call slip your finger over it to see.

Thank you for the clarification. These are all good things to know Has anyone tried setting it to Zero??? for prox time? hmm... ima do it now.

BTW that was a joke for zero value

 

[KSmithInNY]

Ever since 1.8 my Adfree has not been working. It says it's been granted superuser perms when I boot the phone up but I still get ads in Angry Birds, euchre, and everywhere else. I tried unistalling and reinstalling. Grrrrr

Open adfree, turn off symlink, download and install the host, reboot to recovery, wipe cache, reboot.

 

[KSmithInNY]

Yeah the proximity sensor is definitely not controlled by the build.prop and i can say that with 100% certainty now. Ran a chart of it at 25, ran a chart of it at 400, ran a chart of it at 900. You can lay them over top and they are exact matches of each other. Thats gone for sure in the next build.

Now need to check out maximum events windows manager but i already suspect the same results on that. No harm in trying though. The fact that they don't change anything means they don't hurt anything.

 

[jondevere]

Yeah the proximity sensor is definitely not controlled by the build.prop and i can say that with 100% certainty now. Ran a chart of it at 25, ran a chart of it at 400, ran a chart of it at 900. You can lay them over top and they are exact matches of each other. Thats gone for sure in the next build.

Now need to check out maximum events windows manager but i already suspect the same results on that. No harm in trying though. The fact that they don't change anything means they don't hurt anything.

Thank you for the info. Ima tinker around I think. i would like to see the outcome of the windows manager testing. Im sure your right tho.

 

[sfhub]

You are, and , it is.

Anyone can check theirs. Feel free.
1) Reboot device
2) With any kind of a root explorer drive to the following /sys/devices/virtual/bdi/179:0/read_ahead_kb

result = 2048.

I think there is a race condition with putting the read_ahead_kb in the "on boot" section.

I redid the TR1.8.3 install and it said 2048 on initial check after the initial setup language selection came up. Then I rebooted and checked again. Now it says 128.

It probably depends on what is getting loaded on startup whether the race condition goes one way or the other. I'm doing an absolute fresh install with nothing installed. I also have the USB cable connected when I'm rebooting and USB debugging is enabled by default in TR. Since it is probably a race condition and I'm not sure what items are racing, it could be that for some people it'll always be 2048 and for others it might always be 128, or even it might change from one boot to the next.

So I should rephrase, I don't think TR1.8.3 is setting read_ahead_kb in a deterministic manner, though it will be 2048 in many cases.

After initial TR1.8.3 install, booting with empty /data, USB connected, skip language, skip Google account, uncheck GPS.

C:\SDK\tools>adb shell

# getprop ro.build.display.id
getprop ro.build.display.id
ThundeROM-V1.8.3

# cat /sys/devices/virtual/bdi/179:0/read_ahead_kb
cat /sys/devices/virtual/bdi/179:0/read_ahead_kb
2048

After first reboot, USB connected

# reboot
reboot

C:\SDK\tools>adb shell

# getprop ro.build.display.id
getprop ro.build.display.id
ThundeROM-V1.8.3

# cat /sys/devices/virtual/bdi/179:0/read_ahead_kb
cat /sys/devices/virtual/bdi/179:0/read_ahead_kb
128

Another reboot, USB not connected until after boot is complete

# reboot
reboot
C:\SDK\tools>adb shell

# getprop ro.build.display.id
getprop ro.build.display.id
ThundeROM-V1.8.3

# cat /sys/devices/virtual/bdi/179:0/read_ahead_kb
cat /sys/devices/virtual/bdi/179:0/read_ahead_kb
128

This time reboot to recovery, wipe data/factory, USB connected at boot

# reboot recovery
reboot recovery

C:\SDK\tools>adb shell

# getprop ro.build.display.id
getprop ro.build.display.id
ThundeROM-V1.8.3

# cat /sys/devices/virtual/bdi/179:0/read_ahead_kb
cat /sys/devices/virtual/bdi/179:0/read_ahead_kb
2048

Anyway, on my own install I moved it later in the boot process to init.qcom.post_boot.sh and it always comes up 2048.

 

[Kingatmos]

I got v.1.8.2 How can I update to 1.8.3 without losing my setting and saved games?

 

[pitmasterme]

I got v.1.8.2 How can I update to 1.8.3 without losing my setting and saved games?

Just dl and flash.....make a nandroid first of course......


Sent from my LS670 using Tapatalk

 

[Kingatmos]

trying now.....

 

[debh945]

I think there is a race condition with putting the read_ahead_kb in the "on boot" section.

I redid the TR1.8.3 install and it said 2048 on initial check after the initial setup language selection came up. Then I rebooted and checked again. Now it says 128.

It probably depends on what is getting loaded on startup whether the race condition goes one way or the other. I'm doing an absolute fresh install with nothing installed. I also have the USB cable connected when I'm rebooting and USB debugging is enabled by default in TR. Since it is probably a race condition and I'm not sure what items are racing, it could be that for some people it'll always be 2048 and for others it might always be 128, or even it might change from one boot to the next.

So I should rephrase, I don't think TR1.8.3 is setting read_ahead_kb in a deterministic manner, though it will be 2048 in many cases.

After initial TR1.8.3 install, booting with empty /data, USB connected, skip language, skip Google account, uncheck GPS.


After first reboot, USB connected


Another reboot, USB not connected until after boot is complete


This time reboot to recovery, wipe data/factory, USB connected at boot


Anyway, on my own install I moved it later in the boot process to init.qcom.post_boot.sh and it always comes up 2048.

Thank you sfhub! It also did not "stick" for me after a reboot. Edited my init.qcom.post_boot.sh and now it sticks.


Sent from my LS670 using Tapatalk

 

[KSmithInNY]

i won't be able to look at, touch, change anything until later. Gotta work

 

[holangja1]

my widgets(advanced task killer, NoLed, Extended controls) keep disappearing after reboots. i cant even re-add them because it disappears from the widget picker as well. i have to keep re-installing the app to bring it back. what can i dooo?

 

[jstntp]

my widgets(advanced task killer, NoLed, Extended controls) keep disappearing after reboots. i cant even re-add them because it disappears from the widget picker as well. i have to keep re-installing the app to bring it back. what can i dooo?

That happened to me a while back on an earlier version of TR. I wiped data, cache, and dalvik then reflashed TR. And it was fine.

Sent by Tapatalk ----- Optimus s

 

[ccrs8]

Is anyone else getting frequent force closes with the new music player in TR 1.8.3? Just about every other time I hit the menu button while in the music player, it force closes. I rebooted and I also reflashed but neither has fixed the problem. Given that the new music player was a big part of 1.8.3, I'm sure others who have upgraded to it have tried out the new music player. The fact that nobody has posted about FCs while using it makes me think it's just me.