Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Database
  • Assigned To No-one
  • Operating System iPod 5G
  • 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 Xebozone - 2007-09-29
Last edited by bluebrother - 2009-12-06

FS#7861 - Poor performance until database is initialised

I posted a bug a while ago about the very slow menus on the iPod and ways to make it faster to scroll through a large database.

What I didn’t realise is that the reason it was slow was because of a bug!

The problem is fixed when the database is initialised!
I have my database set to load into the ram, and haven’t tested this to see if this is the final solution and I haven’t tested it with the database not loaded into the ram, but it does work for me!

Perhaps manually telling the database to initialise loads it into the ram?

If this is the case, then if “Load Database into RAM” is set to “Yes”, then the database should be initialised when Rockbox is booted, (and after the setting has been set to ‘yes’ if it wasn’t already, of course).

Closed by  bluebrother
2009-12-06 14:36
Reason for closing:  Fixed
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

Doesn't occur anymore according to reporter, no comments since almost a year. Should be fixed, if not please file a new issue.

After playing a song, it slows down again… Maybe the database is automatically initialised on startup?

If it is, then playing a song seems to replace the database in the RAM with buffer information for the song, slowing the database down again.

If this is true, then a fix needs to be implemented so that the database is stored in the RAM in a secure location that isn’t replaced by the audio buffer until “load database into ram” is set to “no”.

MikeS commented on 2007-09-29 07:53

If it’s during disk access by the database thread, this might be a threading priority problem which still does in fact exist to some extent. Those won’t really be fixed without priority inheritance implemented.

1. Even bore playing any song, I need to ‘initialise’ the database
2. After starting a song, I can browse through part of the database that’s on the screen, or near the screen without a slowdown, but after scrolling for a bit, it slows down again, even if returning to the same area again (that was initially fast). An initialisation while the audio is playing speeds things up temporarily, until, of course the database ram is erased by the audio buffer
3. After pausing or even stopping the playback, the database is still slow until it’s initialised again.

All three of these reasons support a ram issue, not a disk access priority issue :)

edit:

1. Even before…

i think this bug does not exist any longer, does it?

the bug seems to be fixed now :)

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing