background scanning

[Sean Adams]

I'm pretty sure that perl under windows has a fork() mechanism that
really calls the underlying threads, as windows doesn't have true
fork().

That's what it looks like - fork() emulation is probably a good way to go
as opposed to threads, since threaded perl is not (AFAIK) installed by
default on any distros, and it's not even supported on some unices.
However, if it works on windows and we can do a true fork() on Unix, then
we're getting the best of both worlds!

I'd like to give the scheduler a chance though - staying single threaded
is nice, but we shouldn't go out of our way to avoid fork() if it's
the better solution.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited PC-PC calling at Crystal Voice! - Only $1/Mo.
Download your free 30 day trial. Click here.
http://us.click.yahoo.com/Gb1xVB/GxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[vajonez]

Ok, can you file a feature request for an option to turn off
the animation?

Done. Thanks Dean.

-- Tom


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Need new boots for winter? Looking for a perfect gift for your shoe loving friends?
Zappos.com is the perfect fit for all your shoe needs!
http://us.click.yahoo.com/ltdUpD/QrSDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Daniel Sully]

Once upon a time Sean Adams shaped the electrons to say...

osx is no problem - it's true Unix.
Here's some info on fork() emulation under Windows - maybe we should give
it a try...
http://www.xav.com/perl/lib/Pod/perlfork.html

I'm pretty sure that perl under windows has a fork() mechanism that
really calls the underlying threads, as windows doesn't have true
fork().

-D
--
When Hell freezes over, I'll snowboard there too.

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited calling with 3-way conferencing. Only $1/Mo.
with CrystalVoice! FREE trial. Click Here.
http://us.click.yahoo.com/Hb1xVB/HxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Sean Adams]

osx is no problem - it's true Unix.

Here's some info on fork() emulation under Windows - maybe we should give
it a try...

http://www.xav.com/perl/lib/Pod/perlfork.html

threads aren't portable in perl. fork() is moreso. it should work on
windows, i'm not sure about macos < X

I'm fairly certain that it was decided that "Classic" MacOS would no
longer be supported, so this shouldn't be a problem.
-- Tom
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Call any Phone in the World from your PC with CrystalVoice
-LOW rates world-wide - $0.039/min in U.S.
FREE trial. Click here.
http://us.click.yahoo.com/Ib1xVB/IxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[vajonez]

threads aren't portable in perl. fork() is moreso. it should work on
windows, i'm not sure about macos < X

I'm fairly certain that it was decided that "Classic" MacOS would no
longer be supported, so this shouldn't be a problem.

-- Tom


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited calling with 3-way conferencing. Only $1/Mo.
with CrystalVoice! FREE trial. Click Here.
http://us.click.yahoo.com/Hb1xVB/HxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[vajonez]

jeez that's a lot of mp3s. This may be a silly question, but why
not run the SliMP3 server from that machine?

I use my SliMP3 at work. The machine that hosts those files isn't mine
(although I do have an account on it), it's our VP of engineering's
linux workstation. I mostly listen to files stored locally on my
server, but ocassionally will look through and play his stuff.

I'll check out a copy of the server on that machine and see how the
performance is for a large local collection.

-- Tom


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Tiny Wireless Camera under $80!
Order Now! FREE VCR Commander!
Click Here - Only 1 Day Left!
http://us.click.yahoo.com/75YKVC/7.PDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Daniel Sully]

Once upon a time dean blackketter shaped the electrons to say...

My usage patterns are likely to be atypical. Probably few people will
have access to a 240GB mp3 collection.

jeez that's a lot of mp3s. This may be a silly question, but why not run
the SliMP3 server from that machine?
Still, we should be sure it works with NFS.

The NFS problem may not be solvable without threading or multiple
processes in perl. If the server blocks for a fractional second
while a directory is opened over NFS, there's precious little we can
do about making the animation smoother.

threads aren't portable in perl. fork() is moreso. it should work on
windows, i'm not sure about macos < X

