FS#12369 - Unneeded mass storage accesses with dircache off

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


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, 13:58 GMT
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, 06:50 GMT
If this is the case we can close this.
Comment by Thomas Martitz (kugel.) - Wednesday, 09 November 2011, 08:06 GMT
Well, someone needs to verify. That it doesn't happen with dircache speaks against.
Comment by Boris Gjenero (dreamlayers) - Tuesday, 20 December 2011, 05:09 GMT
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, 17:50 GMT
&& !defined(BOOTLOADER)

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