Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Deprecated: Function create_function() is deprecated in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/rockbox.org/flyspray/adodb/adodb.inc.php on line 845 Deprecated: Function create_function() is deprecated in /sites/rockbox.org/flyspray/includes/class.user.php on line 111 FS#7861 : Poor performance until database is initialised

Rockbox

Tasklist

FS#7861 - Poor performance until database is initialised

Attached to Project: Rockbox
Opened by Mark (Xebozone) - Saturday, 29 September 2007, 03:13 GMT
Last edited by Dominik Riebeling (bluebrother) - Sunday, 06 December 2009, 14:36 GMT
Task Type Bugs
Category Database
Status Closed
Assigned To No-one
Operating System iPod 5G
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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).
This task depends upon

Closed by  Dominik Riebeling (bluebrother)
Sunday, 06 December 2009, 14:36 GMT
Reason for closing:  Fixed
Additional comments about closing:  Doesn't occur anymore according to reporter, no comments since almost a year. Should be fixed, if not please file a new issue.
Comment by Mark (Xebozone) - Saturday, 29 September 2007, 03:25 GMT
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".
Comment by Michael Sevakis (MikeS) - Saturday, 29 September 2007, 07:53 GMT
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.
Comment by Mark (Xebozone) - Saturday, 29 September 2007, 08:01 GMT
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 :)
Comment by Mark (Xebozone) - Saturday, 29 September 2007, 08:02 GMT
edit:

1. Even before...
Comment by Johannes Linke (Jaykay) - Wednesday, 17 December 2008, 15:12 GMT
i think this bug does not exist any longer, does it?
Comment by Mark (Xebozone) - Saturday, 27 December 2008, 00:40 GMT
the bug seems to be fixed now :)

Loading...