Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Battery/Charging
  • Assigned To No-one
  • Operating System SW-codec
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by mikeholden - 2006-07-02
Last edited by jdgordon - 2008-07-08

FS#5624 - Runtime estimate very pessimistic

Now that the battery drain problem has been resolved, we need to update the expected runtime constant for the iriver h3x0. The current estimate is about 9 hours, but this is very low now.

I have added this bug with severity=High, when at first glance it appears a low priority cosmetic change. On further thought, it is something that is likely to raise bug reports from new users when they say “using iriver I get 16 hours, how come I only get 9 hours with Rockbox?” - they don’t see beyond the estimated runtime on the screen.

My testing reveals that using 128kbps mp3 files, caption backlight on and backlight timeout at 15 seconds, I got 17 hours 35 minutes continuous playback before the unit powered off.

Closed by  jdgordon
2008-07-08 03:56
Reason for closing:  Out of Date
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

each target needs to be fixed individually and this report was origioanlly for h300 which has been fixed

nls commented on 2006-11-10 18:25

I changed the description of this task as the runtime estimate problem
applies to all SWCODEC targets, and closed a couple of other tasks reporting
the same problem for individual targets.

I do however see a problem with fixing this as there are so many factors
that affect the battery life. Beside the factors that apply to the Archos
players there’s now also codec choice, and a range of bitrates for each codec
there’s also a whole range of DSP effects and caches etc.

The possible solutions I see to this problem are as follows.
1) Make a “standard” estimate, i.e. default settings, 128kbps mp3.
2) Make some sort of learning system that remembers the battery state
when charging and how much runtime was had between charges and make some
calculated average. This seems to bee too much complexity for such a small
feature but would be nice if anyone would care to code it.
3) Drop the feature for SWCODEC platforms (definitely the most KISS solution)

Is this still an issue? The estimates on the e200 seem pretty realistic to me.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing