When I start amarok, its startup progress takes half a minute. The main window appears but is empty and unresponsive. I always thought Amarok crashed/froze but when I left it, it starts and then works fine. I then started it with the --debug parameter. The file is attached. Note the END__: void RecentlyPlayedListWidget::updateWidget() [DELAY Took (quite long) 25s] amarok: END__: void RecentlyPlayedListWidget::setupTracksData() [DELAY Took (quite long) 25s] in line 630. Reproducible: Always
Created attachment 71396 [details] amarok --debug output
What version is this about? You can set the version field yourself and please always do so when reporting a bug. If there is no version field please include the version in the bug description. FWIW: the upstart time has improved a lot between 2.5 and now, and we are about to release version 2.6 beta1.
I experience the same behavior on Amarok 2.6. Tried to disable some plugins and script, but it tooks about 24 seconds to update RecentlyPlayedListWidget. Thank you for the great work.
Strange, I can't reproduce this here at all, using Amarok 2.6. My startup time until the GUI shows up is 5 seconds at most. Do you have a long playlist that is loaded by default? That can indeed take some time, especially if there are tracks from various sources e.g.streams or tracks on external devices.
I had about 70 tracks from the local collection and 4 radio streams. I removed all local tracks leaving only the streams, but it didn't solve. Thank you for your reply.
Found it. Removing the RecentlyPlayedListWidget, Amarok starts immediately.
Well, how about removing the streams? Those are usually causing the problem, not the CurrentTrack Widget. I don't see how the widget could cause the problem, the mandatory URL check of the streams much more.
Empty playlist, same behavior. As reported by KaiUweBroulik2, running amarok in debug mode seems to confirm that it hangs updating the widget. ... amarok: BEGIN: void RecentlyPlayedListWidget::setupTracksData() amarok: BEGIN: void RecentlyPlayedListWidget::updateWidget() amarok: END__: void RecentlyPlayedListWidget::updateWidget() [DELAY Took (quite long) 25s] amarok: END__: void RecentlyPlayedListWidget::setupTracksData() [DELAY Took (quite long) 25s] .... Thank you Myriam.
Thank you for the feedback.
Is this still valid for Amarok 2.6? I can't reproduce that here.
Closing for lack of feedback. Please feel free to reopen if you can reproduce this with Amarok 2.6 beta 1, to be released in about a week or a later release.. I can't reproduce this here with Amarok v2.6.0-422-gfc07990
I'm facing this issue with Amarok 2.7 on KDE 4.10 from ArchLinux repos. How do I reopen this bug?
(In reply to comment #12) > I'm facing this issue with Amarok 2.7 on KDE 4.10 from ArchLinux repos. > > How do I reopen this bug? Can you provide logs from 'amarok -d --nofork'? Without specifics why the startup is long and proper timing there is little we can do. Also please make sure you have no 3rd-party scripts enabled and that all devices are mounted and reachable before you start Amarok.
Setting status correctly.
After using Amarok a while to listen to some music this issue is gone now. The output was pretty much the same of the already attached one. amarok: BEGIN: void RecentlyPlayedListWidget::setupTracksData() amarok: BEGIN: void RecentlyPlayedListWidget::updateWidget() amarok: END__: void RecentlyPlayedListWidget::updateWidget() [DELAY Took (quite long) 25s] amarok: END__: void RecentlyPlayedListWidget::setupTracksData() [DELAY Took (quite long) 25s] The only thing I noticed when the bug occurred is that recently played list show last played date as January 2013 and had music with non ASCII characters. I'll try to reproduce this issue but it seems gone now.
Hi, So, I was able to reproduce this bug once more. The amarok -debug output remains the same amarok: BEGIN: void RecentlyPlayedListWidget::setupTracksData() amarok: BEGIN: void RecentlyPlayedListWidget::updateWidget() amarok: END__: void RecentlyPlayedListWidget::updateWidget() [DELAY Took (quite long) 25s] amarok: END__: void RecentlyPlayedListWidget::setupTracksData() [DELAY Took (quite long) 25s] Any thing I can make to help solve this issue.
Created attachment 80933 [details] amarok-startup-debug.log
I am seeing the same problem of delayed startup of Amarok 2.7.1 (Arch Linux, KDE 4.10.5). If I remove the Recently Played widget, the issue is resolved. I had experienced this on Amarok 2.6 previously, but only solved it by completely purging Amarok and all of its configuration files, including dropping the MySQL table and user. After reinstalling, reconfiguring the database, and building the library, Amarok was starting up properly for some while. This issue cropped up again seemingly randomly (on 2.7.0) without any change to preferences, no change to the interface layout, and no change to the database/library. Attached debug log. Please let me know if I can provide any further information.
The same issue happens here in openSUSE 12.3 with Amarok 2.7.1 (from the Packman repo). amarok: [ScriptManager] ScriptUpdater: Skipping update check amarok: [ScriptManager] found script: "Scriptable Service" "Cool Streams" "1.0" ("Amarok2.0") amarok: [ScriptManager] found script: "Lyrics" "LyricWiki" ".2" ("Amarok2.0") amarok: [ScriptManager] found script: "Scriptable Service" "Free Music Charts" "1.6.0" ("Amarok2.5") amarok: [ScriptManager] found script: "Scriptable Service" "Librivox.org" "1.0" ("Amarok2.0") amarok: [ScriptManager] found script: "Generic" "Amarok Script Console" "1.0" ("Amarok2.0") amarok: BEGIN: void ScriptManager::configChanged(bool) amarok: END__: void ScriptManager::configChanged(bool) [Took: 0s] amarok: END__: void ScriptManager::updateAllScripts() [Took: 0.002s] amarok: BEGIN: void DBusAbstractAdaptor::_m_emitPropertiesChanged() amarok: END__: void DBusAbstractAdaptor::_m_emitPropertiesChanged() [Took: 0s] X Error: BadWindow (invalid Window parameter) 3 Major opcode: 20 (X_GetProperty) Resource id: 0x5600012 amarok: BEGIN: void RecentlyPlayedListWidget::setupTracksData() amarok: BEGIN: void RecentlyPlayedListWidget::updateWidget() amarok: END__: void RecentlyPlayedListWidget::updateWidget() [DELAY Took (quite long) 50s] amarok: END__: void RecentlyPlayedListWidget::setupTracksData() [DELAY Took (quite long) 50s] amarok: BEGIN: void CollectionTreeItemModelBase::handleSpecialQueryResult(CollectionTreeItem::Type, Collections::QueryMaker*, const DataList&) amarok: [CollectionTreeItemModelBase] Received special data: 2
The RecentlyPlayedListWidget changed a lot lately, can you please test the git version and see if the problem still occurs?
So....... There is any way to run the built amarok without needing to install it under /usr and mess with my current installation?
(In reply to comment #22) > So....... > There is any way to run the built amarok without needing to install it under > /usr and mess with my current installation? You can make a local installation, but you need to remove the existing package anyway. This does NOT affect your database if you do not remove the data files in $HOME/.kde/sahre/apps/amarok/ http://blogs.fsfe.org/myriam/2009/09/26/compiling-amarok-from-git-locally-full-summary/
Well I ran the built installation but the recently played list shows nothing, so amarok starts really fast. I noticed that there is no reference to recently played widget in the --debug log. In short, this test proves nothing :(
(In reply to comment #24) > Well > I ran the built installation but the recently played list shows nothing, so > amarok starts really fast. Just skip through 10 songs, the widget should populate.
Thats the problem. I can only reproduce the problem when I play some songs and let amarok rest (without playing music) for about a month :(. I know that not opening amarok for over a month seems too much, but things happens. So I'll not be able to get this bug again probably until amarok 2.8 is out (I guess).
Since nobody here can reproduce it and is probably willing to not use Amarok for a month I suggest you reopen this report if you can really reproduce it later.
@Myriam: See comments #18 and #19. I was able to reproduce this 100%. Simply removing the widget was the workaround for me. Unfortunately, I've since purged KDE after 3+ years of a rolling Arch installation due to the cumulative effect of an ever-growing number of unresolved bugs such as this.
(In reply to comment #28) > @Myriam: See comments #18 and #19. I was able to reproduce this 100%. Simply > removing the widget was the workaround for me. Oh, that's very nice. We could use your help trying to reproduce this now, because as I outlined in comment #21, the widget has undergone major changes, and the issue has probably been resolved as a by-product. if no one is able to reproduce this with a build *containing* this change, then I fail to see what's left to do than to close the issue?