Rockbox General > Rockbox General Discussion

Rockbox wont idle powerdown if music is paused and sleep-timer is set

<< < (2/3) > >>

saratoga:
I think it makes sense to have the idle power off still occur even if the sleep timer is set.  Logically at least I would expect power off conditions to be be OR'ed with one another, not have an unspecified one take precedence over the others. 

Besides, if you fall asleep with the music paused, no sense in wasting battery waiting for the sleep timer :)

[Saint]:
Wow...Ok, so, apparently I'm the only one that thinks the current behaviour is deliberate?

To me, it makes absolutely no sense to idle shutdown if the user has specifically chosen to shutdown the device at a predetermined time in the future. This is a choice the user made consciously, and shouldn't be ignored. For what its worth, I also don't think it makes much sense at all to idle shutdown when the device is paused, either, but this may be semantics - to me, paused != idle.


[Saint]

edfardos:
I think the important thing is that all desired behaviors are possible.   I don't personally ever use "stop", in fact, I modified the power/stop button so it does nothing but light up the display, and a long-hold shuts down the system.

User wants unattended playing music to end after an hour (sleep)
User wants a stopped device to power down after 10 mins (idle)
User wants a paused device to power down after 10 mins, but also wants unattended playing device to run for an hour (??)
User wants paused device to stay on for an hour (sleep)
User wants stopped device to stay on for an hour (idle)
User wants device to stay on until the battery is dead (neither)

