PDA

View Full Version : rescan performance issues in 6.x



Paul Forgey
2005-11-06, 10:49
I am now running 6.2, but since 6.0.x my slimp3 player (long time owner :)) is useless during rescans. The music drops out and even produces speaker threatening pops and whumps. I have the "build items per pass" parameter set to 1. This is a P-4 2.3GHz with 512 MB RAM. Not the fastest computer but it should be capable enough for this.

While on the subject of rescans, 99% of the time it rescans is because I've ripped a CD or made some iTunes playlist adjustments. The problem is the rescan triggers almost immediately when I make my _first_ iTunes adjustment, like the first track being ripped. While the feature is a nice idea, it doesn't help to just have to rescan again later to get the rest of the songs that ripped. I would suggest the auto rescan feature has a time that it waits before actually starts scanning after seeing the iTunes database change.

Michaelwagner
2005-11-06, 11:09
I am now running 6.2, but since 6.0.x my slimp3 player (long time owner :)) is useless during rescans. I believe this is an acknowledged problem. The SLiMP3 has the smallest buffer of the lot, and is the least tolerant of small amounts of inattention.

I think it's being worked on.

Bonesteel
2005-11-06, 19:06
Interesting.

This is the same issue that prompted rants from me in two different threads. My initial post asked if there was any issue with using a SLIMP3 with 6.2 (I saw the same symptoms the original poster did on a mac). Many indicated that it was fine and would work. Now it seems there is an acknowledged problem being worked on. Doh!

It is hard to keep track of which release one should use, isn't it?

Michaelwagner
2005-11-06, 19:43
My initial post asked if there was any issue with using a SLIMP3 with 6.2. Many indicated that it was fine and would work. Now it seems there is an acknowledged problem being worked on.Both are true.

The vast majority of people, it seems, have no problem. But some do have a problem. As a result of comments like yours and others, I would guess there is some kind of a problem in some configurations. But I don't think anyone's any closer to figuring out *which* configurations, which would be a good first step to tracking down the problem.

It's like that rattle in your car that doesn't rattle when the mechanic is there ... hard to know what to fix until you can at least identify the problem.

The bit about being acknowledged seems to have been misunderstood, by the way ... if there's going to be a performance problem on a given system, it's acknowledged that the original SLiMP3, having the smallest buffer, will have the hardest time. The SB2 (&3) can go for most of a minute without being fed music and not blink. The SB1 about 5-10 seconds. The SLiMP3 about half that, perhaps less, depends on a variety of things.

Another way of saying this would be everyone acknowledges that, with its vastly larger buffer, the SB2s can skate over and mask small performance problems. The SLiMP3s can't.

Michael

Paul Forgey
2005-11-06, 20:31
My music store is served up by a file server located elsewhere on my network. It's a 100Mbit connection, but otherwise a very fast file server with U320 discs. The SMB latency is probably causing SlimServer to wait needlessly for files to open when reading them. There is a way around this but not in perl so I kind of expect this to be my fault if this is the problem.

But why does it have to do this at all if I gave it an iTunes database and no music folder anyway? Or is it really spending all of it's time just copying the data into SQLLite?

Dan Sully
2005-11-06, 20:36
* Paul Forgey shaped the electrons to say...

>But why does it have to do this at all if I gave it an iTunes database
>and no music folder anyway? Or is it really spending all of it's time
>just copying the data into SQLLite?

Yes - it's pulling out data from iTunes, and then reading the files directly,
as iTunes doesn't put all the required data into their XML file.

-D
--
<ZangTT> berkeley db - it's mostly about the hash()

Michaelwagner
2005-11-06, 20:37
Someone recently commented (in another thread) that in order to solve one problem with caching, they (unintentionally) introduced another. It's a problem for people with slow or remote file systems. It's more of a problem for people with "deep" file systems. This might be related to the problems you're having. I haven't had the time to check any of this out. For all I know, I misunderstood the original poster ... :-)

Bonesteel
2005-11-06, 21:14
Both are true.

The bit about being acknowledged seems to have been misunderstood, by the way ... if there's going to be a performance problem on a given system, it's acknowledged that the original SLiMP3, having the smallest buffer, will have the hardest time. The SB2 (&3) can go for most of a minute without being fed music and not blink. The SB1 about 5-10 seconds. The SLiMP3 about half that, perhaps less, depends on a variety of things.

Michael

I did not know this, and it explains quite a bit. Thank you for clarifying. Any issue with performance (e.g. 6.2 start up and scanning) will be made painfully obvious on my SLiMP3 and it's small buffer. I just wish this information was easier to come by. It would have saved me some typing and p&ssing off a number of people.

JB

radish
2005-11-07, 08:04
I did not know this, and it explains quite a bit. Thank you for clarifying. Any issue with performance (e.g. 6.2 start up and scanning) will be made painfully obvious on my SLiMP3 and it's small buffer. I just wish this information was easier to come by. It would have saved me some typing and p&ssing off a number of people.

JB

http://wiki.slimdevices.com/index.cgi?HardwareComparison

Michaelwagner
2005-11-07, 08:30
In particular, from that page,
Buffer RAM
SLiMP3 1Mb (8 seconds at 128Kbps)
SB1 8Mb (64 seconds at 128Kbps)
SB2 40Mb (320 seconds at 128Kbps)
SB3 Same as Squeezebox2

Note that 128Kbps isn't much. I routinely record my music at 320 Kbps, so that's already 2.5 times less time. My actual experience is that an SB1 will starve after about 10 seconds of inattention (in my case, by pulling the network cable out or by killing the server on purpose).

Bonesteel
2005-11-07, 09:52
Looks like time for an upgrade. Santa?

:)

Michaelwagner
2005-11-07, 19:18
Looks like time for an upgrade. Santa?Well, I guess Santa might come in one of two directions ... either an upgrade to more buffer-full hardware, or perhaps someone will find the problem (or problems) in the slim server code. Because even 5 seconds seems to my eyes like a long time for the server not to service one client.

That said, I've spent a few days looking through the tag reading code, and the cause sure isn't jumping out at me. :-)

There's a lot of code in there to prevent this kind of buffer drying up.

Why it isn't working right some of the time is escaping me.

eschurr
2005-12-16, 14:57
i've had a similiar problem during recans. my solution was to set the iTunes rescan interval to 0 (to disable it) and then use the rescan plug-in to schedule rescans to run at night when you're not using the CPU.

if you add a new song to iTunes and want to play it in SS right away, use the "browse music folder" option.