Michaelwagner Wrote: > 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: > > 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.
actually.... yes it does! I run SlimServer on multiple machines. All the machines are a minimum of 2.8GHz up to 3.06GHz. All my machines have 1GB of RAM and large hard drives with more than enough space remaining on each drive. Everyone of my machines not only pegs the CPU when scanning. But also comes close just during normal operation, even when Slim.exe is idle. All of my machines are running the latest version of Windows XP Pro with all the latest patches. All machines are running SlimServer 6.3.0 - 8148 -- fingers ------------------------------------------------------------------------ fingers's Profile: http://forums.slimdevices.com/member.php?userid=5570 View this thread: http://forums.slimdevices.com/showthread.php?t=26350 _______________________________________________ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
