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
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
