Version: 2.1.1 (using KDE KDE 3.3.1) Installed from: FreeBSD Ports Compiler: gcc (GCC) 3.4.2 [FreeBSD] 20040728 OS: FreeBSD I just started using Juk and as such I've had to go through and clean all the tags in my library. I've noticed that whenever I try to edit tags either manually or with the tag guesser on multiple files it can sometimes take a long time and the application interface locks up until the editting is complete. If I'm playing an mp3 it will continue to play without a problem, but if the track ends then it takes awhile until the next track will be started or until again the editting completes. I've noticed that when I use the tag guesser Juk will also lock up. So the combination of using the tag guesser on multiple files is very painful. I believe the problem is just that the editting is not forked off into a separate thread because the CPU usage when the lockup occurs is only 5% - 10% I believe that the slowdown occurs because my files reside on a mounted Samba share over the LAN, but regardless I still think the tagging should be able to run asynchronously.
I'm experiencing the same slowdown - on local files (tagging flac files is not that fast) - on debian unstable (it's not bsd-specific)
FLAC tagging is slow by nature -- the files are large, the tag is at the beginning of the file and there's no provision for "padding" a la ID3v2 in Xiph-style tags. The big change that will have to happen for something like this is to completely move tagging out to another thread, though since that's pretty invasive it won't likely happen for 3.4.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.