Re: Re: Problems with the player stopping

Sean Adams <sadams-C+JAmueIyFXt/WbtSZLAmwC/[email protected]> Mon, 7 Jan 2002 02:56:35 +0000 (GMT)
Newsgroups gmane.music.equipment.slimp3.user
Message-ID <[email protected]>
This is the expected behavior with the current server design - if the
player's beuffer runs out because the server is tied up, then the stream
will stop (instead of stuttering, or starting up later).  The player's
buffer is pretty big, but there are some critical points in the server
where it can get tied up long enough for the buffer to run empty.

We have a number of ideas for how to improve this, but it's going to be
major surgery (moving to a multithreaded architecture, probably). The two
things that can tie up the server right now are mainly internal processes,
like building a huge playlist, refreshing a large list in the web
interface, or reading a big directory from disk. We've made a few
performance improvements since the 1.8 release, but we haven't started on
the full overhaul needed to remove these bottlenecks.

There are also some external things which can cause this, such as having
to wait for a disk to spin up. The solution needed here will probably be
to have a separate thread for streaming, and keep a large RAM buffer in
the server in case there's a long delay accessing the disk.


On Mon, 7 Jan 2002, robertlbrown wrote:

> The exact same thing happens to me.  I notice it happens when my
> server needs to go away for a period of time to do something else.
> Just as in Jordon's case, I have a top-level directory with a large
> number of subdirectories - hundreds of them.  I can often get the
> player to stall if I click the "Top Level" link on the web
> interface.  It takes my system a few seconds (4-8) to read the
> directory and as often as not, the player stops and will not start.
>
> But, sometimes it happens during the course of playing a long
> playlist, too.  I think it's the same circumstance, here's why:
>
> My mp3 directory is a LVM volume (much like a RAID 0) of eight IDE
> disks, concatenated.  After any individual drive has been idle for a
> while (time unknown - several minutes) it will spin down.  Then when
> the playlist advances to the next song, if a disk has to spin back
> up, the player will generally, if not always, stall.
>
> The same thing can happen if I leave the web interface idle for a
> long period (allowing the disks to spin down) and then start browsing
> through the directories again.  In order to read the directories,
> disks have to spin up, causing the dead time that results in the
> player hanging.
>
> In any of these instances, I can get it all going again by just
> clicking on one of the songs listed in the playlist of the web
> interface.  Starts right up.
>
> This smells like a timer management problem in the server.
>
> Server 1.8, firmware 1.1.
>
> -- Bob Brown
>
>
>
> To unsubscribe from this group, send an email to:
> [email protected]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>


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

To unsubscribe from this group, send an email to:
[email protected]

 

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