-D
--
This knob controls the thing that changes when you turn it. - noah

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited PC-PC calling at Crystal Voice! - Only $1/Mo.
Download your free 30 day trial. Click here.
http://us.click.yahoo.com/Gb1xVB/GxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[dean blackketter]

My usage patterns are likely to be atypical. Probably few people will
have access to a 240GB mp3 collection.

jeez that's a lot of mp3s. This may be a silly question, but why not run
the SliMP3 server from that machine?
Still, we should be sure it works with NFS.

The NFS problem may not be solvable without threading or multiple
processes in perl. If the server blocks for a fractional second
while a directory is opened over NFS, there's precious little we can
do about making the animation smoother.

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited calling with 3-way conferencing. Only $1/Mo.
with CrystalVoice! FREE trial. Click Here.
http://us.click.yahoo.com/Hb1xVB/HxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Sean Adams]

My usage patterns are likely to be atypical. Probably few people will
have access to a 240GB mp3 collection.

jeez that's a lot of mp3s. This may be a silly question, but why not run
the SliMP3 server from that machine?

Still, we should be sure it works with NFS.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
FREE COLLEGE MONEY
CLICK HERE to search
600,000 scholarships!
http://us.click.yahoo.com/Pv4pGD/4m7CAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[dean blackketter]

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [slimp3-dev] Re: background
scanning</title></head><body> <blockquote type="cite" cite>&gt; My usage patterns are likely to be
atypical.&nbsp; Probably few people will<br>
&gt; have access to a 240GB mp3 collection.<br>
<br>
jeez that's a lot of mp3s. This may be a silly question, but why not
run<br>
the SliMP3 server from that machine?<br>
</blockquote>
<blockquote type="cite" cite>Still, we should be sure it works with
NFS.</blockquote>
<div><br></div>
<div>The NFS problem may not be solvable without threading or multiple
processes in perl.&nbsp; If the server blocks for a fractional second
while a directory is opened over NFS, there's precious little we can
do about making the animation smoother.&nbsp; </div>
</body>
</html>

[dean blackketter]

Try changing this line in server.pl
if (SliMP3::Scheduler::run_tasks(0.0125))
to 0.00001 instead of 0.0125.
You're right it's probably something with NFS. I hope we don't
have to rethink this whole scanning thing :(
I'll do some testing with NFS.

Sean, thanks. This certainly helped. The animation seems much smoother
and I can't make playback stop by holding down buttons on the remote.
Except, of course, using the stop, pause, or power buttons. :)

Ok, I'll change it to a very small number. Thanks.

I must admit that while the animation is extremely cool, if it were
configurable I'd probably turn it off. I find the scrolling to be to
fast enough so that I can't read the text while it's moving, but slow
enough to be annoying (after the gee whiz-iness wears off). However,
the "bumps" that happen when you press right when on an mp3 file and
left when at SliMP3 home, are perhaps my favorite UI feature.

Ok, can you file a feature request for an option to turn off the animation?

I know you can interrupt, and navigate through, the animation and I
often do this on my local (personal) mp3 collection, since I'm
familiar with the contents. But when browsing the NFS mounted stuff
(which isn't my collection), I need to read the display and decide
what to do. In this case the lack of familiarity with the collection
prevents me from making quick selections while browsing and the
animation only slows the process down.

I think that there is probably some tweaking to be done on the
animation to make it smoother and faster while still make sense
visually.

My usage patterns are likely to be atypical. Probably few people will
have access to a 240GB mp3 collection.

I'm trying my best.... :-)

-dean

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited calling with 3-way conferencing. Only $1/Mo.
with CrystalVoice! FREE trial. Click Here.
http://us.click.yahoo.com/Hb1xVB/HxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[vajonez]

Try changing this line in server.pl
if (SliMP3::Scheduler::run_tasks(0.0125))
to 0.00001 instead of 0.0125.
You're right it's probably something with NFS. I hope we don't
have to rethink this whole scanning thing :(
I'll do some testing with NFS.

Sean, thanks. This certainly helped. The animation seems much smoother
and I can't make playback stop by holding down buttons on the remote.
Except, of course, using the stop, pause, or power buttons. :)

I must admit that while the animation is extremely cool, if it were
configurable I'd probably turn it off. I find the scrolling to be to
fast enough so that I can't read the text while it's moving, but slow
enough to be annoying (after the gee whiz-iness wears off). However,
the "bumps" that happen when you press right when on an mp3 file and
left when at SliMP3 home, are perhaps my favorite UI feature.

I know you can interrupt, and navigate through, the animation and I
often do this on my local (personal) mp3 collection, since I'm
familiar with the contents. But when browsing the NFS mounted stuff
(which isn't my collection), I need to read the display and decide
what to do. In this case the lack of familiarity with the collection
prevents me from making quick selections while browsing and the
animation only slows the process down.

My usage patterns are likely to be atypical. Probably few people will
have access to a 240GB mp3 collection.


-- Tom


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Call any Phone in the World from your PC with CrystalVoice
-LOW rates world-wide - $0.039/min in U.S.
FREE trial. Click here.
http://us.click.yahoo.com/Ib1xVB/IxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[dean blackketter]

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>[slimp3-dev] Re: background
scanning</title></head><body> <blockquote type="cite" cite>&gt; Try changing this line in
server.pl<br>
&gt; <br>
&gt;&nbsp; if (SliMP3::Scheduler::run_tasks(0.0125))<br>
&gt; <br>
&gt; to 0.00001 instead of 0.0125.<br>
&gt; <br>
&gt; You're right it's probably something with NFS. I hope we
don't<br>
&gt; have to rethink this whole scanning thing :(<br>
&gt; <br>
&gt; I'll do some testing with NFS.<br>
<br>
Sean, thanks. This certainly helped. The animation seems much
smoother<br>
and I can't make playback stop by holding down buttons on the
remote.<br>
Except, of course, using the stop, pause, or power buttons.
:)</blockquote>
<div><br></div>
<div>Ok, I'll change it to a very small number.&nbsp; Thanks.&nbsp;
</div>
<div><br></div>
<blockquote type="cite" cite>I must admit that while the animation is
extremely cool, if it were<br>
configurable I'd probably turn it off. I find the scrolling to be
to<br>
fast enough so that I can't read the text while it's moving, but
slow<br>
enough to be annoying (after the gee whiz-iness wears off).
However,<br>
the &quot;bumps&quot; that happen when you press right when on an mp3
file and<br>
left when at SliMP3 home, are perhaps my favorite UI
feature.</blockquote>
<div><br></div>
<div>Ok, can you file a feature request for an option to turn off the
animation?</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite>I know you can interrupt, and navigate
through, the animation and I<br>
often do this on my local (personal) mp3 collection, since I'm<br>
familiar with the contents. But when browsing the NFS mounted
stuff<br>
(which isn't my collection), I need to read the display and decide<br>
what to do. In this case the lack of familiarity with the
collection<br>
prevents me from making quick selections while browsing and the<br>
animation only slows the process down.</blockquote>
<div><br></div>
<div>I think that there is probably some tweaking to be done on the
animation to make it smoother and faster while still make sense
visually.</div>
<div><br>
<br>
</div>
<blockquote type="cite" cite>My usage patterns are likely to be
atypical.&nbsp; Probably few people will</blockquote>
<blockquote type="cite" cite>have access to a 240GB mp3
collection.<br>
</blockquote>
<div><br></div>
<div>I'm trying my best.... :-)</div>
<div><br></div>
<div>-dean</div>
</body>
</html>

[Sean Adams]

Tom,

Try changing this line in server.pl

if (SliMP3::Scheduler::run_tasks(0.0125))

to 0.00001 instead of 0.0125.

You're right it's probably something with NFS. I hope we don't have to
rethink this whole scanning thing :(

I'll do some testing with NFS.

Sean

It didn't work out well for me. Animation stopped and stuttered,
browsing the UI was slow and cumbersome, even playing stopped.
Took almost 2 minutes to scan the complete directory structure
(11Gb library, 3,785 files in 386 folders). Although of course
once it was done, it was nice and fast going through things.

I, too, am having some difficulties with the background scanning. My
setup is perhaps a little odd. I'm running OpenBSD 2.9 on a 500 MHz P3
with 320 MB of RAM. I have ~3GB of mp3's stored locally and ~240GB
(~43000 tracks in ~5000 directories) in an NFS mounted subdirectory
(on a 100 MB/s switched network).
The background scanning takes >30 minutes and while it is happening
the animation stutters and I can get playing to stop by depressing any
button on the remote continuously for ~ 1 second. This is while
playing a local file.
After the scan completes I have no problems.
I'm sure some of the problem stems from the NFS mount of such a large
collection.
-- Tom
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Need new boots for winter? Looking for a perfect gift for your shoe loving friends?
Zappos.com is the perfect fit for all your shoe needs!
http://us.click.yahoo.com/ltdUpD/QrSDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Sean Adams]

That may be an issue for me. I'm running the server on a Pentium 90 (not
900!) with 16MB of RAM. I can set my emulator to grab the stream data
from the server as fast as possible, and the server works fine; but a
cache that takes up lots of RAM may become a problem.

It won't be a problem if you're running on Linux - the unused RAM will be
swapped out until you need it. So you'll still (mostly) get the
accelleration. Take a look at process size vs. resident size, in top. If
your RAM is limited, it'll swap out the least recently used pages. I agree
though, it's still too much memory usage for the cache.



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Need new boots for winter? Looking for a perfect gift for your shoe loving friends?
Zappos.com is the perfect fit for all your shoe needs!
http://us.click.yahoo.com/ltdUpD/QrSDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Jacob Potter]

Memory usage seems to be on the order of 1M per 1000 items - we're wasting
a lot of RAM but it's still not too bad. Memory-wise there are some easy
improvements we could make, such as caching everything in a single hash
(all those keys have to be duplicated in each hash).

Indeed. Let's see if it's a problem for folks and fix what needs
fixing. I wonder if people have RAM proportional to their library
size...

That may be an issue for me. I'm running the server on a Pentium 90 (not
900!) with 16MB of RAM. I can set my emulator to grab the stream data
from the server as fast as possible, and the server works fine; but a
cache that takes up lots of RAM may become a problem.

- Jacob
--
"Terminak #3 has bad keyboard. Pkease fix."

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Need new boots for winter? Looking for a perfect gift for your shoe loving friends?
Zappos.com is the perfect fit for all your shoe needs!
http://us.click.yahoo.com/ltdUpD/QrSDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Richard Smith]

I hear you - re-encoding is not ideal, but I have to work with the chips
that exist. If there were a single, cost effective chip that did
ogg/mp3/wav/whatever, you can bet we'd be using it.

Yea, I hear ya.

The best way to incorporate codecs is probably to write a perl interface
for them, and link them right into our server. Of course, piping through
an external command is the easiest way, but unfortunately we can't be
Unix-only.

Which is why I'm trying to get it working on Windows. I figure if I can get
it to work with the Windows kludge, it'll easily port to *nix. :)
Thankfully, LAME is available for both.



Richard Smith
richard-+***@public.gmane.org

- Free, REALLY customisable hosted messageboards
- http://www.chatbear.com/
- I wrote them, trust me, they're good... :)


To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Sean Adams]

I hear you - re-encoding is not ideal, but I have to work with the chips
that exist. If there were a single, cost effective chip that did
ogg/mp3/wav/whatever, you can bet we'd be using it.

The best way to incorporate codecs is probably to write a perl interface
for them, and link them right into our server. Of course, piping through
an external command is the easiest way, but unfortunately we can't be
Unix-only.

It's a real bummer. I'm surprised that playing stopped, as the
client's buffer is several seconds deep. Did it stop altogether or
did it break up?

Yea, first time it's ever hapenned, it just stopped dead.

Anybody have any idea why the windows performance would be so
different than linux. (Be kind.)

I have since removed the call in server.pl that started off the scanning and
find that browsing through directories without the pre-cache is plenty fast
as is, including a directory which has a couple of hundred items in it. I
don't even notice it reading it (although I believe I've noticed it in the
past).
On an unrelated note, I've been playing with trying to get WAV files to play
instead of just MP3's, by pushing the track through a LAME binary first. It
works quite well apart from me not being able to push LAME into a background
process, so the whole server hangs until it's finished. This should be
easily solved on *nix (just stick & on the end of the command line) but I
haven't found the right solution for win yet. The other option is to use
stdin and stdout, but I'm not sure of the best way to approach that on win
either. If I can get it to work for WAV, then OGG will automatically work
too (since LAME can encode both).
Unfortunately hardware that can only play MP3 is a bit of a brick wall
because I don't think many people will want all their nice new OGG files
re-encoded to MP3 so they can hear them (although, we could encode it to MP3
at such a high bitrate, they might not notice).
Richard Smith
- Free, REALLY customisable hosted messageboards
- http://www.chatbear.com/
- I wrote them, trust me, they're good... :)
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited PC-PC calling at Crystal Voice! - Only $1/Mo.
Download your free 30 day trial. Click here.
http://us.click.yahoo.com/Gb1xVB/GxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Steve Hill]

One thing that comes to mind re: windows performance is the control you
have over fractions of a second, I think.. the HiRes.dll doesn't
implement some of the functions that are available in the unix world
(although I don't know how you're doing the timers anymore - I haven't
looked at the code in a few weeks).

-----Original Message-----
From: Sean Adams <yahoo-***@public.gmane.org>
To: <slimp3-dev-***@public.gmane.org>
Date: Tue, 18 Dec 2001 00:15:37 +0000 (GMT)
Subject: RE: [slimp3-dev] background scanning

I think a smaller time slice for the scanning process would fix it.
There's very little advantage to doing more than one iteration of the
scan
function at a time - it's just a couple function calls and one system
call
to select to go through the main loop.
The problem I think is that only one packet can be served to the player
per time slice through the scheduler, so you're limiting the data rate
there if it's more than about 10ms.
Sean

Richard,
Thanks for the feedback.
It's a real bummer. I'm surprised that playing stopped, as the
client's buffer is several seconds deep. Did it stop altogether or
did it break up?
Anybody have any idea why the windows performance would be so
different than linux. (Be kind.)
-dean
p.s. Even before I added the background scanning, I've had a couple
of times when playing just stopped without warning on my system here.
Skipping to the next song starts it up again. Anybody else seeing
this?

Please give it a try and post if you have any problems. I'm
especially interested in if and how it effects the user interface

