Ticket #928 (new bug)

Opened 4 months ago

Last modified 4 months ago

Some live audio streams don't work correctly w/ autostart

Reported by: pablo Owned by: pablo
Milestone: Flash 5.3 Keywords:
Cc: Forum thread: http://www.longtailvideo.com/support/forums/jw-player/bug-reports/11647/audio-streaming-dont-autostart

Description

This issue can probably be tracked down to the following line: trunk/fl5/src/com/longtailvideo/jwplayer/media/SoundMediaProvider.as#L150

Replace

	if (_sound.isBuffering == true && _sound.bytesTotal > _sound.bytesLoaded) {

with

	if (_sound.isBuffering == true && _sound.bytesTotal > _sound.bytesLoaded > 0) {

Change History

Changed 4 months ago by pablo

  • milestone changed from Flash 5.2 to Flash 5.3

From matthias:

To wait with the playback until the buffer is filled up with the desired amount of bytes is the task of the Sound object, or respectively the SoundLoaderContext, which is passed to the Sound object with the load call. Isn't it? At least that's what the Adobe documentation says there: http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/media/Sound.html#play() in the example description.

Apart from that:
To check wether the bytesLoaded value is > 0 at this point, won't fix the problem. The debug-output above shows that in the moment the Channel gets stopped, the situation is the following:
bytesTotal=9348, bytesLoaded=8598
The problem is, that the Firefox plugin updates both the bytesTotal and the bytesLoaded value while it downloads the mp3-livestream.
So, with the current implementation, the scenario is this one:

The _sound.isBuffering value is true until the Sound object has sufficient data loaded (bufferLength Flash Var)
The Sound Object is still in buffering mode (cause there is still not enough data loaded) and now randomly the Sound object gets bytesLoaded==bytesTotal (cause it doesn't know how long the mp3-livestream actually is.). This causes the positionHandler to dispatch the BUFFER_FULL Event, which in case triggers the state transition from BUFFERING to PLAYING.
Now again the bytesTotal value is higher than the bytesLoaded value and the Sound object still in buffering mode. And now, Bingo!, the positionHandler stops the channel.
So, this behaviour translates in:
If the given bufferLength Flashvar is longer than the actual mediafile to be played back. It will never be played.

2 possible solutions:

Set the bufferlength to 0 for mp3 livestreams, and never use a to high bufferlength for other audios
Delete the _channel.stop() line
Which sideeffects might the absence of the channel.stop() call have on other sound media? And what will be the effect of a zero bufferLength on a livestream player with a bad internet-connection?

Note: See TracTickets for help on using tickets.