You might want to try enabling inBufferSeek:
It might retain a bit longer. Also shortening your overall buffer length will reduce this issue to that amount of time.
Lastly, if it's just a "get around it" issue you might consider adding a "flag" of some sort to tell yourself when those events fire off. Then when a NetStream.Buffer.Flush fires, you set the flag to true to let yourself know it's emptying. Then when the NetStream.Play.Stop is fired off, you simply check that flag and if it's true you know you're in a flush and can run a ns.play() to make sure it plays after the seek.
Just remember to reset that flag when the buffer starts to fill or you do a seek so the NetStream.Play.Stop functions as normal.
I will give inBufferSeek a look.
I was looking at shortening the buffer, but the correct me if I am wrong... but after ready about setting buffer, is that it only appluies to videos from a URL. I should have added that the video files I am working with are for local playback.
As a workaround I did have a listener for the NetStream.Buffer.Flush event, and disabled the scrubber bar upon that event, as the problem only occurs if seeking took place after that event (i.e seeking after NetStream.Buffer.Flush fired - would cause it to fires several times). Most of the time it causes no problems, but if I test it by doing a large amount of seek requests in short succesion (again after NetStream.Buffer.Flush), suddent the NetStream.Play.Stop event gets fired (which I have a method for that event).
I will look into inBufferSeek to see if that helps.
Code operates at gigaflop speed so as long as you have the right conditions setting the right flag at the right time you should be able to avoid the issue. A HUGE amount of code can be completed in just a seconds worth of time. It might even be worth using a timer to put a "hold" on interaction for a single second before the user can proceed, only after the buffer emptying process begins so you don't bother normal seeks.
Playing off the local filesystem renders the buffer size moot. You are getting events for it however. You may as well set the buffer time to 0 and perhaps the event will only fire at the completion of the video.
Yeah, I think I am going to disable the scrubber bar after the Flush starts to avoid the issue (that seeking while the Flush is happening can sometimes result in a NetStream.Play.Stop event).
I tried setting the buffer size (ns.setBufferTime) but I get a warning "1061: Call to a possibly undefined method setBufferTime through a reference with static type flash.net:NetStream." I have no idea as to why....mmmmm
I traced out the buffersize while playing... and it's mostly at 1.4 seconds.... till it starts to flush, which is about 1.5 seconds before the end of the video. So I am thinking if I can set the buffer to zero (or .1 even) I would avoid the early Flush.
It's just bufferTime:
The default is actually already 0.1. It mentions you can set it to 0 for live streaming content but playback off a desktop is pretty much the same, so I'd probably set it to 0 anyhow.
Thanks again for you help..... my newbie status to AS3 is starting to show.... when I try ns.bufferTime(0); I get the error....
Severity and Description Path Resource Location Creation Time Id 1195: Attempted access of inaccessible method bufferTime through a reference with static type flash.net:NetStream. Streamworks Audio Video Player/src/actionScript actionScript.as line 24 1343765208891 877
Like I say... newbie
bufferTime is a property of a NetStream object, like .x and .y are properties of a MovieClip. You set properties like so:
myNetStream.bufferTime = 0;
A method is a function and only then do you use your syntax with parenthesis around arguments. The error description mentions it's not a method (because it's a property).
But it appears that hte buffer cannot be changed... still showing the same value for size even if I set it to 0.1
If it were being downloaded it'd work but in your situation I think 1.5 seconds worth of "seek disable" time for the buffer to empty isn't so bad .