Sigh ... Almost everything you told us, in flamebait and now more calmly, is already known.
You could have found this out yourself with a little light reading. Slimserver is written in perl. Whether you are a perl fan or not, that's the language it's written in. Warts and all. perl did not acquire threads until recently, and not all implementations for all machines work equally well, so the developers have stayed away from multi-threading until very recently. The entire slimserver has it's own internal dispatcher so that it can service music requests and display requests and handle remote control button presses while scanning and dishing out web pages at the web interface. [edit] the two threads you see in windows - one is a perl windows implementation thread that does almost nothing - I think it waits for sigint or something. It is not a perl second thread. Slimserver is at the moment single threaded. In 6.5 they're getting their toe in the water with a second thread. We'll see how that goes. It is true that (some) file systems have a way of notifying you about file updates, but the notification method is not uniform across file systems. Moreover, Slimserver has to work (and does, to a remarkable extent, it does succeed) across multiple systems and across networks. So the file store may be on a linux box, but slimserver may be running on windows. Or vice versa. The problem is complex in it's generality and not, as I understand it, handled at all well by perl. So the application would have to get down and dirty in system details, not a pleasant task. There is code in slimserver, going back to the early days of release 6, to catch and detect most common scanning loops. These loops are more subtle than you might think, because some music file formats spread themselves across multiple files. For instance, one file format records the entire album as a monolith and then generates a second file called a cue sheet. The idea is to prevent gaps between tracks if you don't want them. But the 2 file format wasn't as well thought out as it might have been (by the designers of the format, not Slim) and it is possible to have various out-of-sync problems. But, basically, what you described as happening shouldn't. Which is why we asked to see your logs, to try to get to the bottom of what's happened, to improve the product so it won't happen again. You wrote: > any program running on a desktop computer (in the background) that > consumes 99% cpu (slimserver does this when working properly too) No it doesn't. If it's consuming 99% of the cpu, for long enough for you to casually notice, it's not running properly at all. I run slimserver 24/7 and have done so for about a year now. It runs on my main computer that also runs AutoCAD Mechanical Desktop (when you look up pig in the dictionary, that's what you find). Slim may use the CPU for 10 seconds at a time, in response to a query, but that's it. And when scanning, once in a blue moon, it is rather more busy for 15 minutes to half an hour or so, but even then you have plenty of computer left over, at least I do on my 1.8GHz machine. So *if* that's not your experience, and *if* you actually want to get to the bottom of it rather than complaining and *shouting-but-not-for-help in a very loud voice*, turn on the debugging options and show us what your log shows. Or not. Your choice. -- Michaelwagner ------------------------------------------------------------------------ Michaelwagner's Profile: http://forums.slimdevices.com/member.php?userid=428 View this thread: http://forums.slimdevices.com/showthread.php?t=26350 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
