Just for the record: I have just discovered my hot n900 with timenowd using 90% of my cpu without any reason. As I was not able to reproduce this situation, I guess there must be a race condition somewhere.

What is sure is that it started when the n900 was idle and continued after I started to use it again, resulting ( what a shock ) in a huge battery drain

I saw in your controlPolling fuction (timeow-0.0.10)

void manager::controlPolling(QString status){
if (status == MCE_TK_LOCKED) {
modifyProximitydState("turnOn");
} else {
modifyProximitydState("turnOff");
pressPowerTimer->stop();
// killEverybody();
}
}

Should we comment out the call to modifyProximitydState, because as far as I understand, not commenting this would cause de-registre/re-register the timenowd process with proximityd, and there are no set interval call, so the polling interval would be set to default 100ms, which consume battery a lot. And these call are not necessary as the app would only need to register to proximityd once during it lifetime (which was done in the constructor for manager) (IMO)

I have test with a dummy process for timenowd which set polling interval to the highest of 2000 ms, and the battery consumption is only about 2mA, which is very good, while with the current version of timenow, the power consumption would be 6-8mA even if I set interval to 2000. (And my typical bat. consump. is about 8mA, so which timenow it would reduce batt. life to 50%)

Could this be the culprit?

I'm trying to test but not success with building the package yet.

the reason that line was there was that there is no reason to have proximityd poll the sensor when the phone is unlocked. We could just set the interval again after each register.

Unfortunately I have broken my dev environment for Fremantle right now so I can't test right away, but I'll have it in mind for when I set it up again.

You should be able to build though through qtCreator with fremantle target using the defaults.

I have found another problem.there are too many timenow process, and it seems all of them register to proximityd,but only one set interval to desired value(setting file), the other uses default interval which is 100ms.the way proximity work is that it poll based on the lowest interval process, this render the setting useless.

If you set by hand the interval for all timenow process, then it will work correctly.

You can test this: if the screen black immediately when you cover the proximity sensor,then proximityd is polling at 100ms.

There shouldn't be more than one process.
What do you see in htop? Is there something that can point us out to why more than one process exists?

$ ps | grep timenowd
3625 user 2084 S sh -c run-standalone.sh /opt/timenowd/bin/timenowd
3626 user 2084 S /bin/sh /usr/bin/run-standalone.sh /opt/timenowd/bin/
3635 user 25292 S /opt/timenowd/bin/timenowd
3637 user 2088 R grep timenowd


But I found out that the prob is not by many timenowd processes,but because timenowd failed to change interval (qdebug() does not show intervalRegistered, use a new message when change interval solved this)

On other thought, maybe we should save setting values as some static variables instead of reading from disk,it should save some battery.
The static variable can also be used to store current brightness settings, then we can reduce brightness to minimum when showing the time, then restore original value when screen is locked again.

Just some thought....

[Edit] I saw in the shcript file there is a line for reduce brightness, but it was commented out, I removed the comment and it seems to work fine so far(brightness dim when show lock screen and return to normal when unlocked) and this is great especially when you are sleep and does not want to be waken up by the too bright light from the screen.

I have changed my interval to 2000, and it takes about second to go back to black when I cover the sensor, so I think the interval setting is set correctly in my system.

Ps. If I remember correctly I also had two lines in the ps listing with reference to timenow, when I tried to troubleshoot the starting problem. One starting with the "sh -c..." start and other with "/sh/bin/...." start. My processes can be found in one of my previous post concerning the stop-killall-start routine.

You can go to proximityd website, register a fake process, change it interval to 2000, then test the output. Then you can be sure it is changed correctly.

Another hint is that if the interval is set correctly then battery time should be normal

http://www.mediafire.com/?c3uh4814ivagkii

Above is my modified version of timenow (source)

And below is the compiled version, please note the version information is not correct (default to timenow 0.0.1), so therefore, this is for brave soul want to test only. . It has some debug information so if run in console we can see its output.

http://www.mediafire.com/?dkv51wl0v1k7p8a

cantruchd do you have a github account? If yes please fork and create a pull request, if everything is proven to be ok I'll merge your code.

the processes you see I think are not multiple, just ps prints one line for every program in the chain (sudo shell, sh, run-standalone and actual timenow). I'm not sure this is the correct explanation though, a more experienced linux user should tell us.