After max. 1 minute after starting amarok, the UI goes unresponsive. If playing, the playback continues until the end of the current track and then stops, the next track in the playlist doesn't play. I disabled all the plugins and scripts. Reproducible: Always Steps to Reproduce: 1. Open amarok 2. Wait one minute 3. Try to use the UI
Created attachment 98991 [details] GDB output
Created attachment 98992 [details] console output with --debug
Disabled "Watch folder for changes" and it doesn't happen anymore.
Where is your collection located?
Hi Myriam, on an NFS share
That might be the root of the problem, then. If you are using external media for your collection you always need to make sure it is mounted before Amarok starts. Another source of the slowdown can be a too large playlist containing music from external sources: since all the tracks in the loaded playlist are checked for availability, this slows down the whole startup process. The option "watch folders for change" is dependent on a fast access to the collection, but external media like NFS shares are not as fast as local collections are. I fear there is nothing we can do about this.
(In reply to Myriam Schweingruber from comment #6) > That might be the root of the problem, then. If you are using external media > for your collection you always need to make sure it is mounted before Amarok > starts. > Another source of the slowdown can be a too large playlist containing music > from external sources: since all the tracks in the loaded playlist are > checked for availability, this slows down the whole startup process. > The option "watch folders for change" is dependent on a fast access to the > collection, but external media like NFS shares are not as fast as local > collections are. I fear there is nothing we can do about this. Hi Myriam, the NFS share is always mounted at boot over a Gigabit link and it's available when Amarok starts, this problem started to happen after a while though; disabling the inotify is not a problem, I can trigger the update manually when I add files, the collection is pretty big indeed, 638G on NFS and 44G local, all FLAC. I raised a bug as I couldn't find any precise reason for this in the output, once it hangs, waiting for some time doesn't seem to improve. It's not slowing down, it's becoming at all non responsive; usually I kill it after 5-15 mins. The ticket can be closed for me, or set to very low prio if you wish to sort it out, I'm available to test.
I know there has been quite some work on the database since the release of 2.8.0, could you eventually test Amarok 2.9 beta or current git master?
I set up a Kubuntu VM on the "problematic" debian host with a bridged NIC, it uses the same NFS mountpoint for the collection, mounted with the same options; I imported both mp3s and FLAC, now the collection is ~60k tracks worth. I kept inotify on. I don't seem to be able to reproduce the problem with the below versions: 2.8.0 from the kubuntu repository 2.8.0-git (your commit 2900fe47adde10999a6c0f907d73b00a1c1bd5b1 from the master branch) tags/v2.8.90 Is there anything else I can check? I'm going to try the same on a Debian...
(In reply to Marco Z from comment #9) ... > I don't seem to be able to reproduce the problem with the below versions: > > 2.8.0 from the kubuntu repository > 2.8.0-git (your commit 2900fe47adde10999a6c0f907d73b00a1c1bd5b1 from the > master branch) > tags/v2.8.90 > > Is there anything else I can check? I'm going to try the same on a Debian... It's not unlikely that Kubuntu has a patched version compared to what Debian ships, so the versions might be different. Keep in mind that Debian stable very rarely ships the most actual version.
I tried the same 2.8.0-2.1+b1 package on a new Debian VM, unfortunately I'm not able to reproduce the issue there.
I actually had a look at the GDB output again. Despit lacking debugging symbols (which doesn't make it very useful), there appears to be a deadlock in FAM/KDirWatch, which is an upstream problem, so you might hit bug #281312
Closing correctly: this is most likely a duplicate *** This bug has been marked as a duplicate of bug 281312 ***