Version: (using KDE 4.1.3) Compiler: cmake version 2.6-patch 2, GCC 4.3.2 OS: Linux Installed from: Unspecified Linux I plug my iPod into my computer, then run "pmount /dev/sdb1". The Amarok GUI and tray icon will freeze for ~5 seconds (music continues playing). The GUI will then unfreeze and function like normal.
Mounting the ipod should be threaded.
Perhams if Amarok were to mount the iPod itself, it would be. However, do to some (unfortunate and unknown) flaw in my Arch Linux configuration, I have to manually mount my iPod. Could it be that Amarok is not prepared for manual mounts, and consequently doesn't start the a seperate collection scan thread (or some such task)?
What I meant to say is that reading the itunes db should be threaded.
The same freeze happens when plugging my MTP device.
Yeah, iPod parsing should be threaded. Can't do anything about the mounting issue with Arch Linux though. p.s., MTP connecting is threaded. It shouldn't be freezing up the GUI when connecting, it doesn't do it for me.
> p.s., MTP connecting is threaded. It shouldn't be freezing up the GUI when > connecting, it doesn't do it for me. It does for a little while with my ZVM which has 4500 tracks. amarok: BEGIN: void MediaDeviceCollection::slotAttemptConnectionDone(bool) amarok: [MediaDeviceCollection] starting full scan amarok: BEGIN: virtual void MediaDeviceCollection::startFullScan() amarok: BEGIN: void Meta::MediaDeviceHandler::parseTracks() amarok: RC does not exist amarok: Has read capability interface amarok: Created rc FREEZE amarok: adding provider amarok: BEGIN: MediaDeviceUserPlaylistProvider::MediaDeviceUserPlaylistProvider() amarok: END__: MediaDeviceUserPlaylistProvider::MediaDeviceUserPlaylistProvider() - Took 5.1e-05s amarok: BEGIN: void PlaylistManager::addProvider(PlaylistProvider*, int) amarok: END__: void PlaylistManager::addProvider(PlaylistProvider*, int) - Took 0.00015s amarok: BEGIN: void PlaylistManager::slotUpdated() amarok: BEGIN: void PlaylistBrowserNS::UserModel::slotUpdate() amarok: BEGIN: void PlaylistBrowserNS::UserModel::loadPlaylists() amarok: BEGIN: Meta::PlaylistList PlaylistManager::playlistsOfCategory(int) amarok: BEGIN: virtual Meta::PlaylistList MediaDeviceUserPlaylistProvider::playlists() amarok: END__: virtual Meta::PlaylistList MediaDeviceUserPlaylistProvider::playlists() - Took 5e-05s amarok: BEGIN: virtual Meta::PlaylistList PlaylistFileProvider::playlists() amarok: END__: virtual Meta::PlaylistList PlaylistFileProvider::playlists() - Took 5.1e-05s amarok: BEGIN: Meta::SqlPlaylistList Meta::SqlPlaylistGroup::childSqlPlaylists() const amarok: END__: Meta::SqlPlaylistList Meta::SqlPlaylistGroup::childSqlPlaylists() const - Took 5e-05s amarok: BEGIN: Meta::SqlPlaylistGroupList Meta::SqlPlaylistGroup::childSqlGroups() const amarok: END__: Meta::SqlPlaylistGroupList Meta::SqlPlaylistGroup::childSqlGroups() const - Took 5e-05s amarok: END__: Meta::PlaylistList PlaylistManager::playlistsOfCategory(int) - Took 0.00043s amarok: END__: void PlaylistBrowserNS::UserModel::loadPlaylists() - Took 0.00054s amarok: BEGIN: void PlaylistsInGroupsProxy::buildTree() amarok: "building tree with 21 leafs." amarok: "index 0 belongs to groupName " amarok: "index 1 belongs to groupName " amarok: "index 2 belongs to groupName " amarok: "index 3 belongs to groupName " amarok: "index 4 belongs to groupName " amarok: "index 5 belongs to groupName " amarok: "index 6 belongs to groupName " amarok: "index 7 belongs to groupName " amarok: "index 8 belongs to groupName " amarok: "index 9 belongs to groupName " amarok: "index 10 belongs to groupName " amarok: "index 11 belongs to groupName " amarok: "index 12 belongs to groupName " amarok: "index 13 belongs to groupName " amarok: "index 14 belongs to groupName " amarok: "index 15 belongs to groupName " amarok: "index 16 belongs to groupName " amarok: "index 17 belongs to groupName " amarok: "index 18 belongs to groupName " amarok: "index 19 belongs to groupName " amarok: "index 20 belongs to groupName " amarok: m_groupHash: amarok: (20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0) amarok: END__: void PlaylistsInGroupsProxy::buildTree() - Took 0.00092s amarok: END__: void PlaylistBrowserNS::UserModel::slotUpdate() - Took 0.0016s amarok: BEGIN: Meta::PlaylistList PlaylistManager::playlistsOfCategory(int) amarok: END__: Meta::PlaylistList PlaylistManager::playlistsOfCategory(int) - Took 5.3e-05s amarok: END__: void PlaylistManager::slotUpdated() - Took 0.0018s amarok: Setting memcoll stuff amarok: END__: void Meta::MediaDeviceHandler::parseTracks() - Took 11s amarok: END__: virtual void MediaDeviceCollection::startFullScan() - Took 11s amarok: END__: void MediaDeviceCollection::slotAttemptConnectionDone(bool) - Took 11s amarok: END__: void Meta::MtpHandler::slotDeviceMatchSucceeded(ThreadWeaver::Job*) - Took 11s amarok: BEGIN: virtual void CollectionTreeItemModel::collectionAdded(Amarok::Collection*) amarok: [WARNING!] failed: an unexpected comparison was made amarok: BEGIN: virtual float Meta::MtpHandler::usedCapacity() const amarok: BEGIN: virtual float Meta::MtpHandler::totalCapacity() const amarok: END__: virtual float Meta::MtpHandler::totalCapacity() const - Took 0.0001s amarok: END__: virtual float Meta::MtpHandler::usedCapacity() const - Took 0.0014s amarok: BEGIN: virtual float Meta::MtpHandler::totalCapacity() const amarok: END__: virtual float Meta::MtpHandler::totalCapacity() const - Took 9.1e-05s amarok: END__: virtual void CollectionTreeItemModel::collectionAdded(Amarok::Collection*) - Took 0.005s Maybe it's because it needs to parse many tracks. amarok: END__: void Meta::MediaDeviceHandler::parseTracks() - Took 11s amarok: END__: virtual void MediaDeviceCollection::startFullScan() - Took 11s
Threading of connection requires a decent amount of reworking, targetting for 2.3.
Changing version.
This one is really nasty. Just got this, with a MTP device (4 gigs flash): amarok: END__: int Meta::MtpHandler::getTrackToFile(uint32_t, const QString&) - DELAY Took (quite long) 26s
*** Bug 212615 has been marked as a duplicate of this bug. ***
*** Bug 217380 has been marked as a duplicate of this bug. ***
*** Bug 210844 has been marked as a duplicate of this bug. ***
Adding keyword
Making this a release_blocker is somewhat dangerous, as it could delay the release for a good while. It's currently unclear if the problem can be fixed quickly (or rather: worked around), or if we need a complete redesign of the subsystem (which would take months). I have some ideas I want to try for a workaround, but I can't promise anything.
We won't be able to fix this before 2.2.2 final (it's far too complex), so I'm removing the release_blocker keyword.
Thanks to xevix this is fixed in commit 602801f67eeb506d17b2294f8ae22ff233c1e134. Fix will be in Amarok 2.2.2.
commit 14a1b0f93203f137e45ba56f88d2e1045dcf36f0 Author: Alejandro Wainzinger <aikawarazuni@gmail.com> Date: Tue Dec 29 03:45:14 2009 -0800 Fixed GUI freezing after mounting and during parse of media devices. BUG:180520 diff --git a/ChangeLog b/ChangeLog index 2e8a56e..4919160 100644 --- a/ChangeLog +++ b/ChangeLog @@ -19,6 +19,8 @@ VERSION 2.2.2 fallback. Patch by Andreas Hartmetz <ahartmetz@gmail.com>. BUGFIXES: + * Fixed GUI freezing after mounting and during parse of media devices + (BR 180520) * Fixed missing icons in the drag overlay menu. * More reliable MimeType detection for music formats. Patch by RafaÅ Rzepecki <divided.mind@gmail.com>. (BR 219792)