• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System iPod Nano 2G
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Buschel - 2011-11-06
Last edited by speachy - 2024-04-21

FS#12369 - Unneeded mass storage accesses with dircache off

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.

Closed by  speachy
2024-04-21 13:01
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

Four more releases, a lot has changed.

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.

If this is the case we can close this.

Well, someone needs to verify. That it doesn't happen with dircache speaks against.

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.


                          && ! ((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.


Available keyboard shortcuts


Task Details

Task Editing