and

if there are hiccups in the animation. The background task

manager

gives the tasks 1/80th of a second to run each iteration, which

is

the fastest frame rate in any of the animations. I expect that

we'll

tune these numbers after we have a little more experience.

It didn't work out well for me. Animation stopped and stuttered,

browsing

the UI was slow and cumbersome, even playing stopped.
Took almost 2 minutes to scan the complete directory structure (11Gb
library, 3,785 files in 386 folders). Although of course once it was

done,

it was nice and fast going through things.
Can I also suggest that the hash and everything in it is saved to a

file so

that the next time I load up the server, it just loads that file to

load

everyhting into the hash. Would be much quicker than scanning on

every

startup.
This is all on a Duron 600 Win2K machine with 192mb RAM.
Richard Smith
- Free, REALLY customisable hosted messageboards
- http://www.chatbear.com/
- I wrote them, trust me, they're good... :)
Your use of Yahoo! Groups is subject to

http://docs.yahoo.com/info/terms/

Your use of Yahoo! Groups is subject to

http://docs.yahoo.com/info/terms/
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Need new boots for winter? Looking for a perfect gift for your shoe loving friends?
Zappos.com is the perfect fit for all your shoe needs!
http://us.click.yahoo.com/ltdUpD/QrSDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Richard Smith]

It's a real bummer. I'm surprised that playing stopped, as the
client's buffer is several seconds deep. Did it stop altogether or
did it break up?

Yea, first time it's ever hapenned, it just stopped dead.

