Kew is slow to start when loading large music collections

[pkreuzt]

Probably most people loads full music collection at start. If it is very large (I'm talking several GBs) it takes a long time to reach UI. In my case, collection is on a read-only NFS server, which worsens the issue (as it's over network an I can't save the playlist there).

Best way to solve this would be to save current playlist at exit on a dedicated config directory, and load it again automatically at start. This would probably need an extra switch on playlist UI to "clear" it easily without having to add subcommands to kew start (this benefits those using a .desktop file to start the program).

Or, at least, allow to specify placement for playlist file when saving it.

[ravachol]

Probably most people loads full music collection at start

Do you mean the 'kew all' command? Or just 'kew'?

Yes, the current approach is problematic if you have your music on a slow network drive. It can handle many GB music collections quickly though if it's on the same computer even on an old school hard-drive.

[pkreuzt]

Do you mean the 'kew all' command? Or just 'kew'?

I launch it as 'kew all' by default to have all library loaded as playlist at start, but using 'kew' alone is also slow. I've noticed the initial scan is quite fast actually (compared to other players), but it is somewhat redundant and takes this extra time on every start. On the other side, maybe it's just about the starting steps. Maybe the scan could be delayed to after UI is visible (and even playing). Not sure about this.

[ravachol]

"kew all" could be optimized away by making the "all" playlist at the same time as creating the library. Right now it's actually scanning twice when you run "kew all". This is because the library function was created long after the "kew all" function. Might I ask how long it takes to run just "kew" for you until you reach the UI?

The initial scan is really fast, yes. I didn't want to have a slow "update/recreate music library" function in the app, running in the background and slowing things down, that's why I went with a minimal fast scan.

But maybe we could introduce a config option to use a cached library and then a button to recreate it. Or something like that.

Btw, thank you for bringing this up.

[pkreuzt]

Probably not the best way to measure, but used 'time kew' and 'time kew all' (and inmediately pressed Q to have it closed at the end) to get some indication of time spent in both cases.

$ time kew

real    49,04s
user    0,42s
sys 2,67s
cpu 6%

$ time kew all

real    62,85s
user    1,66s
sys 5,58s
cpu 11%

EDIT: Forgot to mention before, this is kew 2.3.1 from Debian. In case version is relevant.

[ravachol]

That is indeed slow. I will probably make kew ask if the user wants to cache the library if it's slower than 4 seconds or something like that.

[ravachol]

In the latest commit, I have introduced caching of the library and made 'kew all' reuse the library information. It should be quick, you can try it if you want. Just download the latest zip file from here:

https://github.com/ravachol/kew/archive/refs/heads/main.zip

Just run make.

These are the changes:

• It's now possible to cache the library for faster startup times. You can change this in the settings file (kewrc), but if it's slow loading you will be asked once if you want to use a library cache or not.

• You can now press 'u' to update the library in case you've added or removed songs.

• Faster "kew all". It now bases its playlist on the library instead of scanning everything a second time.

[pkreuzt]

Now it starts much faster indeed. First time can be time consuming, but once kewlibrary is created, startup is instantaneous. Thank you very much.

I consider this issue solved. Should I close it or leave open it until next point release?

[ravachol]

Great! If there are any problems with it please tell. I'm closing it now.