Rockbox

Tasklist

FS#5624 - Runtime estimate very pessimistic

Attached to Project: Rockbox
Opened by Mike Holden (mikeholden) - Sunday, 02 July 2006, 11:05 GMT
Last edited by Jonathan Gordon (jdgordon) - Tuesday, 08 July 2008, 03:56 GMT
Task Type Bugs
Category Battery/Charging
Status Closed
Assigned To No-one
Operating System SW-codec
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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.
This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Tuesday, 08 July 2008, 03:56 GMT
Reason for closing:  Out of Date
Additional comments about closing:  each target needs to be fixed individually and this report was origioanlly for h300 which has been fixed
Comment by Nils Wallménius (nls) - Friday, 10 November 2006, 18:25 GMT
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)
Comment by Marc Guay (Marc_Guay) - Friday, 28 March 2008, 21:15 GMT
Is this still an issue? The estimates on the e200 seem pretty realistic to me.

Loading...