This was all in the previous thread.

> file type?


all mp3s.

> server version?


5.0.1 through nightly.

> os?


Solaris 9 - freshly patched

Perl - 5.8.0 with Time::HiRes

> client type?


Slimp3 - firmware 2.2
and another
Slimp3 - firmware 2.2

No synching.

I agree entirely that it shouldnt die
I turned on the buffer switch instead of the progress
bar, and you can watch it rise and fall and then as
soon as the buffer fills up the track stops about two
seconds later. Right about where that "empty" packet
is in the stream.

Here is the start of the --d_source

2004-01-29 00:59:24 loading conversion config files...
2004-01-29 00:59:24 input: 'mov' output: 'mp3'
clienttype: '*': clientid: '*': '$mov123$ $FILE$ |
$lame$ --silent -b $BITRATE$ -r $-x$ - -'
2004-01-29 00:59:24 input: 'ogg' output: 'mp3'
clienttype: '*': clientid: '*': '$oggdec$ -Q -o - -R 1
$FILE$ | $lame$ --silent -b $BITRATE$ -r $-x$ - -'
2004-01-29 00:59:24 input: 'wav' output: 'mp3'
clienttype: '*': clientid: '*': '$lame$ --silent -b
$BITRATE$ $FILE$ -'
2004-01-29 00:59:24 input: 'aif' output: 'mp3'
clienttype: '*': clientid: '*': '$lame$ --silent -b
$BITRATE$ $FILE$ -'
2004-01-29 00:59:24 input: 'shn' output: 'mp3'
clienttype: '*': clientid: '*': 'shorten -d $FILE$ |
$lame$ --silent -b $BITRATE$ - -'
2004-01-29 00:59:24 input: 'flc' output: 'mp3'
clienttype: '*': clientid: '*': 'flac -dc $FILE$ |
$lame$ --silent -b $BITRATE$ - -'
2004-01-29 00:59:24 input: 'aif' output: 'aif'
clienttype: 'squeezebox': clientid: '*': '-'
2004-01-29 00:59:24 input: 'wav' output: 'wav'
clienttype: 'squeezebox': clientid: '*': '-'
2004-01-29 00:59:24 input: 'mp3' output: 'mp3'
clienttype: 'slimp3': clientid: '*': '-'
2004-01-29 00:59:24 input: 'mp3' output: 'mp3'
clienttype: 'squeezebox': clientid: '*': '-'
2004-01-29 00:59:24 input: 'mp3' output: 'mp3'
clienttype: 'http': clientid: '*': '-'
2004-01-29 00:59:24 input: 'rts' output: 'mp3'
clienttype: '*': clientid: '*': 'rtsp_player $URL$ -'


Then tons of this message while playing. They stop as
soon as the music stops and changes to the next
message. You can see by the timestamp how long between
the messages.

Thanks again for helping! I am desperate!

2004-01-29 01:00:27 read a chunk of 1400 length
2004-01-29 01:00:27 metadata now: 0
2004-01-29 01:00:27 read a chunk of 1400 length
2004-01-29 01:00:27 metadata now: 0
2004-01-29 01:00:27 read a chunk of 1400 length
2004-01-29 01:00:27 metadata now: 0
2004-01-29 01:00:27 read a chunk of 1400 length
2004-01-29 01:00:27 metadata now: 0
2004-01-29 01:00:27 read a chunk of 1400 length
2004-01-29 01:00:27 metadata now: 0
2004-01-29 01:00:41 realpos 92900 calcuated from bytes
received: 222072 minus buffer fullness: 129172
2004-01-29 01:00:41 songTime: 3.87083333333333 =
(92900(realpos) / 4166007(size) * 173.583625(duration)
* 1(rate)) + 0(time offset of started stream)
2004-01-29 01:00:53 realpos 92900 calcuated from bytes
received: 222072 minus buffer fullness: 129172
2004-01-29 01:00:53 songTime: 3.87083333333333 =
(92900(realpos) / 4166007(size) * 173.583625(duration)
* 1(rate)) + 0(time offset of started stream)
2004-01-29 01:00:53 realpos 92900 calcuated from bytes
received: 222072 minus buffer fullness: 129172
2004-01-29 01:00:53 songTime: 3.87083333333333 =
(92900(realpos) / 4166007(size) * 173.583625(duration)
* 1(rate)) + 0(time offset of started stream)
2004-01-29 01:00:54 realpos 92900 calcuated from bytes
received: 222072 minus buffer fullness: 129172
2004-01-29 01:00:54 songTime: 3.87083333333333 =
(92900(realpos) / 4166007(size) * 173.583625(duration)
* 1(rate)) + 0(time offset of started stream)



>
> a track shouldn't cause the server to just die when
> the buffer is full. If you
> are using server 5.0.1 with winamp, thats a known
> bug and you'll need to update
> to a nightly build or the soon to be released v5.1
>
> maybe --d_source will help moreso than --d_stream.
>
> -kdf
>