audio: playhead does not move on provider switch with short cached mp3

[GoogleCodeExporter]

What steps will reproduce the problem?
1. http://flowplayer.blacktrash.org/test/shortaudio.html - 1st mp3 (provider: 
rtmp), 2nd _short_ (12 secs) mp3 over http (provider: audio)
2. jump to 2nd clip
3. when 2nd clip has buffered entirely, jump back to 1st clip
4. move playhead to end of 1st clip, and wait for playlist transition to 2nd 
clip
5. 2nd clip starts playing, playhead sometimes jumps back and forth, but in the 
end stays at beginning of scrubber during playback

What is the expected output? What do you see instead?
Expected: playhead moves during playback
Instead: playhead stays fixed

This does not happen when there is no provider switch.

I checked the mp3, it's CBR - even though that should not matter over http.

Setting provider: "http" for the second clip exhibits the same behavior.

Original issue reported on code.google.com by blacktrashproduct on 2 Aug 2012 at 1:12

[GoogleCodeExporter]

Note: you sometimes have to redo steps 4. and 5. several times to trigger the 
problem.

Original comment by blacktrashproduct on 2 Aug 2012 at 1:17

[GoogleCodeExporter]

Oh, and once the playhead has jumped back, the play button goes from pause to 
play during playback. Sometimes also the playback simply stops.

Original comment by blacktrashproduct on 2 Aug 2012 at 1:20

[GoogleCodeExporter]

Error #2044: Unhandled AsyncErrorEvent:. text=Error #2095: flash.net.NetStream 
was unable to invoke callback onID3. error=ReferenceError: Error #1069: 
Property onID3 not found on org.flowplayer.rtmp.RTMPStreamProvider and there is 
no default value.
    at org.flowplayer.rtmp::RTMPStreamProvider/startStream()
    at org.flowplayer.rtmp::RTMPStreamProvider/doLoad()
    at org.flowplayer.controller::NetStreamControllingStreamProvider/start()
    at org.flowplayer.controller::NetStreamControllingStreamProvider/onConnectionSuccess()
    at org.flowplayer.controller::ParallelRTMPConnectionProvider/onConnectorSuccess()
    at org.flowplayer.controller::ParallelRTMPConnector/_onConnectionStatus()

This may be of interest , wierd one

Original comment by dani...@electroteque.org on 6 Aug 2012 at 3:55

[GoogleCodeExporter]

what streaming server is this perhaps it needs to deal with this differently ??

Original comment by dani...@electroteque.org on 6 Aug 2012 at 4:01

[GoogleCodeExporter]

two different audio providers :O

Original comment by dani...@electroteque.org on 6 Aug 2012 at 4:04

[GoogleCodeExporter]

this particular server isn't responding to the standard id3: request. dont know 
anything about it. 

Original comment by dani...@electroteque.org on 6 Aug 2012 at 4:13

[GoogleCodeExporter]

first error is fixed up but now I get this for that file

TypeError: Error #1009: Cannot access a property or method of a null object 
reference.
    at org.flowplayer.audio::AudioProvider/pause()
    at org.flowplayer.audio::AudioProvider/onId3()

Original comment by dani...@electroteque.org on 6 Aug 2012 at 4:24

[GoogleCodeExporter]

The correct auto buffer config is

autoPlay: false,
autoBuffering: true

Issues with auto buffering ..

Original comment by dani...@electroteque.org on 6 Aug 2012 at 4:41

[GoogleCodeExporter]

fixed some issues but this auto buffering business on one file, and mixture of 
rtmp and http provides doesn't seem good. This rtmp server seems very funky 
need to know what it is because its sending odd statuses which is triggering 
complete events therefore showing the replay button. The audio plugin is 
causing the playlist to replay just that one file. 

Original comment by dani...@electroteque.org on 6 Aug 2012 at 5:03

[GoogleCodeExporter]

I've updated
http://flowplayer.blacktrash.org/test/shortaudio.html
to use cloudfront as rtmp provider and can still reproduce it.

There is no autoPlay: false, autoBuffering: true involved here. Where did you 
see that? Both properties are not configured, i.e. at their default values.

Original comment by blacktrashproduct on 6 Aug 2012 at 6:11

[GoogleCodeExporter]

I've updated
http://flowplayer.blacktrash.org/test/shortaudio.html
to use cloudfront as rtmp provider and can still reproduce it.

There is no autoPlay: false, autoBuffering: true involved here. Where did you 
see that? Both properties are not configured, i.e. at their default values.

Original comment by blacktrashproduct on 6 Aug 2012 at 6:11

[GoogleCodeExporter]

The config had autobuffering on the http clip ;) I don't quite understand but 
it was trying to pause before a sound channel was open quite possibly because 
how insanely tiny the file was. I don't quite understand but the rtmp audio 
changes were working and now not ? Please hold while I upload some changes 
there is multiple issues here. 

Original comment by electrot...@gmail.com on 7 Aug 2012 at 2:39

[GoogleCodeExporter]

Your cloudfront demo is fine, i'l concentrate on the audio plugin first, it 
replays the last file in the playlist. 

Original comment by electrot...@gmail.com on 9 Aug 2012 at 9:04

[GoogleCodeExporter]

No, it's not fine. I was just able to reproduce it again (updated to latest 
versions). As I said, you might have to redo steps 4 and 5. I can _always_ 
reproduce it sooner or later.

Original comment by blacktrashproduct on 9 Aug 2012 at 10:42

