Version: 2.2.1 (using KDE 4.3.3) Installed from: Ubuntu Packages Any operation on a mass storage vfat device, like for example "Read tracks", or copying to or from makes amarok'UI freeze, no operations/clicks can be done, until the I/O operation over vfat completes, then amarok returns responsive. It happened with 2.2.0 and it's still happening with 2.2.1
Why didn't you report it for 2.2.0?
I thought that maybe it was something related to my Ubuntu packages, so I preferred to wait to see if a new package solved the problem. Moreover I had chance to use a vfat storage only lately, when 2.2.1 was on its way so I preferred to wait a few weeks before reporting. Another couple of symptoms: when the UI freezes, it freezes even the "external" plasma (i.e. the panel), but no other apps (kmail, kopete etc). No particular CPU spikes in Xorg/amarok/plasma-desktop processes, CPU usage seems normal Playing songs from the device in Amarok directly on the other hand works fine, no UI blocked at all. Only when reading the songs list and copying to/from device within amarok
The UMS mediadevice implementation is know to block the UI on scanning. That is what happens when you click "read tracks". This should really be fixed because UMS MediaDevice is really used a lot for big harddrives. It's not really an issue for those small flash players. Plasma blocking is probably do to either the "Now Playing" plasmoid or the system tray icon if you clicked on it. In both cases this is a design flaw in Plasma. I used to have the same problem when debugging Amarok in gdb until I removed that plasmoid.
Bart, indeed I have a Now Playing plasmoid in one of my panels. I have an 8GB player and it needs ~30 secs to scan all my tracks,and having the UI blocked and with no "Updating collection" warning somewhere it really makes you think that Amarok just hung. Can you confirm that blocking UI even on copying is a know bug/behaviour too? Thanks!
Can't reproduce a blocked UI on copy-to. At least I didn't notice this while copying one album of about 75MB. According to the progress bar this took quite a while to complete yes the files were on disk almost instantly. There might be another problem there. The copy probably uses KIO::file_copy, which doesn't block the mainloop by default. Can you find some way for use to reproduce the blocked UI on copy?
Ok, just tried again now. This is a different kind of "blocked UI". I could see that the status bar is updated, there is a progress bar and a label saying that a file is being transferred but if it's a single song (or few MBs), no problem at all, but if you try to syncronize an album that weights >100MB or lots of albums, the UI is blocked again, with the progress bar not progressing after a few %. But the process is running and eventually ends with all files transferred. I did the same copy over KIO within Dolphin and no problems there. Maybe it detects new files on the vfat device and so update the collection, blocking the UI as said before?
Wait, get the concepts right first: a blocked UI means it doesn't respond to anything at all and there are no redraws. Such as what happens on "Read Device". It's caused by the tread running the Qt mainloop being busy with something else, a function that takes to long to complete. The other is not a blocked mainloop, there is just a lot going on so the response of Amarok might be slow. I didn't notice this, it might be related to the speed of your machine, how CPU intensive the copy to USB is on your hardware, etc. It's not a bug.
Yeah, I'm not saying that's a blocked mainloop in the copy case, but anyway Amarok UI is unresponsive and unusable, causing the same pain to the end user as a true blocking call in the mainloop. If you prefer I can file a separate bug report, no problem, cause I still think it's an amarok bug since the same exact operation in Dolphin gives no unresponsive UI at any rate on the same system.
*** This bug has been marked as a duplicate of bug 212615 ***