Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 2 of 2
  1. #1
    Kilgore Trout
    Guest

    Stops when buffer is full. Was slimserver on solaris.

    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
    >

  2. #2
    NOT a Slim Devices Employee kdf's Avatar
    Join Date
    Apr 2005
    Posts
    9,493

    Stops when buffer is full. Was slimserver on solaris.

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •