PDA

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



Kilgore Trout
2004-01-29, 17:38
Well, I know just enough Perl to be dangerous and
through a sick miracle I am able to listen to music.

I changed this section of code in Stream.pm from
sendEmptyChunk to sendNextChunk figuring that I dont
want it to stop sending chunks just because the buffer
is full, because that is where my problem is. Well, it
didnt work the way I wanted to in that the buffer
doesnt fill up at all now. Which for now is GREAT!
because I can listen to music!
Hats off to inebriated coding!
If anyone is a stout drinker this beer is incredible.
http://www.victorybeer.com/storm.htm
but dont take my word for it.
http://beeradvocate.com/beer/rate_results/345/1013/

Anyway here is the code I mangled from the nightly.
It is in the sendNextChunk sub.

387
Slim::Utils::Timers::setTimer($client,
Time::HiRes::time() + $BUFFER_FULL_DELAY,
\&sendNextChunk);






--- Kilgore Trout <diatrive (AT) yahoo (DOT) com> wrote:
> Hi,
> I will try a new network card tonight and see what
> happens. The play has already died by the time the
> transition comes into play. On the --d_source output
> it just stops, no message. The only oddity I have
> found in the logs is during the --d_stream_v this
> empty chunk that gets sent seems to get sent when
> the
> buffer fills up and the traffic stops. Does anyone
> else see this message ever? This is the only thing
> that happens every time play dies, and only when
> play
> dies.
>
> Thanks again for your time!
>
> 2004-01-29 00:06:48 00:04:20:04:07:4e
> 1075352808.2055
> gotAck for seq: 111 2004-01-29 00:06:48 ack:
> wptr:11200, rptr:14057, seq:111, 2004-01-29 00:06:48
> bytesinflight:1400 fullness:128158
> 2004-01-29 00:06:48 00:04:20:04:07:4e
> 1075352808.21153
> sending stream, seq=112 len=1400 wptr=11900
> state=play
> inflight=
> 2004-01-29 00:06:48 00:04:20:04:07:4e
> 1075352808.21831
> gotAck for seq: 112 2004-01-29 00:06:48 ack:
> wptr:11900, rptr:14358, seq:112, 2004-01-29 00:06:48
> bytesinflight:1400 fullness:128956
> 2004-01-29 00:06:48 00:04:20:04:07:4e sendEmptyChunk
> 2004-01-29 00:06:48 00:04:20:04:07:4e
> 1075352808.27621
> sending stream, seq=113 len=0 wptr=12600 state=play
> inflight=
> 2004-01-29 00:06:48 00:04:20:04:07:4e
> 1075352808.32994
> sending stream, seq=113 len=0 wptr=12600 state=play
> inflight=
> 2004-01-29 00:06:48 00:04:20:04:07:4e
> 1075352808.38522
> sending stream, seq=113 len=0 wptr=12600 state=play
> inflight=
>
>
>
>
>
> --- Jason Holtzapple <jasonholtzapple (AT) yahoo (DOT) com>
> wrote:
> > > 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.
> >
> > Tried out 29 Jan build on Solaris and things seem
> > ok.
> >
> > I'm not seeing this problem when my SLIMP3 buffer
> > fills up.
> > Everything is playing normally. I did capture some
> > --d_source
> > output from a song transition:
> >
> > 2004-01-29 09:40:45.5785 Read 1400 bytes from
> source
> > 2004-01-29 09:40:45.6647 songTime:
> > [243.736635009916] = (6265974(realpos) /
> > 6395891(size) * 248.790204081633(duration) *
> > 1(rate)) + 0(time offset of
> > started stream)
> > 2004-01-29 09:40:45.9474 Reduced chunksize to 835
> at
> > end of file (6395891 -
> > 6395056)
> > 2004-01-29 09:40:45.9492 Read 679 bytes from
> source
> > 2004-01-29 09:40:45.9904 Reduced chunksize to 156
> at
> > end of file (6395891 -
> > 6395735)
> > 2004-01-29 09:40:45.9921 Read to end of file or
> pipe
> > 2004-01-29 09:40:45.9942 end of file or error on
> > socket, opening next song,
> > (song pos: 6395735(tell says: . 6395891),
> > totalbytes: 6395891)
> > 2004-01-29 09:40:45.9958 opening next song...
> > 2004-01-29 09:40:46.0277 the next song is number
> 1,
> > was 0
> > 2004-01-29 09:40:46.0303 checking formats for:
> > mp3-mp3-slimp3-00:04:20:02:03:f1
> > 2004-01-29 09:40:46.0319 Matched mp3-mp3-slimp3-*
> > 2004-01-29 09:40:46.0357 openSong on:
> >
>
/export/music/flaming_lips/the_soft_bulletin/flaming_lips_-_the_soft_bulletin_-_02_a_spoonful_weighs_a_ton.mp3
> > 2004-01-29 09:40:46.0416 openSong: getting
> duration
> > 212.48, size 5183629, and
> > offset 156 for
> >
>
/export/music/flaming_lips/the_soft_bulletin/flaming_lips_-_the_soft_bulletin_-_02_a_spoonful_weighs_a_ton.mp3
> > 2004-01-29 09:40:46.0436 checking formats for:
> > mp3-mp3-slimp3-00:04:20:02:03:f1
> > 2004-01-29 09:40:46.0453 Matched mp3-mp3-slimp3-*
> > 2004-01-29 09:40:46.0469 openSong: this is an mp3
> > file:
> >
>
/export/music/flaming_lips/the_soft_bulletin/flaming_lips_-_the_soft_bulletin_-_02_a_spoonful_weighs_a_ton.mp3
> > 2004-01-29 09:40:46.0487 file type: mp3 format:
> > mp3
> > 2004-01-29 09:40:46.0503 command: -
> > 2004-01-29 09:40:46.0523 openSong: opening file
> >
>
/export/music/flaming_lips/the_soft_bulletin/flaming_lips_-_the_soft_bulletin_-_02_a_spoonful_weighs_a_ton.mp3
> > 2004-01-29 09:40:46.0541 seeking in 156 into
> >
>
/export/music/flaming_lips/the_soft_bulletin/flaming_lips_-_the_soft_bulletin_-_02_a_spoonful_weighs_a_ton.mp3
> > 2004-01-29 09:40:46.0561 Streaming with format:
> mp3
> > 2004-01-29 09:40:46.1179 Negative position
> > calculated, we are still playing out
> > the previous song.
> > 2004-01-29 09:40:46.1197 realpos -119582 calcuated
> > from bytes received: 6395734
> > minus buffer fullness: 119582
> > 2004-01-29 09:40:46.1213 songTime: [0] =
> (0(realpos)
> > / 5183629(size) *
> > 212.48(duration) * 1(rate)) + 0(time offset of
> > started stream)
> > 2004-01-29 09:40:46.1328 Negative position
> > calculated, we are still playing out
> > the previous song.
> > 2004-01-29 09:40:46.1346 realpos -119582 calcuated
> > from bytes received: 6395734
> > minus buffer fullness: 119582
> > 2004-01-29 09:40:46.1362 songTime: [0] =
> (0(realpos)
> > / 5183629(size) *
> > 212.48(duration) * 1(rate)) + 0(time offset of
> > started stream)
> > 2004-01-29 09:40:46.1498 Read 1399 bytes from
> source
> > 2004-01-29 09:40:46.1916 Read 1400 bytes from
> source
> > 2004-01-29 09:40:46.2307 Read 1400 bytes from
> source
> > ...etc..
> >
> > --Jason
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! SiteBuilder - Free web site building tool.
> > Try it!
> > http://webhosting.yahoo.com/ps/sb/
> >