Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#13026 : Clip+ database is slow



FS#13026 - Clip+ database is slow

Attached to Project: Rockbox
Opened by John (plsng) - Tuesday, 03 February 2015, 20:02 GMT
Last edited by Michael Sevakis (MikeS) - Wednesday, 16 January 2019, 13:31 GMT
Task Type Bugs
Category Database
Status Closed
Assigned To No-one
Operating System Sansa Clip+
Severity Medium
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No


Using build 95fdad5.

The database on the Clip+ is very slow in loading: when you select an artist/album/..., it takes about a second or two for the list of albums/tracks/... to show up. On the latest stable release this is instant. This problem has likely been around since;a=commit;h=7d1a47c
This task depends upon

Closed by  Michael Sevakis (MikeS)
Wednesday, 16 January 2019, 13:31 GMT
Reason for closing:  Fixed
Additional comments about closing:  Original reporter saying it's fixed and request task be closed.
Comment by Michael Sevakis (MikeS) - Friday, 29 May 2015, 21:49 GMT
Yea, quite possible that has something to do with it. You said "likely" but didn't confirm. Yes, it disables some code for caching dircache pointers for the time being because of the dircache changes so, as a result, I wouldn't at this point consider it a bug but just a prompt to continue the project.

ETA: I haven't noticed that short lists take much time to populate. How many items in a list a we talking about?
Comment by John (plsng) - Saturday, 30 May 2015, 13:45 GMT
Opening the artist list (like pretty much everything else) is instant, but once you go a level deeper, i.e. to albums by a selected artist, the list of that artist's albums doesn't show up instantly but takes a noticeable amount of time, however the amount of items in the list doesn't seem to have a large impact on this as a list of 1 item and a list of 40 items took about the same amount of time to show up.

Also, possibly the most noticeable slowness is when adding anything from the database to a/the playlist. On the last stable build, this is instant (adding 1000 songs takes less than a second), but on the daily builds this takes a lot of time (adding 1 song already takes more than a second, adding 1000 takes excruciatingly long, about 20 seconds at least). However, this slowness in adding to playlists only occurs when you use the 'add to playlist' menu option. When you just click on one of the songs to start playing, the playlist is instantly populated with all the album's tracks.

Hopefully this has helped a bit in finding the cause.
Comment by John (plsng) - Sunday, 22 May 2016, 21:29 GMT
Comment by joshua (sigrokBlack) - Sunday, 21 August 2016, 16:59 GMT
The same on my Ipod 6g as mentioned here:,51425.0.html
Comment by John (plsng) - Wednesday, 25 January 2017, 20:53 GMT
Two years on, nothing has changed, the database is still completely unusable. Please prioritise fixing the speed (or lack thereof) of the database.
Comment by MichaelGiacomelli (saratoga) - Monday, 01 May 2017, 21:05 GMT
This is likely fixed in the new 3.14 release and newer.
Comment by John (plsng) - Tuesday, 02 May 2017, 09:12 GMT
Good to see a new major release, but I just checked and unfortunately it is not fixed. Maybe it got slightly better, but it's still unusable in its current state.
Comment by John (plsng) - Thursday, 28 December 2017, 12:15 GMT
Great news: a recent commit seems to have fixed this problem on the Clip+ and the Clip Zip. Adding hundreds of songs to a playlist is now near instant again, as it used to be. I don't have a Fuze to test right now, but assuming it was the same bug, both this and can now be closed. Many thanks!
Comment by John (plsng) - Tuesday, 15 January 2019, 09:28 GMT
Turns out this wasn't actually fixed either, it's still there on the most recent daily build. So this shouldn't be closed yet, and the reported issue for the Fuze should be reopened. Clips and Fuzes, and apparently iPod Classics, too, simply can't use the database.
Comment by Michael Sevakis (MikeS) - Tuesday, 15 January 2019, 22:48 GMT
You said it was fixed but that now it's not? I have a few ideas off the top of my head.

1) You don't have directory cache and Database:Load to RAM enabled now for some reason.

2) Something got broken in the builds.

3) Early technical debt: In the beginning, RAM was large, storage relatively small and assuming everything could fit it RAM was somewhat reasonable. So, all caching was implemented with the dictum of "cache everything at once or nothing at all". If you've overrun the memory by having a large number of tracks, some cache functionality will quietly just not work, resulting in slower access of the database than if everything had fit. The directory cache will cache everything it can and still function with what it is able to load. On the other hand, the database code will simply disable the RAM caching completely if it cannot load it in its entirety. Edit: Has your database track count increased substantially recently?
Comment by John (plsng) - Wednesday, 16 January 2019, 08:13 GMT
Actually, I apologise for the false positives and false negatives. I was repairing a couple of Clips last week, and it turns out I'd switched one still running an older version of Rockbox with a fully up to date one, which is working just fine. So, the final verdict on the Clip series is that the database is perfectly usable, and this issue can with 100% certainty be closed. Your comment about Load to RAM made me recheck the Fuze that was still giving me problems, turns out it did indeed get disabled at some point, and re-enabling it solved the problem, so I believe the other reported issue can remain closed. Thanks for your help!