Linux 32-bit: SoulseekQt-2016-1-17-32bit.tgz
Linux 64-bit: SoulseekQt-2016-1-17-64bit.tgz
See the Changelog for list of features and fixes.
MP3 scanning, which is by far the heaviest part of indexing shared files does take place in a secondary thread, and it should only happen once. Does this happen every time you start the client? Other than MP3 scanning, there's just checking the contents of each shared folder to see if any files were added or removed, and putting the shared file information in the client's data system. The data system may be the culprit here (more on that in my response to your other thread), but I'm not gonna be able to say for sure until I do some testing on my end.
No I mean when i press the "rescan shares" button on the options -> file sharing page.
The client takes a long time to start, but so did the old one, so this isn't a problem. When i press the "rescan shares" button, this seems to lock up the main application completely until its finished rescanning. It's a brill option 'cos before you'd either have to restart the client or unshare the folder, close the sharing window, re-open it and re-add the share for it to trigger the re-indexing. Just would be nice if the new option worked in the background so i could continue to chat or download or whatever at the same time.
I see, I'll take a look at what's going on there as soon as I get the time.
im share 150K files and rescan after music update its one minutes.
in baground it will will create a lot of superfluous loading on the computer. the superfluous.
if u programs lock when rescan, maybe optimization of OS will help you.
Also much role plays the separate winchester there is OS or on one with files that you distribute