• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Database
  • Assigned To No-one
  • Operating System Sansa Clip+
  • Severity Medium
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 2
  • Private
Attached to Project: Rockbox
Opened by plsng - 2015-02-03
Last edited by MikeS - 2019-01-16

FS#13026 - Clip+ database is slow

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

Closed by  MikeS
2019-01-16 13:31
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

Original reporter saying it's fixed and request task be closed.

MikeS commented on 2015-05-29 21:49

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?

plsng commented on 2015-05-30 13:45

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.

plsng commented on 2016-05-22 21:29


The same on my Ipod 6g as mentioned here:,51425.0.html

plsng commented on 2017-01-25 20:53

Two years on, nothing has changed, the database is still completely unusable. Please prioritise fixing the speed (or lack thereof) of the database.

This is likely fixed in the new 3.14 release and newer.

plsng commented on 2017-05-02 09:12

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.

plsng commented on 2017-12-28 12:15

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!

plsng commented on 2019-01-15 09:28

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.

MikeS commented on 2019-01-15 22:48

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?

plsng commented on 2019-01-16 08:13

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!


Available keyboard shortcuts


Task Details

Task Editing