Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#12369 - Unneeded mass storage accesses with dircache off

Attached to Project: Rockbox
Opened by Andree Buschmann (Buschel) - Sunday, 06 November 2011, 12:57 GMT+2
Last edited by Thomas Martitz (kugel.) - Sunday, 25 December 2011, 18:49 GMT+2
Task Type Bugs
Category Music playback
Status New   Reopened
Assigned To No-one
Player Type iPod Nano 2G
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Private No

Details

With r30907 (and also back to at least r30809 which I tested as well) I experience unneeded mass storage accesses on my iPod nano2G. I do not see this effect on my iPod Video.

Use case:
- Create a playlist from either DB or file browser
- Let buffering finish
- Skip forward track by track
(I use mpc/mp3/aac with embedded album art.)

Effect seen: For some skips I see short flash accesses (much shorter than full rebuffering).

This only happens if dircache is off. With activated dircache this effect is gone.

As such mass storage accesses are severely impacting the battery runtime on HDD targets I hope we get this figured out before v3.10.
This task depends upon

Comment by Thomas Martitz (kugel.) - Sunday, 06 November 2011, 14:58 GMT+2
It could be that some playlist information is flushed to disk.

That the effect is not visible on the video suggests it goes through the idle storage interface which delays stuff to the next spin up on HDD. I believe it's instant on flash but not sure.
Comment by Andree Buschmann (Buschel) - Monday, 07 November 2011, 07:50 GMT+2
If this is the case we can close this.
Comment by Thomas Martitz (kugel.) - Wednesday, 09 November 2011, 09:06 GMT+2
Well, someone needs to verify. That it doesn't happen with dircache speaks against.
Comment by Boris Gjenero (dreamlayers) - Tuesday, 20 December 2011, 06:09 GMT+2
Track changes call status_save() via playlist_update_resume_info(). Without HAVE_RTC_RAM, that calls register_storage_idle_func(), and without USING_STORAGE_CALLBACK, that immediately calls the function: write_nvram_data() which writes the nvram file. So, some flash access on track change is to be expected. This seems reasonable, and I suggest closing the task as not a bug.

However, I don't know why dircache would make it not happen. Maybe it just becomes so fast that you don't notice it.
Comment by Thomas Martitz (kugel.) - Sunday, 25 December 2011, 18:50 GMT+2
#define USING_STORAGE_CALLBACK (CONFIG_PLATFORM & PLATFORM_NATIVE) \
&& ! ((CONFIG_STORAGE & STORAGE_NAND) \
&& (CONFIG_NAND == NAND_IFP7XX)) \
&& !defined(BOOTLOADER)

That means it is enabled on flash as well. It's only disabled on sim/raaa, bootloader and the abandoned iriver ifp.

Loading...