PDA

View Full Version : Stops when buffer is full. Was slimserver on solaris.



Kilgore Trout
2004-01-28, 23:10
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
>

kdf
2004-01-28, 23:37
Quoting Kilgore Trout <diatrive (AT) yahoo (DOT) com>:

> This was all in the previous thread.

sorry about that. Signal to noise has been high lately, so I haven't been
reading as carefully as I usually do.
>

> Solaris 9 - freshly patched
>
> Perl - 5.8.0 with Time::HiRes
>
I know Holtzapple is using Solaris with success. Ever seen this before, Jason?

> 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

the startup is fine. its the start of playback, the stoppage and the switch to
the next song that might matter here.
>
> 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)
>

I'm curious what it looks like at the start of a song. Its odd that none of the
numbers are changing, and I'm afraid nothing is tweaking for me on this right
now. even with 5.0.1 slimp3 used to work fairly well wint just mp3's. If this
is still giving you issues as of the Jan 26 build, you should definately file a
bug report at bugs.slimdevices.com so this can be tracked.

-kdf