[GoogleCodeExporter]

Ive narrowed down the problem with the audio plugin is flagged as not ended 
therefore won't rewind the playlist, just trying to figure it out. 

Original comment by electrot...@gmail.com on 9 Aug 2012 at 11:08

[GoogleCodeExporter]

this is bigger than I was expecting, don't try and debug on your end for now 
please. It's not rewinding playlists :O

Original comment by electrot...@gmail.com on 9 Aug 2012 at 11:28

[GoogleCodeExporter]

I can't continue on this until I correct the playlist, its now showing the 
replay button on the first clip with two rtmp clips in a playlist.  it's 
related to this issue so i wont setup a new ticket. 

Original comment by electrot...@gmail.com on 9 Aug 2012 at 11:58

[GoogleCodeExporter]

it's while auto buffering is configured on the items. I'll look at that later. 

Original comment by electrot...@gmail.com on 9 Aug 2012 at 12:09

[GoogleCodeExporter]

Well the auto buffering thing was part of the issue, the rtmp server is 
triggering a complete status very late and causing the player to complete while 
it's loading the next clip, it still plays but the replay button appears. with 
auto buffering enabled it will replay the last clip, without it configured the 
audio items play through and replay fine. 

Original comment by electrot...@gmail.com on 9 Aug 2012 at 12:17

[GoogleCodeExporter]

http://flowplayer.blacktrash.org/test/shortaudio.html never had autoBuffering 
configured - but perhaps you're talking about something else.

Original comment by blacktrashproduct on 9 Aug 2012 at 1:10

[GoogleCodeExporter]

yes autobuffering was configured on the original demo there is a problem there 
repeating playlists but thats for another time. 

rtmp plugin and its stream events is still active while moving to the audio 
plugin and dispatches a finish event which is why the replay button appears the 
audio is playing though.  I don't see any events calling stop on the previous 
stream provider its tough to debug ;) Its quite possibly because the audio 
plugin has no such netstream so it keeps the rtmp plugin one active. ive never 
tested rtmp streams with http streams or have seen a ticket for such :) have to 
leave it for today. 

Original comment by electrot...@gmail.com on 9 Aug 2012 at 2:41

[GoogleCodeExporter]

Yes ok the state is set to silent therefore the stop event is not set on the 
rtmp provider when going to new items, therefore leaving its stream and 
connection open. This might also be a problem going to other stream providers 
in a playlist perhaps and needs to be tested. 

Original comment by electrot...@gmail.com on 9 Aug 2012 at 5:26

[GoogleCodeExporter]

There is a possible solution here by first flagging if the currently loading 
clip in the playlist is the one previouslly loaded on the rtmp plugin so it 
doesn't fire a finish event when the buffer empties, its possibly not best 
changing how the playlist progression works. 

Original comment by electrot...@gmail.com on 10 Aug 2012 at 3:02

[GoogleCodeExporter]

Still no good, it will trigger the player to be in a buffering state, the only 
other way is to close the stream if the provider is not the same. 

Original comment by electrot...@gmail.com on 10 Aug 2012 at 4:22

[GoogleCodeExporter]

https://dl.dropbox.com/u/3394987/flowplayer.rtmp-3.2.11.zip
https://dl.dropbox.com/u/3394987/flowplayer.commercial-3.2.13.zip

Please try this its by no means complete, it will fully close the rtmp stream 
when moving to the next item. it should perhaps just close the stream and not 
the connection when there is an item after so meeting halfway. Needs to be done 
on the playlist controller though as a silent flag will not cause any stop 
method. 

Original comment by electrot...@gmail.com on 10 Aug 2012 at 7:53

[GoogleCodeExporter]

when you have a moment let me know if the rtmp fix and the playlist state hack 
helps. ill commit the rtmp fix after that. 

Original comment by electrot...@gmail.com on 13 Aug 2012 at 2:10

[GoogleCodeExporter]

https://dl.dropbox.com/u/3394987/flowplayer.commercial-3.2.14.zip
https://dl.dropbox.com/u/3394987/flowplayer.audio-3.2.10.zip
https://dl.dropbox.com/u/3394987/flowplayer.rtmp-3.2.11.zip

Please try these, i had to find an unobtrusive way to deal with this because it 
would require big changes to the stream provider api therefore cause a 
compatibility break and all streaming plugins require to be updated with the 
core ;) 

It will close the stream when the clip has finished if the next clip is not the 
same provider. Doing so actually causes the playlist to replay correctly now !  
The issue when replaying previously is because the audioprovider is a seperate 
stream provider , when rtmp begins to replay it think it's replaying itself 
because it hasn't being reset, so that has been fixed also. It should start a 
new stream, and not attempt a new connection. The issue I found if i tried to 
close the connection is when the audio provider attempted to manipulate the 
volume, it's also trying to set the volume on the previous provider's netstream 
and with no connection set will break aggh. 

The solution now is rtmp's stream will close and no more events will fire when 
going to the audio plugin. Needs some through testing through between different 
providers ...

Original comment by electrot...@gmail.com on 25 Aug 2012 at 2:54

[GoogleCodeExporter]

and only some fixes have been committed on rtmp. quite a few changes for 
problems in the core are uncommitted until tested ;)

Original comment by electrot...@gmail.com on 25 Aug 2012 at 2:55

[GoogleCodeExporter]

this has been committed but requires some testing. 

Original comment by electrot...@gmail.com on 4 Sep 2012 at 10:50