PDA

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



Kilgore Trout
2004-01-29, 17:55
Bah, this did not work for long. Oh well, back to the
drawing board.

--- Kilgore Trout <diatrive (AT) yahoo (DOT) com> wrote:
> 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) *
>
=== message truncated ===

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/