Just to chime-in.... I have a dual 500MHz Dell Precision workstaion with 2Gb RAM and a 640Gb MicroNet RAID-5 connected via firewire 800 that stores my >70,000 tunes on WinXP SP2. I have been a SlimDevices customer since around v3 of the slim server software.
An initial scan of the library takes over a day. Always has. You just need to sacrifice a day and half for the initial scan with large libraries IMO. I turned-off scheduled rescans, as I have never been able to get SS to pick-up new music on the rescans. I have added music to my library in the past, but SS never seems to "see" it. For me, the scheduled rescan is only good after correcting tags. That's about it. If I add music, I need to forfeit 2 days of a hard rescan of the library. -- Dondi --- Kevin Hawkins <[EMAIL PROTECTED]> wrote: > Stewart Loving-Gibbard wrote: > > > >>>The larger the music library gets, the worse > the performance. It's > > >>>getting to a stage where it really isn't good > enough to run - when for > > >>>example two people run searches on the music > library, all three > > players > > >>>will stall. > > > > Ah, a topic near to my heart. > > > > > > In the meantime, I'm going to throw an absurd > amount of hardware at > > this problem. I'm putting together a dual Xeon > 3ghz server, likely > > with a Areca SATA RAID 5. (The performance of the > 3ware RAID cards has > > always been underwhelming, Perl proc hogs aside. > The Areca/Tekrams I > > have running elsewhere seem far, far better.) > > > > I'd be curious if anyone out there with a "large" > library (I'll let > > you define what that means) is getting good or > even snappy performance > > with their setup? Care to brag? > > > Hi Stewart, > > A topic near to my heart too. I would caution > against throwing > "absurd amounts of hardware" at this as a solution. > SlimServer runs for > me on XP on a 3.4GHz 4GB memory machine, almost > dedicated and the > results , although slightly better than before, are > still flawed. Memory > - which was a big issue on v5 is now not an issue > under v6. Here's my > experience... > > I have a very large library - circa 100K tracks, and > I have 8 players > although only ever about 2 or 3 are playing. The V6 > Slimserver has > helped solve a lot of my problems (stalls) but it > hasn't fixed what I > believe is an architecture issue in SlimServer to do > with threading. It > is not the number of players that is the issue btw. > On searching my > library I can interrupt all playback and displays > for over 15 minutes !! > This is to do with the search results being large, > if you search for > narrower terms then control returns quicker, say 2-3 > minutes but once > you exceed 10 secs or so then music stalls so it's > still an issue. . If > I rescan my libray it takes over 24 hours :-( and > all player > interaction is lost for that time. This has got much > worse btw in recent > (beta) builds. There has been a bug filed over a > year since v5.1.6 - it > was hoped to fix this in v6 with the new DB > architecture and then when > it didn't pan out it was intended for 6.1 but now > yet again it has been > pushed to a 6.2 target. > > I can't help feeling that this is a big issue > in how SlimServer is > architected and may not be so easy to remedy. No > consumer product > should really lock out users for long lengths of > time however my library > size is hardly typical consumer either so that is > unfair. If people with > much more typical libraries are seeing this then > it's an issue though. > I feel the display, IR remote and playback should > be threaded > separately from the other processes such that they > can continue to > function without interruption. mp3 playback (no > transcoding) is a very > light cpu task and the DB searches now seem > lightning fast in their > responses - it's the subsequent data handling and > the library scan task > that seems to kill anything - which to me ( as a > novice programmer) > seems something that shouldn't be happening, but may > be a bi-product of > Perl or something.. In a way I wish a big > development pause/splurge > could be had on the fundamental performance issues > of SlimServer rather > than fancy new features, but that's not so > interesting to people I > guess. The open source side does tend to become a > bit of a > rollercoaster sometimes - but that's why I love > SlimServer too - all the > new things that it can do . My purchase has grown in > functionality for free. > > I am hanging on in there for this fix as > SlimServer is potentially > such a great product for me (if it worked) , the > current situation is > very fragile though. The fact that player actions > effect other players > (stalling / interrupting music) is my main problem. > I control via AMX > and Crestron and these modules get really messed > around by stalls in the > CLI interface too. But, I'll wait to 6.2 and pin my > hopes on that once > more. No other solution is as accessible and > flexible for me as > SlimServer and fits so well into my HA setup so > fingers crossed. Indeed > I'm struggling at the moment to find an alternative > or I might have > jumped already. > > > Kevin > > > > _______________________________________________ > Discuss mailing list > Discuss@lists.slimdevices.com > http://lists.slimdevices.com/lists/listinfo/discuss > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
