Version: 2.4.0 (using KDE 4.5.4) OS: Linux Cold start (i.e. the first after clearing /tmp and /var/tmp on system boo) takes about 40 seconds on my PC (processor load is about 30% on 8-cores system). Every next start is quite OK, about 5 seconds, but the first one is terribly slow if I just want to play some music. Reproducible: Always
Where is your collection located?
on HDD and a couple of items are internet streams. Also the playlist is quite long. I've got debug log of startup, the big part of startup time is taken by thousands of such messages: amarok: [BEGIN:] Playlists::PlaylistFilePtr Playlists::loadPlaylistFile(const KUrl&) amarok: [END__:] Playlists::PlaylistFilePtr Playlists::loadPlaylistFile(const KUrl&) [Took: 0.022s] Obviously, this routine runs for every item in the playlist and takes somewhere from 0.005s to 0.5s.
Of course every stream URL needs to be checked. What is the length of the playlist? FWIW: large playlists should be avoided, as Amarok is not designed to work like this. Also you can use the APG and the Dynamic Playlists, no need for large playlists anyway.
The playlist has 931 items, about 10 of them are streams. But I should say that according to log those function takes for streams no more than for every other item. Thanks for suggestions, I'll try. I don't say that it's right use case, but I think it's quite popular. Anyway, paying up to 50 ms of startup time to every single playlist item is flaw, I think.
I often have playlists of around 50 items and never have such a long delay, but I usually don't mix streams and local files. You should maybe try to cleanup your amarok* configuration files in $HOME/.kde/share/config/. FWIW, although my system is on an SSD, the collection is on an external USB HD, the longest startup time I have seen post 2.4 release is 3 seconds with a mounted external HD. Dual core 64bit system with 4 Gb of RAM.
Yeah, all the next startups after the first one don't really last more than 5-6 seconds but the first one seems to depend on playlist size. Removed amarok* files from config directory, will try with fresh configuration.
Sorry, this bug slipped from our attention. Streams in playlists need to get the URL checked, so this can of course slow down the startup. Has this changed in 2.4.1
No problem, thank you for respond. Will try 2.4.1 and post the result.
Any news on this?
Sorry for delaying with answer. I tried 2.4.1 a couple of weeks ago. Nothing was dramatically changed in terms of cold start speed but it seems that it's not about URL checks anymore. I tried to delete URL streams from playlist and speed didn't changed. I think, the problem is just with *really* long playlist like one I wrote before. If Amarok is not designed for such a case it's obviously not a bug, but if I have some time I'll try to evaluate the real problem, maybe it could be fixed without changing design considerably.
Thank you for the feedback, You are of course welcome to give a hand in improving this indeed :) I will keep this open for that purpose.
Thanks, Myriam. It makes me even more encouraged to participate.
I have noticed that it takes Amarok ages to display the main window the first time the system tray is clicked - 10 seconds - but closing the window and bringing it back up is almost instant.
If you don't need the context browser you can disable it. That should speed up startup considerably and save you a sizeable chunk of memory too.
Hi, I have similar problems, regardless of playlists' length. Probably because I don't use KDE besides library for amarok. Amarok is taking so long at the first startup because half of KDE is starting with it? Am I right? And can I do something about it
Well, I don't thing it's because you don't use the whole KDE. How much is 'so long' for Amarok to start? It spends some time even with empty playlist but this bug report is not about it.
It takes about 15 seconds the first time I start it (with empty playlist and without content view). My computer is 4-5 years old and has 2 GB ram.
We are about to release Amarok 2.4.3 (2.4.2 was skipped because of a bad regression), could you please check it out and see if something changed?
I'll try to do it this week both with my big playlist and an empty one but first I need to upgrade to 4.7 before it.
Hi, I have now tried version 2.4.3 with kde 2.6.2 on gentoo. I timed amarok fresh after reboot with only X and window manager running, it took 21 seconds according to "time amarok". Every next startup is significantly faster, they only take 2-3 seconds. The debug output of the cold start says: .. amarok: [00;35mEND__:[00;39m void EngineController::initializePhonon() [07;33m[DELAY Took (quite long) 6.6s][00;39m .. amarok: [00;36mEND__:[00;39m MainWindow::MainWindow() [07;33m[DELAY Took (quite long) 6.4s][00;39m .. amarok: [00;32mEND__:[00;39m void App::continueInit() [07;33m[DELAY Took (quite long) 13s][00;39m amarok: [00;31mEND__:[00;39m App::App() [07;33m[DELAY Took (quite long) 13s][00;39m so that's 6 seconds for the main window and 7 seconds for phonon initialization. I added my own timestamp to the log and found: tstamp: 1:: tstamp: 2:: tstamp: 3:: tstamp: 4:: tstamp: 5:: tstamp: 6:: KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work amarok: [00;31mBEGIN:[00;39m App::App() amarok: [00;32mBEGIN:[00;39m void App::continueInit() amarok: [00;34mBEGIN:[00;39m EngineController::EngineController() amarok: [00;34mEND__:[00;39m EngineController::EngineController() [00;34m[Took: 0s][00;39m amarok: [00;35mBEGIN:[00;39m void EngineController::initializePhonon() tstamp: 7:: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) kbuildsycoca4 running... tstamp: 8:: tstamp: 9:: tstamp: 10:: tstamp: 11:: tstamp: 12:: tstamp: 13:: added device default id 0 added device aout_file id 1 added device alsa id 2 added device aout_sdl id 3 added device dummy id 4 amarok: [EngineController] Tick Interval (actual): 100 amarok: [00;35mEND__:[00;39m void EngineController::initializePhonon() [07;33m[DELAY Took (quite long) 6.6s][00;39m amarok: [00;36mBEGIN:[00;39m MainWindow::MainWindow() ... You can see that Amarok first starts outputting debug information after another 6 seconds. hope that helps
Johannes, could you maybe upgrade your KDE as well? There is KDE 4.6.5 and 4.7 available.
Just a thought: do you have Media devices or external HDs connected that are not in the main collection? Try disabling/unplugging those and see if that helps.
I'v finally finished update to KDE SC 4.7 and Amarok 2.4.3. I've also performed some tests base on Johannes's scenario and with my (quite big) playlist and here's the results: Full Playlist (my big playlist mentioned above): 'time amarok' (real): about 0m7.88s - the 1st time real 0m1.622s - the 2+ times approx. time to main window paint completed (wall clock): 27.8 s - the 1st time 5 s - the 2+ times Empty Playlist (with just one item automatically added by Amarok to any empty playlist): 'time amarok' (real): real 0m5.346s - the 1st time real 0m1.598s - the 2+ times approx. time to main window paint completed (wall clock): 12 s - the 1st time 4 s - the 2+ times So I consider it as a big step forward in terms of cold startup time as it was about 1 minute and more for full playlist before. Thanks a lot to developers!
Changing component to playlist as there is a huge difference in startup-time depending on the playlist size.
reply to comment 3 "FWIW: large playlists should be avoided, as Amarok is not designed to work like this. Also you can use the APG and the Dynamic Playlists, no need for large playlists anyway." I'll tell you what: I can't accept this sort of argumentation "is not designed to work like this". Plus, please don't try to suggest things on the users that "are not needed for them." Users are individuals who like to do things the way they always did, and not change from model of thinking #A to #B if there is no need. If the Amarok documentation was any good, I would use the APG you spoke of plus the Dynamic Playlists, but to tell the truth, the documentation is abysmal and I could not get any word how to do it. Hence, I had to revert to the old-school way, and yes, this *IS* the way with a big searchable playlist. Well, for foobar2000 (Windows-only, unfortunately, otherwise I would not touch Amarok with security gloves on mind you!) this has never been a problem. My playlist once was a 10,000 track all-in-one playlist and instantly everything was there on app start. No need to wait 2 hours for a 10,000+ track playlist, and, nor any need to WAIT AGAIN for the very same playlist if amarok was fully closed and reopened during that time. The *actual* problem is the misconception of Amarok: the idiotic idea to RESCAN EVERYTHING at app start *every freaking time* instead of doing something sensible like an incremental update. But I've even hacked amarok and added more debug info and I can now prove that amarok indeed scans everything *physically* on hard disk at every start. Whenever I ask the developer *kindly* to make it optional to rescan everything and instead just use the playlist *as-is*, all I get is the same thing about the software "not being designed for...". Just leave it to the user what they prefer, thank you very much. Sorry for the long post, I really had to get this off my chest.
This bug still in Amarok 2.7. Never will be fixed? I have 20,000 tracks in a playlist, and its to hard start amarok... Sometimes crash, sometimes close, its very hard start amarok with a playlist more than 3,000+ songs. Why always amarok scan the Hard Drive for the stupid list?
I'm experiencing similar issue, since ever (for last 2 years following all KUbuntu releases). Today I'm with amarok 2.8.0, and I still get ~3 to 5 minutes delay on first amarok startup after login. I guess it's because of the large music collection (~7000 tracks). All of them are mp3's and all of them are on local hard disk (link from home). I'm not changing neither the playlist nor the music collection, so even if this could be the "DB rescan", I can't figure our WHAT does it 3 minutes on unchanged files? Can I somehow debug what amarok is doing on startup?
Folks, the size of your collection is not an issue, what takes long is when you have huge playlists with remote tracks or even streams, as these will invariably be checked on startup. That is only logical as it needs to check the existence of the track as it is in the playlist. If you don't like it: sorry, it is not going to change, this is by design. FWIW: don't make huge playlists, Amarok is not meant to be used that way, use the APG or Dynamic Playlists instead. FWIW: I experience no delay whatsoever when using a small playlist (30 tracks)
1) I have no one remote track or stream in my collection. 2) Playlist with 350 tracks is by no means "huge". 3) Limiting playlists to 30 items is definitely not a solution. 4) How you can close the issue without even confirming those facts? 5) APG or dynamc playlists are not the solution, as they can't filter out things based on my personal taste, which is per definition not deterministic. 6) Designs are not made in stone. Designs which are not working for even basic use cases are awful examples of software engineering. Need a solution draft? Here is it: No one needs a full rescan of 7000 tracks on startup, if the playlist contains 300. No one needs rescan 300 tracks on startup, if the current playlist position is the only track needed to be checked. So sorry, amarok current design is a crap and has to be fixed. 7) I'm forced to create new bug, because I do not see neither a viable workaround not proposed fix.
Created bug 328274 for the design issue.
@Myriam Schweingruber: what about making the check at start up optional, or maybe only checking the first track of the first playlist and all others while the application is initialized (and therefore usable)? NOTE: I do not demand from anybody to implement this, it is just I thought I would like to hear an opinion on ... Would patches trying to implement something like this be welcome, or do you say: "No, we decided so and that's it"?