PDA

View Full Version : Best Performance - recommendations? -- no,but I can tell you what *isn't* working for me..



Dondi
2005-08-04, 09:23
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 <lists (AT) ukusa (DOT) demon.co.uk> 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
>
>
>
>

radish
2005-08-04, 14:41
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

What I don't understand is why the scan time is seemingly exponential. I can do a full wipe and rescan of about 10,000 tracks in under 15 minutes (more like 10), so why does 7x the tracks take 96x as long to scan?

wr420
2005-08-04, 17:16
Maybe a .cue/.m3u problem?
A lot of the CDs I have ripped have playlist files in the dir with the
music. If I browse folders and play a directory containing a CD that
has a playlist file in it I get 2 of each song. I commented out .cue
and .m3u in types.conf to remedy.(which of course broke playlists
altogether).
BUT I'm pretty sure it dropped a 4-5 hours scan time to under a half
hour.
(40,000 tracks)
YMMV - I wasn't timing it so this may be a big wrong. Just something to
think about.
I will test later and report.
Matt



>
> What I don't understand is why the scan time is seemingly exponential.
> I can do a full wipe and rescan of about 10,000 tracks in under 15
> minutes (more like 10), so why does 7x the tracks take 96x as long to
> scan?
>
>
> --
>
> radish
>

Dondi
2005-08-05, 09:23
--- radish
<radish.1t9esz (AT) no-mx (DOT) forums.slimdevices.com> wrote:

> What I don't understand is why the scan time is
> seemingly exponential.
> I can do a full wipe and rescan of about 10,000
> tracks in under 15
> minutes (more like 10), so why does 7x the tracks
> take 96x as long to
> scan?

Radish... diff OS?? Is Linux the answer to those with
large libraries? Haven't had the time nor the courage
to make the leap to Linux, but if I can get a
wipe-scan time of an hour or two as opposed to almost
2 days, then Im all for it. The dual-processor box I
have is a dedicated SlimServer, so I dont mind at all
trashing the thing to make my SB experience a bit
slicker, but I have yet to figger out how to
accomplish this with a large library (absolutely no
playlists involved in the library, no FLACs; just
MP3s). So, to the original poster, I wouldn't throw a
mondo-amount of hardware at this project. It's only my
opinion and from my experience, there hasn't been any
gain in efficiency, especially if you have a "large"
library. Just grin & bear it. The rescans are fine.

So again, maybe we can narrow this down a bit -- what
are people with large libraries getting for scan times
and what OS are they using?? Maybe its the demonic
windows that bogs the deal down??

-- Dondi

radish
2005-08-05, 09:41
--- radish
<radish.1t9esz (AT) no-mx (DOT) forums.slimdevices.com> wrote:

> What I don't understand is why the scan time is
> seemingly exponential.
> I can do a full wipe and rescan of about 10,000
> tracks in under 15
> minutes (more like 10), so why does 7x the tracks
> take 96x as long to
> scan?

Radish... diff OS?? Is Linux the answer to those with
large libraries? Haven't had the time nor the courage
to make the leap to Linux, but if I can get a
wipe-scan time of an hour or two as opposed to almost
2 days, then Im all for it. The dual-processor box I
have is a dedicated SlimServer, so I dont mind at all
trashing the thing to make my SB experience a bit
slicker, but I have yet to figger out how to
accomplish this with a large library (absolutely no
playlists involved in the library, no FLACs; just
MP3s). So, to the original poster, I wouldn't throw a
mondo-amount of hardware at this project. It's only my
opinion and from my experience, there hasn't been any
gain in efficiency, especially if you have a "large"
library. Just grin & bear it. The rescans are fine.

So again, maybe we can narrow this down a bit -- what
are people with large libraries getting for scan times
and what OS are they using?? Maybe its the demonic
windows that bogs the deal down??

-- Dondi

No, XP SP2 here. I actually did a test yesterday. Started an album playing (FLAC files, transcoding to PCM on the server, wireless link to SB2) and hit the rescan button. Took around 10 minutes, and although the SB2's display was a little jerky when scrolling, the buffer never dropped below 90% full. As I've posted before, this is not a super powerful machine, but it is dedicated. Also, remember that dual proc boxes are entirely redundant when running slimserver.

Could it be file types? I'm mainly vorbis & FLAC, with only a very few mp3s. I know vorbis tags are supposed to be somewhat better designed than ID3, but I don't know if they're more efficient to read. Also do the obvious things like making sure your virusscanner isn't scanning the music files, and that the disks are in decent shape re: DMA settings & fragmentation.

Dan Sully
2005-08-05, 09:57
* radish shaped the electrons to say...

>Could it be file types? I'm mainly vorbis & FLAC, with only a very few
>mp3s. I know vorbis tags are supposed to be somewhat better designed
>than ID3, but I don't know if they're more efficient to read. Also do
>the obvious things like making sure your virusscanner isn't scanning
>the music files, and that the disks are in decent shape re: DMA
>settings & fragmentation.

Vorbis / FLAC tags are much more effecient to read than MP3.

-D
--
"My pockets hurt." - Homer Simpson

Dondi
2005-08-05, 10:34
* radish shaped the electrons to say...

> >Could it be file types? I'm mainly vorbis & FLAC,
> with only a very few
> >mp3s. I know vorbis tags are supposed to be
> somewhat better designed
> >than ID3, but I don't know if they're more
> efficient to read. Also do
> >the obvious things like making sure your
> virusscanner isn't scanning
> >the music files, and that the disks are in decent
> shape re: DMA
> >settings & fragmentation.

I personally don't have an issue with my long scan
times. I have already resigned to the fact that it
takes me about 2 days to scan my library. My RAID is
defragmented on a regular basis by PerfectDisk and I
am aware of my bloated MP3s and the metadata contained
therein i.e., album review for the COMMENT, embedded
JPG album covers, and data for ALBUM ARTIST as my MCE
needs this info to discern compilation albums from
"regular" albums. I understand the process for parsing
the metadata, and as I said, I have already
surrendered the effort for efficiency. I had always
had this battle with my library and SlimServer's scan
times and had posted my "then issues" eons ago as my
library, at the time, was unusually "large". As time
goes on, everyone's "large" library will be considered
"normal".

My $.02,
-- D