Bug 180078

Summary:	Cannot Defer Playlist Scan at Start
Product:	[Applications] juk	Reporter:	Dave Taylor <me>
Component:	general	Assignee:	Scott Wheeler <wheeler>
Status:	CONFIRMED ---
Severity:	wishlist	CC:	cardinalidiego, ggrabler, mpyne
Priority:	NOR
Version First Reported In:	19.12
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Dave Taylor 2009-01-08 23:54:33 UTC

Version:           3.2 (using KDE 4.1.2)
OS:                Linux
Installed from:    Ubuntu Packages

When I start Juk it takes quite a duration to get to the point where I can play a song. I have a reasonably large collection of songs and the scan at startup can take some where close to two minutes and makes the HD go ballistic (I would test but Juk just refuses to start at the moment). Would it be possible to either defer this process from the start or to somehow query the directories for files that have a time stamp later than the last scan so that the lengthy process needn't be run at every start (maybe nepomuk/strigi would be up to this if they are in a working state).

Comment 1 Georg Grabler 2009-01-25 06:20:14 UTC

Would be possible, but could take some changes in JuK (playlist management - foreground and background).

Probably good to detatch it like amarok does, simply put scanning in the tray, and start up by constantly adding files to the playlist, starting the detached process with a lower priority for keeping the rest of the system responsive enough.

I lately bothered with a similar problem in QT, not sure how this could be done in KDE though.

Comment 2 Michael Pyne 2009-01-25 06:27:23 UTC

There's probably some low-hanging fruit for improvement in this sphere (some of which I worked on before the KDE 4.0 release).  However I haven't really planned on revamping the loading logic until after I get JuK ported to Qt4's model/view architecture which I haven't had time for yet.

The real answer long term may be to switch the cache to a database and then ensure we only load data on demand.

Please note that there *is* a cache.  You shouldn't get JuK saying that it's "reading tag from from file ..." messages on every startup, if so that's a separate bug than what I think you're referring to (slow startup).

Comment 3 Dave Taylor 2009-01-25 21:19:07 UTC

To be fair I shouldn't have tried to have pinned down the root cause when I know nothing of the internals of Juk, my reason for lgging this fault is the lengthy start time of Juk. The start time as I have just taken it is 1 minute and 50 seconds. 

Start process description
-------------------------
During this period the splash screen displays a loading text label with a number to the right of it that count up to 5541 during this time the GUI does appear and the Collection list does populate however the track list is not available and is not available for some time after the splash screen has disapeared. During all this time the HDD is making a lot of noise.


I didn't realise there was a cache and it was that loading that takes up such a long time. If it is of some assistance the cache that I have is 2.1MiB, the playlists file is 9.9 MiB and the covers file is 12B. Juk is using 175,216K of memory and 24,880 od shared memory.

Comment 4 lupccs 2020-08-10 23:27:25 UTC

Eleven years later and we still have that problem, at least on kubuntu 20.04