+++ This bug was initially created as a clone of Bug #263759 +++ Version: 2.8.0 (using KDE 4.11.2) OS: Kubuntu 13.10 Amaroc cold start (i.e. the first after login) takes about 3 to 5 minutes on my PC (not much CPU load). Every next start is OK, about 5 seconds, but the first one is terribly slow if I just want to play some music. Reproducible: Always Library contains ~7000 mp3 files. Playlist contains ~300 mp3 files. All tracks are on local disk. The system is 8 core 8 GB RAM with 2 TB HD, with no other CPU/HD intensive tasks running in parallel. Looks like amarok scans the entire library each time on startup, delaying started playback, but this is only my guess. Please advice how to find the root cause. If the problem is because of re-scanning the local collection on each startup, there are multiple ways to fix that: 1) Start rescan in different thread. I have 7 cores more which are not doing anything useful anyway :-). 2) Rescan only files in playlist or even only current file to be played and continue with the rescan during the playback. 3) Why to rescan if not requested? I do not change my collection often. Add an option for rescan on demand. 4) ... be creative ...
Did you erase your configuration files? Please test this with a new user as well.
Yes I did erased, doesn't help at all. How I can trace what amarok does on startup?
Start it from the command line with 'amarok -d --nofork'
Start it from the command line with 'amarok -d --nofork' Of course, please make sure you do not use any 3rd-party scripts to start with.
FWIW: I can't reproduce any of this, local collection (on an external HD attached by USB 3.0) 18'000+ tracks, playlist 35 tracks, cold startup time 3 seconds (with the options -d --nofork), Amarok v2.8.0-106-g81ad305 on KDE .11.3, Kubuntu 13.10. My basic system runs on an SSD.
Hi, I also experienced a very slow amarok lauch, always and only at the first start. I can't tell how long but it took waay longer than firefox at the time. I think the problem for me was that I used only Amarok and nothing else of the KDE suite (on gentoo). So probably Amarok's launch triggered some KDE initialization that would have already been processed at bootup on 'normal systems'. Perhaps Andrey's problem is situated similarly? regards, Johannes
>3) Why to rescan if not requested? I do not change my collection often. Add an option for rescan on demand. This is what I've been praying for ages, but it has fallen on deaf ears. But the case that "Management" completely decides against the users is very familiar to me from a project called Discogs ;-) "FWIW: I can't reproduce any of this, local collection (on an external HD attached by USB 3.0) 18'000+ tracks, playlist 35 tracks, cold startup time 3 seconds " Yes, that's because you're using Amarok differently as we do. Andrey has _300_ files on his playlist, and you have a little than a tenth of it, which is a comparison like apples to oranges. One day it WILL happen. I tell you. One day there'll be a fork of this thing which _does_ have rescanning optional, since if heads in "upper floor" are obviously made of concrete, users will have to take the sledgehammers and smash the concrete themselves. Yes it's called rebellion, but this is sometimes really necessary to give bureaucrats a stern talking-to. P.S. How did you get the idea to close bug 263759 anyway? To me it means "let us do things as we want to, you users can go to hell". And why do you, Myriam, who is obviously not really a programmer of this thing, always try to make decisions as if you were the developers themselves? Why not let the developers speak up DIRECTLY here and have a word? It doesn't feel like in an open-source project, this feels like talking with a politician through a "press agent" proxy.
Created attachment 83906 [details] log file on cold startup As proposed, I've started amarok with debug flag. This didn't helped much as one could not see timestamps in the log file. Also I've modified command line to: amarok -d --nofork 2>&1 | awk '{ print strftime("%H:%M:%S"), $0; fflush(); }' >> ~/amarok.log With this command I've generated attached log. Check the line 452-453, where amarok waits 5 minutes! 18:19:10 amarok: [EngineController] slotStateChanged from 1 to 4 18:25:26 amarok: [00;32mBEGIN:[00;39m void EngineController::slotMetaDataChanged() On "warm" restart this lines show *zero* seconds difference. I think Johannes idea that amarok triggers initialization of some KDE parts could be right, because I observed the long start almost always after full reboot, but seldom after only switching user. That said, I'm not using nepomuk/akonadi stuff, neither any PIM/mail functionality from KDE. So if amarok for some strange reason depends on akonadi services and waits until some timeout before starting through? Any idea what amarok is doing between [EngineController] slotStateChanged from 1 to 4 and BEGIN: void EngineController::slotMetaDataChanged() ???
Created attachment 83909 [details] The "right" log file from cold startup Sorry, the log I've attached before was from the "warm" startup. Now the right "cold" one. BTW one can compare them side by side after removing first column with timestamp by: cut -d " " -f 2- amarok.log > amarok1.log
I think Andreas E expressed his opinion a bit extreme, but I can't disagree to be honest. Why is there no clear statement about the speed issue? All we get in all bug reports regarding the startup issue is always the same opinion of the same person that states: speed is fine, just keep your playlists small. This is obviously kind of ignoring/denying bugs. And setting all bug reports regarding those issues to solved/invalid etc. is just like ignoring the reality and very bad behavior imho. I am working on a pretty fast SSD here and the startup time is still to slow, I think it can be optimized a lot. Checking everything at startup without initializing any gui is a real showstopper for some people. Please do not get me wrong, Amarok is a cool music player and the community is great, but if someone involved in development gives statements here it would be nice to not try to deny facts, but say something like "We do not plan to optimize anything at the startup process, but patches are welcome/unwelcome ....". I would be willing to look into this and provide feedback, do proper performance testing monitoring etc, but I think it is useless as long as all bug reports are set to "Needs info" etc. despite info being attached and not letting users changing status of the bug report.
(In reply to comment #10) > I would be willing to look into this and provide feedback, do proper > performance testing monitoring etc, but I think it is useless as long as all > bug reports are set to "Needs info" etc. despite info being attached and not > letting users changing status of the bug report. As already suggested on IRC: please take this and your concrete proposals about how to solve this to the amarok-devel@kde.org mailing list, this should not be discussed in a bug report.