Anybody have any idea why the windows performance would be so
different than linux. (Be kind.)

I have since removed the call in server.pl that started off the scanning and
find that browsing through directories without the pre-cache is plenty fast
as is, including a directory which has a couple of hundred items in it. I
don't even notice it reading it (although I believe I've noticed it in the
past).


On an unrelated note, I've been playing with trying to get WAV files to play
instead of just MP3's, by pushing the track through a LAME binary first. It
works quite well apart from me not being able to push LAME into a background
process, so the whole server hangs until it's finished. This should be
easily solved on *nix (just stick & on the end of the command line) but I
haven't found the right solution for win yet. The other option is to use
stdin and stdout, but I'm not sure of the best way to approach that on win
either. If I can get it to work for WAV, then OGG will automatically work
too (since LAME can encode both).

Unfortunately hardware that can only play MP3 is a bit of a brick wall
because I don't think many people will want all their nice new OGG files
re-encoded to MP3 so they can hear them (although, we could encode it to MP3
at such a high bitrate, they might not notice).



Richard Smith
richard-+***@public.gmane.org

- Free, REALLY customisable hosted messageboards
- http://www.chatbear.com/
- I wrote them, trust me, they're good... :)


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Call any Phone in the World from your PC with CrystalVoice
-LOW rates world-wide - $0.039/min in U.S.
FREE trial. Click here.
http://us.click.yahoo.com/Ib1xVB/IxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Sean Adams]

I think a smaller time slice for the scanning process would fix it.
There's very little advantage to doing more than one iteration of the scan
function at a time - it's just a couple function calls and one system call
to select to go through the main loop.

The problem I think is that only one packet can be served to the player
per time slice through the scheduler, so you're limiting the data rate
there if it's more than about 10ms.

Sean

Richard,
Thanks for the feedback.
It's a real bummer. I'm surprised that playing stopped, as the
client's buffer is several seconds deep. Did it stop altogether or
did it break up?
Anybody have any idea why the windows performance would be so
different than linux. (Be kind.)
-dean
p.s. Even before I added the background scanning, I've had a couple
of times when playing just stopped without warning on my system here.
Skipping to the next song starts it up again. Anybody else seeing
this?

Please give it a try and post if you have any problems. I'm
especially interested in if and how it effects the user interface and
if there are hiccups in the animation. The background task manager
gives the tasks 1/80th of a second to run each iteration, which is
the fastest frame rate in any of the animations. I expect that we'll
tune these numbers after we have a little more experience.

It didn't work out well for me. Animation stopped and stuttered, browsing
the UI was slow and cumbersome, even playing stopped.
Took almost 2 minutes to scan the complete directory structure (11Gb
library, 3,785 files in 386 folders). Although of course once it was done,
it was nice and fast going through things.
Can I also suggest that the hash and everything in it is saved to a file so
that the next time I load up the server, it just loads that file to load
everyhting into the hash. Would be much quicker than scanning on every
startup.
This is all on a Duron 600 Win2K machine with 192mb RAM.
Richard Smith
- Free, REALLY customisable hosted messageboards
- http://www.chatbear.com/
- I wrote them, trust me, they're good... :)
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[dean blackketter]

Schweet. 2 seconds to build a playlist of 3200 items, with debugging off.
We could get even more performance by caching directory contents, right?

We already do. Check out lib/SliMP3/Playlist.pm

Memory usage seems to be on the order of 1M per 1000 items - we're wasting
a lot of RAM but it's still not too bad. Memory-wise there are some easy
improvements we could make, such as caching everything in a single hash
(all those keys have to be duplicated in each hash).

Indeed. Let's see if it's a problem for folks and fix what needs
fixing. I wonder if people have RAM proportional to their library
size...

Shouldn't we also do the playlist building in the background? Even if it
only takes a couple seconds for a large library, it's important with
multiple clients not to have the server tied up even for that long. Plus
we could send a groovy animation to the client... "building playlist"
with a spinning bar or something.

Good idea. Can you file that on Sourceforge? :-)

Outstanding, Dean!

thanks.

