when idle right
and not in active
its inactive
please correct it

I uninstalled batterypatch to see if the issue comes from it (or from speedpatch which I installed at the same time as batterypatch).

If I don't have battery problem this night, I will eventually try batterypatch again.

When I said my phone was "inactive", I mean I used the phone right side sliding button to stop the screen.

from my opinion, the batterypatch has something to do with the PK49. you should install PK49 along with batterypatch to get it working. but if you just a normal user and not use overclocking, i suggest you just install the PK49 + speedpatch. you will notice the difference.

Yes, I don't use overclocking so, as you say to me, batterypatch is useless in this case ?

Sadly, I don't know how I can have wl drivers (which could be useful when you travel and you stay in big city with a lot of WEP encrypted networks ) on kernel power 49.

Do you know if there is any port of those drivers on kernel power 49 ? (in fact, it's more a question which belongs to the forum kernel power's topic)

So, is my current speedpatch install on a kernel power 46 useless ?

If you installed battery patch, you are overclocking. You really should read the postings in this thread about that.

One thing to consider: While battery patch does in fact underclock the device sometimes, it only does so in certain conditions. In particular, it will only underclock when the device is closed (no keyboard showing) and the screen backlight is off. If you have the keyboard open, or have the config set to leave backlight on when plugged in, it will never underclock in those conditions.

Secondly, it may be underclocking that's causing you issues. Many people run overclock profiles without a problem (I run mine constantly at 500-900 without issue). But if you install batterypatch any time you add lots of new media that needs updating with tracker and the like, that can cause it to use lots more battery than it would normally . Let me explain:

Suppose you just flashed your device, and are setting up fresh. You install all your apps, and all the media you want, then later you plug it in to charge and go to sleep. At some point, tracker kicks in and goes off to find and index all the new media. What normally would happen is the system would ramp quickly up to 600Mhz and make all the thumbnails and what not it needs. Lets say that takes an hour, the device then has several more hours of sleep time to catch up and fully charge the battery.

With Batterypatch though, tracker is reniced (being a background process), and "IGNORE_NICE_LOADS" is set, so it will run for it's duration at 125Mhz only. In this case, even though tracker is running top notch, it will never kick up to a higher speed. What would normally take an hour running at 600Mhz before will take closer to 5 hours at 125Mhz. And since 125Mhz is an active mode (not sleeping), it will eat most of the power that would have gone to charging the battery (especially if using a low-power < 1A charger). If there's enough media, it may just run all night, and never have a chance to charge at all, using all the power it gets to index instead.

This is one of the dangers of tweaking parameters in the kernel for "optimal performance" for a certain use case. What may be fine for common use can cause problems when doing things that are less common, or not considered as part of the standard use case.

hey Karam. thanks for ur hard work but i have a question. why phone just stays at 720-805 mhz during call. isn't its dangerous for the cpu to be overclocked for a hour or more ?

that's true
i have made some mistakes

The new version of batterypatch is in extras
changelog:

* Fixed the problem causing to load cpu_sleep many times while idle
* Added new pausing scripts while in idle
* Added overclock-while-in-call profile
* Warning in description about overclocking
* Changed installation method: all KP49> has vdd1=0
* Installation results with clean dbus-scripts patch: only includes needed files


also batterypatch-testing has new tweaks which will hopefully increase the continues time of usage
but need some people to confirm it so i can move the changes to batterypatch

SOME INFO ABOUT NEW BATTERYPATCH
minfreq for overclock-call is 600
it's only activated until the call is answered

a new profile is created (overclock-while-in-call) which will be loaded directly after answering a call
it is the same as overclock (so 250 is min freq when talking on N900)
i made a this new profile so anyone can edit it separated from overclock profile (the one used by default)

@woody i have added warning about OC to description

i recommend any one who was disappointed from previous versions to try this one

testing battery patch testing 4.0. btw why you disabled vdd1 ?

are you using kernel-power 49 ? or pre50 ?

if [ "$kernel " == "2.6.28.10-power49" ]; then
kernel-config load default
mv /opt/dbus-scripts/overclock49-50 /usr/share/kernel-power-settings/overclock
mv /opt/dbus-scripts/overclock-call49-50 /usr/share/kernel-power-settings/overclock-call
mv /opt/dbus-scripts/overclock-while-in-call49-50 /usr/share/kernel-power-settings/overclock-while-in-call
mv /opt/dbus-scripts/underclock49-50 /usr/share/kernel-power-settings/underclock
else
rm /opt/dbus-scripts/overclock49-50
rm /opt/dbus-scripts/overclock-call49-50
rm /opt/dbus-scripts/overclock-while-in-call49-50
fi

this is part off postinst script
if you are using 49 or pre50 or 50
it will load the overclock profile with vdd1 enabled

/EDIT :
oops i have a problem (typo) in postinst with batterypatch-testing

i will fix it now
thank you for notifying me

/EDIT2 :
please update to 5.1 stable
or 4.1 testing

a problem encounter in stable v5.1
video is not playing continuously