Keeping library database
Submitted by validator on Mon, 04/23/2012 - 08:32
Forums:
If the shared file collection is large, SoulSeekQT just liek SOulseekNS takes forever to start. It's worse than NS though in that the screen is just locked, at least NS becomes functional and keeps scanning in the background. In either case it's a fairly strange and unsual approach to my mind that doesn't scale.
I'd like to recommend that you keep a simple database reflecting the result of the scan, a media library like many media players offer. On startup, just load this. Then farm out a rescan on demand only, and ideally on a worker thread so the UI doesn't lock.
That would rock!
- Log in to post comments
The only part of the scanning
The only part of the scanning process that takes place in the main thread is reading the directory information of any folders that are being shared. MP3 scanning takes place in a secondary thread. Also, the client does save MP3 attribute information between sessions, so what's freezing the client in your case must be the re-reading of the contents of your shared folders. I know that the Qt mechanism for reading directory information can have serious performance issues on Windows, especially when it comes to reading the contents of network drives. I've been experimenting with replacing QDir calls with native FindFirstFile/FindNextFile Windows calls. It doesn't solve the network drive situation (on Vista and Windows 7 these APIs appear not to have access to them at all), but it might be a lot faster in situations where you're sharing a lot of files. If you want to try it out I can set you up with a test build.