Rockbox Technical Forums
Support and General Use => Hardware => Topic started by: eicca on February 15, 2021, 10:34:41 PM
-
Normal battery life when running Apple firmware, but when playing fairly low bit rate mono-channel talk show MP3s in RockBox I'm seeing a battery loss as nasty as 20% in ten minutes.
I'm using a 256GB SD card and an iFlash adaptor, brand new battery. I've tweaked all the settings I can think of to reduce disk and screen usage.
Any pointers? Known config combinations to help out?
-
I think with the stock hardware your device gets something like 20 hours battery life with normal files.
Maybe the modified storage has some problems? Is the device getting extremely hot while in use?
-
No temperature problems. This is my second iPod Mini I've tried in an attempt to rectify this issue.
I'm going to run a rough benchmark in stock firmware but even playing lossless in Apple FW lasts noticeably longer than playing cruddy MP3 in RockBox.
-
Stock firmware benchmark is still in progress, but it's been going for six hours now and is still showing at least 75%-ish battery. Now I know the graphical meter thingy isn't really accurate but last time I benchmarked RockBox it only went about five hours before shutting off.
-
Apple firmware resulted in 20 hours of playback.
RockBox benchmark is currently in progress, playing the same album on repeat at the same approximate volume as in the Apple firmware test. It's only been an hour and I've already lost 20%. Terrible. Database loads to RAM, doesn't auto-update, all audio enhancements are off. Backlight is off, hold switch is on. Directory Cache is off since I never use the file browser.
What debugging can I do to find out why the drain is so abysmal?
-
It's getting worse! Just sitting idle I'm watching my battery drop 1% every few minutes, backlight off!
Still no problems in the Apple firmware.
Really need some help, devs!
-
It's getting worse! Just sitting idle I'm watching my battery drop 1% every few minutes, backlight off!
Still no problems in the Apple firmware.
Really need some help, devs!
What did your battery bench end up at?
Using one of the latest dev builds I go 10 hours 31 minutes which seems to be fairly standard in comparison to these benchmarks.
https://www.rockbox.org/wiki/IpodRuntime (https://www.rockbox.org/wiki/IpodRuntime)
-
Barely five hours.
Are you using a CF card? Stock microdrive?
In another thread it seems that my CF-SD adapter doesn't support ATA power management and is being kept active 100% of the time. Wondering if an actual CF card will do the trick. There's an 18-hour benchmark in the runtime wiki with a CF card back in 2009.
-
I have a patch in gerrit that should improve battery life, but it's awaiting more testing -- the last thing anyone wants to cause data corruption again.
-
I have a patch in gerrit that should improve battery life, but it's awaiting more testing -- the last thing anyone wants to cause data corruption again.
Early testing seems to indicate there's no corruption problem, so I went ahead and committed it.
So please grab the latest dev build (or 2012-03-12 or newer) and see if that brings the battery consumption back into the expected range.
-
I have a patch in gerrit that should improve battery life, but it's awaiting more testing -- the last thing anyone wants to cause data corruption again.
Early testing seems to indicate there's no corruption problem, so I went ahead and committed it.
So please grab the latest dev build (or 2012-03-12 or newer) and see if that brings the battery consumption back into the expected range.
On it! Will test and report back. Thanks for looking into this.
-
I will test this too.
-
Newest release I'm seeing in the dev builds is 3/11. How soon should the patched version show up?
EDIT: UTC time on the commits is throwing me off. What build number should I look for?
-
"dev builds" come from https://build.rockbox.org/ and are updated after every commit.
"daily builds" come from https://www.rockbox.org/daily.shtml and are generated early every morning.
A daily build with these specific changes will happen early tomorrow morning, but it is present in the current dev builds.
-
Gotcha. So 043e8a0c5c is the version to try.
-
Alright, initial results don't look good. It's only been going for thirty minutes and 10% of the battery is already gone. That's still only about five hours at this rate.
-
What matters is the total runtime, not how long it takes to drop from two arbitrary points on the power curve -- The percentage mapping was tuned for new(ish) stock batteries, and as batteries age do does the discharge curve. And of course there's no guarantee that a random ebay replacement battery has the same chemistry/capacity/durability as what Apple originally shipped.
As an example of this, last year before I reworked the xDuoo X3's battery curve, the last four hours (out of about twelve) had rockbox claiming there was only 5% battery remaining.
-
Well I started the test at 4:25pm and it made it to 9:58pm before shutting off. 5 hours 33 minutes. This was looping the same album that resulted in 20 hours on the Apple firmware with a brand new (eBay) battery.
When I go to "show disk" in the Debug menu, there's a bunch of power management and such items that say "not supported." I imagine that has something to do with it, but I'm still confused why there's such a huge discrepancy.
-
Unfortunately having some problems with the new build.
I am using an iflash adapter. Just set it up to run a battery bench but came back to an error after a minute or so.
Also seems to have an issue handling when it's unplugged from a computer. This also resulted in a crash.
When plugging into Windows it detected an error with the storage which it scanned and then said there was no error.
-
The write error is unrelated to this is essentially a "write timeout". It's most likely completely unrelated to this powermgmt change, because we don't actually shut anything down until the disk subsystem has been idle for several seconds.
The failure to mount after unplugging is almost always due to some filesystem error, typically caused by unsafe disconnects. Windows detected something wonky, so there was clearly something wrong.
Can't comment on that first data abort panic, except perhaps that all three are due to the same underlying disk corruption. It's easy enough to back out the change re-enabling shutting off power to the "disk" but to be honest I don't think what you saw is due to this.
(The best way to make sure here -- grab the 2021-03-11 and 2021-03-12 daily builds, and see if they behave any differently. Please unzip the builds via apple disk mode and do a disk check too just to be safe, afterwards have at it and see what happens. if 3-12 crashes as you describe but 3-11 does not, then we'll have pretty good confidence what's causing this...)
The same goes for the decrease in battery life; I don't doubt that it's real, but if there is no improvement with 3-12 (versus 3-11) then it's looking increasingly unlikely that it has anything to do with the "iflash fixes" being discussed here. If you're willing to be a guniea pig I can generate a one-off build that reverts to the known-corrupting pre-fix state (ie issue SLEEP commands), to confirm this theory.
-
Well I started the test at 4:25pm and it made it to 9:58pm before shutting off. 5 hours 33 minutes. This was looping the same album that resulted in 20 hours on the Apple firmware with a brand new (eBay) battery.
When I go to "show disk" in the Debug menu, there's a bunch of power management and such items that say "not supported." I imagine that has something to do with it, but I'm still confused why there's such a huge discrepancy.
I have the same issue actually. Using a 64GB MicroSD in a CF-SD adapter. Also says "not supported" for power_mgmt, noise_mgmt and read_ahead.
Current running time is at 5h:44m, tho it has been at 0% for a couple mins now.
I listened to tracks on shuffle, about a 50/50 mix of flac and 320kbit mp3
-
The same goes for the decrease in battery life; I don't doubt that it's real, but if there is no improvement with 3-12 (versus 3-11) then it's looking increasingly unlikely that it has anything to do with the "iflash fixes" being discussed here. If you're willing to be a guniea pig I can generate a one-off build that reverts to the known-corrupting pre-fix state (ie issue SLEEP commands), to confirm this theory.
What are the circumstances that cause the data corruption? Is it only when copying files from a computer or does it happen when just using the device? I only ever copy data when in Apple firmware because my Mac won’t read it otherwise, and so far the only data corruption I’ve had was with certain old cards I was trying to run tests with. My primary SD card has worked flawless. Other than the horrific battery life.
-
The write error is unrelated to this is essentially a "write timeout". It's most likely completely unrelated to this powermgmt change, because we don't actually shut anything down until the disk subsystem has been idle for several seconds.
The failure to mount after unplugging is almost always due to some filesystem error, typically caused by unsafe disconnects. Windows detected something wonky, so there was clearly something wrong.
Can't comment on that first data abort panic, except perhaps that all three are due to the same underlying disk corruption. It's easy enough to back out the change re-enabling shutting off power to the "disk" but to be honest I don't think what you saw is due to this.
(The best way to make sure here -- grab the 2021-03-11 and 2021-03-12 daily builds, and see if they behave any differently. Please unzip the builds via apple disk mode and do a disk check too just to be safe, afterwards have at it and see what happens. if 3-12 crashes as you describe but 3-11 does not, then we'll have pretty good confidence what's causing this...)
The same goes for the decrease in battery life; I don't doubt that it's real, but if there is no improvement with 3-12 (versus 3-11) then it's looking increasingly unlikely that it has anything to do with the "iflash fixes" being discussed here. If you're willing to be a guniea pig I can generate a one-off build that reverts to the known-corrupting pre-fix state (ie issue SLEEP commands), to confirm this theory.
Ok confirmed crashed happen on 2021-03-12 but not on 2021-03-11
-
Ok confirmed crashed happen on 2021-03-12 but not on 2021-03-11
Thank you for confirming this. The only meaningful change between those two is that 03-12 allows turning off the power supply to the drive, which happens 2 seconds after the last I/O operation is reported as complete by the drive.
Clearly the iFlash adapter is lying, and it's still writing stuff in the background even two seconds later. So, as another attempt to mitigate this, I've increased the poweroff delay to a full five seconds. Please test the most recent dev build (2743bde0 or newer include it) and see if it still crashes/corrupts things on you?
-
Testing 2743bde0 for battery life now.
Mine still has never crashed (other than the aforementioned old wonky memory chips)... is there something that is known to trigger a crash or corruption that I should try?
-
Ok confirmed crashed happen on 2021-03-12 but not on 2021-03-11
Thank you for confirming this. The only meaningful change between those two is that 03-12 allows turning off the power supply to the drive, which happens 2 seconds after the last I/O operation is reported as complete by the drive.
Clearly the iFlash adapter is lying, and it's still writing stuff in the background even two seconds later. So, as another attempt to mitigate this, I've increased the poweroff delay to a full five seconds. Please test the most recent dev build (2743bde0 or newer include it) and see if it still crashes/corrupts things on you?
Ok I've tested the dev build.
Internal storage can't be accessed when in rockbox mode. It freezes for 30 seconds or so before displaying the cable diagram but it never mounts on windows once you unplug it crashes with the mount error.
I'm still getting the crash which seems to happen exactly on the 5th minute after pressing play.
Also when trying to access the battery_bench app it gets stuck on loading then it either crashes or displays can't access the file.
-
Roast, what brand SD card are you using? I had similar errors but only with an older DaneElec card. My Lexar Professional isn't giving me any errors on 2743bde0.
But it also doesn't look like there's any improvement either. Still draining at the same rate.
-
Roast, what brand SD card are you using? I had similar errors but only with an older DaneElec card. My Lexar Professional isn't giving me any errors on 2743bde0.
But it also doesn't look like there's any improvement either. Still draining at the same rate.
☠️😓 Geez I just broke my click wheel connector.
But I am using a SanDisk ultra 128gb, or I was...
So I'm out of the game until I get a replacement.
-
Well runtime with 2743bde0 is identical to everything else I've tried. 5 hours 30 minutes of playback.
-
Any update on this? Would really like to be able to use my iPod Mini for more than two hours before having to charge it...
-
Has anyone tested stock Mini 2G hardware recently? The benchmarks on the wiki are more than a decade old and predate a lot of the power management improvements. It would be interesting to know if there is some general regression.
-
Other than my last tests, posted in this thread, I haven't done anything official.
It would seem RockBox doesn't play nice with the Tarkan CF-SD adaptor. In the "disk info" section of debug, all "power management" entries show "unsupported." That probably has something to do with it.
I grabbed a few old CF cards to run tests with but apparently they were all bad and kept throwing errors during setup.
-
It would seem RockBox doesn't play nice with the Tarkan CF-SD adaptor. In the "disk info" section of debug, all "power management" entries show "unsupported." That probably has something to do with it.
That is actually what you were testing on the last page of this thread. The issue is that those adapters don't actually support a lot of the power management stuff in the ata spec, so if you try to use it they crash or corrupt data.
-
Crap, so am I still looking at shelling out big bucks for a high-capacity CF card?
Or is there a known-working CF-SD adapter that'll play nice with the power management?