-dean

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited calling with 3-way conferencing. Only $1/Mo.
with CrystalVoice! FREE trial. Click Here.
http://us.click.yahoo.com/Hb1xVB/HxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[dean blackketter]

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [slimp3-dev] background
scanning</title></head><body>
<blockquote type="cite" cite>Schweet. 2 seconds to build a playlist of
3200 items, with debugging off.<br>
We could get even more performance by caching directory contents,
right?</blockquote>
<div><br></div>
<div>We already do.&nbsp; Check out lib/SliMP3/Playlist.pm </div>
<div><br></div>
<blockquote type="cite" cite>Memory usage seems to be on the order of
1M per 1000 items - we're wasting<br>
a lot of RAM but it's still not too bad. Memory-wise there are some
easy<br>
improvements we could make, such as caching everything in a single
hash<br>
(all those keys have to be duplicated in each hash).</blockquote>
<div><br></div>
<div>Indeed.&nbsp; Let's see if it's a problem for folks and fix what
needs fixing.&nbsp; I wonder if people have RAM proportional to their
library size...</div>
<div><br></div>
<blockquote type="cite" cite>Shouldn't we also do the playlist
building in the background? Even if it<br>
only takes a couple seconds for a large library, it's important
with<br>
multiple clients not to have the server tied up even for that long.
Plus<br>
we could send a groovy animation to the client... &quot;building
playlist&quot;<br>
with a spinning bar or something.</blockquote>
<div><br></div>
<div>Good idea.&nbsp; Can you file that on Sourceforge?&nbsp;
:-)</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite>Outstanding, Dean!</blockquote>
<div><br>
thanks.</div>
<div><br></div>
<div>-dean</div>
</body>
</html>

[Sean Adams]

You can also save by using references where possible. What type of
system is that? It will differ somewhat between OS and perl build.

It's LinuxPPC 2.2.18 and Perl 5.6.1. Agreed, references instead of a long
string for the hash keys is a good idea. Saves space and speeds lookup
time.

Sean




------------------------ Yahoo! Groups Sponsor ---------------------~-->
Need new boots for winter? Looking for a perfect gift for your shoe loving friends?
Zappos.com is the perfect fit for all your shoe needs!
http://us.click.yahoo.com/ltdUpD/QrSDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[dean blackketter]

hi all,

i just checked in a simple background ID3 and directory scanner.

Essentially, at server start time, it starts scanning the mp3dir
recursively as a background task. Each time the task gets called it
either decends one directory or gets the ID3 information from a
single file.

The results of directory opening or ID3 inspection are cached in the
existing caches.

When the music directory has been completely scanned, the scanner
stops. (On my Duron 800 server, the scanning was taking about 20% of
my CPU, so I thought that scanning should probably not be continuous.
This could be a server setting in the future.)

Please give it a try and post if you have any problems. I'm
especially interested in if and how it effects the user interface and
if there are hiccups in the animation. The background task manager
gives the tasks 1/80th of a second to run each iteration, which is
the fastest frame rate in any of the animations. I expect that we'll
tune these numbers after we have a little more experience.

-dean

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited calling with 3-way conferencing. Only $1/Mo.
with CrystalVoice! FREE trial. Click Here.
http://us.click.yahoo.com/Hb1xVB/HxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[dean blackketter]

hi all,

i just checked in a simple background ID3 and directory scanner.

Essentially, at server start time, it starts scanning the mp3dir recursively as a background task. Each time the task gets called it either decends one directory or gets the ID3 information from a single file.

The results of directory opening or ID3 inspection are cached in the existing caches.

When the music directory has been completely scanned, the scanner stops. (On my Duron 800 server, the scanning was taking about 20% of my CPU, so I thought that scanning should probably not be continuous. This could be a server setting in the future.)

Please give it a try and post if you have any problems. I'm especially interested in if and how it effects the user interface and if there are hiccups in the animation. The background task manager gives the tasks 1/80th of a second to run each iteration, which is the fastest frame rate in any of the animations. I expect that we'll tune these numbers after we have a little more experience.

-dean