Did I miss any?  Can we accommodate each scenario with idle, sleep, and reset-sleep-with-button?  I personally want unattended music to stop after an hour (I'm asleep), but I also want the unit to power down if it's not playing, because I paused it and threw it in my bag.  In all cases, I don't think anyone wants to pickup a device only to discover it's battery was flattened doing nothing.

This really is a cool project guys!  Lovin' this sansaclip w/ opensource rockbox,

-edfardos

[Saint]:
Setting the sleep timer is a deliberate action (granted, pausing the device is often a deliberate action as well) and should be respected. I don't want my player to shut down because I got up to go to the bathroom and temporarily paused playback. Nor would I want to have to adjust the idle timeout each time to overcome this.

We probably can't make a case that fits all users, but we can try to make one that makes the most sense, and personally I think we already have it.


[Saint]

Jason Arthur Taylor:
Hi all.  Saratoga was kind enough to have directed me here after I posted a bug about this issue to flyspray.  The url is http://www.rockbox.org/tracker/task/13058 in case anyone wants to read it there.  I guess I am supposed to discuss the issue here?  Certainly, we don't want to just change code arbitrarily.  Assuming that's the case, here goes.

As a preliminary matter, my calculations show that one should be able to easily quadruple battery life by using a shutdown of 2 minutes and a sleep of 30, if this feature were coded/allowed.  So this thread here isn’t trivial in nature.  It is huge.

Reading this thread I see that all but one person thinks this is a bug.  So, without getting into the details, the democratic thing to do might be to implement a patch, and to fix the problem that all but one person apparently thinks is a problem.

But perhaps we need to be sure.  If so, let me examine exactly what Saint and wodz said, and see if Saint is wrong or right, if that is instead the case.  Saint, hopefully you can explain your position in more detail in case you I mess up in my analysis.

Saint basically makes the case that if you want a computer to do something, it should do it.  The thing is that the normal use pattern of the sleep timer is to deal with unpredictability, not to do planned and definite things, like to cook eggs.

Saint wrote that,

"apparently I'm the only one that thinks the current behaviour is deliberate?

To me, it makes absolutely no sense to idle shutdown if the user has specifically chosen to shutdown the device at a predetermined time in the future. This is a choice the user made consciously, and shouldn't be ignored."

My first observation is that an assertion here Saint makes is actually incorrect. There is actually a popular option that resets the sleep timer upon any key-press, even if that keypress has nothing to do with the sleep timer.  So the timer isn’t normally invoked directly.

As an example, the typical use here is that someone is in bed with the intent of dosing off.  However, before that happens they might rewind a podcast or something, or adjust the volume briefly, or even use the player’s light.  The goal of the sleep timer here is to avoid having the player on all night long, no matter what, since you know you are going to sleep one way or the other.  And if you are awake and the player shuts down it isn’t a big deal.  You just can turn it on again.  So the auto-reset of the timer upon keypress is why it isn't true that the user has specifically chosen to shut down.  Not at all.  They selected the desire to have battery power in the morning.  That is what they wanted.  And to do it they used the auto-reset of the timer based on the last time they were clearly awake.  The method is to use the keypad as a sleeping/awake sensor, looking at any keypresses for anything.  I don't normally look at the clock, and set a time to have the unit turn off at all.  The sleep timer is constantly being reset all the time, especially since I want to use it during the day as well.  It should go on when I stop moving for a long time.  Or for instance if I take off the mp3 player because I am going swimming, or going to an event where I don't want an mp3 player, I want it to turn itself off. 

Secondly, even if we wanted a dictatorship, and I’m wrong in my intentionality argument above, if one really wants an mp3 player to go to sleep at a set time all they would have to do after the patch is in is to disable the inactivity shutdown timer, or set it to be longer than the sleep timer.  So, if you really want your player to go to sleep at a fixed time, you still will be able to, and you currently can, so there is no loss of a present feature by putting in the patch. So, even if I'm wrong, Saint you  will still have this feature you like with the patch. 

So even if I'm wrong, the patch should still go in.

That all said, let me comment about all other things Saint thus far has written.  He also wrote:

“I don't want my player to shut down because I got up to go to the bathroom and temporarily paused playback.”

The OP, edfardos, and many others have explained why the two different methods of shutting down are both simultaneously needed.  Moreover, the shutdown and startup process in flash-based mp3 players is actually super fast.  Long ago, this was not true.  So, unlike hdd mp3 players, use of shutdown and startup are really good ways to save battery life, especially with the auto-resume feature which Saint for some inexplicable reason is not using.  Un-pausing is only a little faster than turning on and auto-resuming, but one saves a lot of battery since nobody here has bothered to learn how to slow down the cpus when they aren’t being used.

The last thing Saint wrote that I haven’t addressed is this:

“I also don't think it makes much sense at all to idle shutdown when the device is paused “

IMO pause is used when there is a phone call or something.  But we all know a phone call can lead to a lot of other things.  At the end of the day, we need multiple methods of making sure the following DOES NOT OCCUR:  the player is on for no reason for a whole day or night.  We really need “sleep even though paused” capability because it is common for a player to be paused for an indeterminable amount of time.  All I know if I get a phone call when the player is on is that I'd better pause the mp3 player real fast, if it is running.  I have no idea when I will want it to resume, and I don't want to have to rush back to my residence because I forgot and left my mp3 player paused instead of in sleep shutdown because Saint doesn’t know about auto-resume.

Saint, please chime back in to explain if you still think we are all wrong.  Otherwise, let's get this bug patched to make our mp3 players last much longer between recharges.

The last thing I could comment about is the question by wodz about this being a bug as the OP says.  wodz says he has looked at the code and he thinks the code is designed to make sure the sleep timer prevails.   Well, that is in fact what the code does.  So, yes, if you just look at the code to determine intent, you end up with the current code being correct.  That is always the case, is it not, even if the code is wrong?  LOL.

And anyway, if the intent was to make sure the mp3 player was off via sleep within 30 minutes, and the inactivity timer shut the player off within 10 minutes, is not the desire that the player be off within 30 minutes not discharged if the player was already off 20 minutes early?  From a battery saving perspective, the answer is yes, and if we didn't care about saving power there would be neither sleep nor inactivity code at all.

I'd say the OP is instead correct, since if Saint were really correct we probably wouldn't even have these two separate times for inactivity and sleep in the first place.  The interface would be "either or" prior to being able to set these two timers; it would drop down to whichever method of automatic shutting down was preferred. 

We can also do some forensics, seeing who introduced the sleep code.  But that is too much for now.  Let's just look at the present code.  I think it says,

"/*
 * We shut off in the following cases:
 * 1) The unit is idle, not playing music
 * 2) The unit is playing music, but is paused
 * 3) The battery level has reached shutdown limit
 *
 * We do not shut off in the following cases:
 * 1) The USB is connected
 * 2) The charger is connected
 * 3) We are recording, or recording with pause
 * 4) The radio is playing
 */"

I didn't post this to flyspray but the 2nd #3 is no longer true since the sleep timer now also prevails there.  The coder who did the sleep feature apparently didn't do a complete job, and also broke the 1st #2, and didn't edit the comments either.  Why not? 

The best explanation is that the sleep timer coder didn't know he or she was breaking these features.  It is common for someone who wants a feature to focus just on their feature.  I'm guessing.  But if that guess is correct there didn't seem a need to edit these comments.  He was just trying to add a new feature.  I'd love to see the 2nd #3 and 1st #2 re-enabled. 

IMO, that the sleep coder seems to have patched the code in one particular and arbitrary way, unknowingly breaking two features, has little bearing on what we should do now that we realize he or she introduced two bugs.  Personally, I'm thinking the whole section could be rewritten, since this thread proves that the code isn't easy to understand. 

So, to sum up about the bug/feature debate, the current interface, and the manual, and the comments in the code itself all point towards this being two bugs and not some microsoft lawyer's vision of "hidden features". 

Cheers,
Jason Arthur Taylor jasontaylor.us

Navigation

[0] Message Index

[#] Next page

[*] Previous page