Seeking towards end of video broken since 3.2.7 (!)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Finally found a way to reproduce. Please see 
http://flowplayer.blacktrash.org/test/fp3-bauhaus.html
2. Seek into the very last portion of the video, 1 to 3 seconds before end
3. Replay button appears to early, playback stops before last frame

What is the expected output? What do you see instead?
Expected: after seek playback stops at last frame, replay button appears over 
last frame (like in 3.2.7)
Instead: see 3. above

See also: https://github.com/flowplayer/work/issues/154

Original issue reported on code.google.com by blacktrashproduct on 20 Aug 2012 at 12:07

[GoogleCodeExporter]

Possible cause could be that the video's duration is _just_ under a full second 
mark. The displayed duration differs between 3.2.7 (39 sec) and 3.2.14 (40 
sec). See my diagnosis at the bottom of the demo page.

Original comment by blacktrashproduct on 20 Aug 2012 at 12:08

[GoogleCodeExporter]

freaky the time gets messed up, it buffers quick obviouslly so its seeking in 
the buffer, I get a time of 32 at 38 display after seeking to that position. 

Original comment by electrot...@gmail.com on 20 Aug 2012 at 2:49

[GoogleCodeExporter]

same deal with the first example, though its most likely it doesn't have the 
duration tracker code. Can you use one of the standard videos we're testing 
with perhaps or another vid ? Both display a time of 32 when seeking to 38. 

Original comment by electrot...@gmail.com on 20 Aug 2012 at 2:51

[GoogleCodeExporter]

[LOG] time 01:02:02.11 :: 
org.flowplayer.controller::NetStreamControllingStreamProvider : calling 
netStream.seek(38.33777679720537)
[LOG] time 01:02:02.33 :: org.flowplayer.controller::PlayTimeTracker : setting 
time to 38.33777679720537

Time reverts to 31.4 upon playback for some reason or another.  

[Number] 31.542
[LOG] time 01:02:02.292 :: org.flowplayer.controller::PlayTimeTracker : last 
time detected == 38.147

Times do not match, not sure where it's picking it up from looks like the seek 
time not the stream time. 

Original comment by electrot...@gmail.com on 20 Aug 2012 at 3:08

[GoogleCodeExporter]

private function seekTo(event:ClipEvent, seconds:Number):void {
            if (! durationTracker) createDurationTracker(clip);
            doSeekTo(event, seconds);
            durationTracker.time = seconds;
        }

this is the culprit expecting the times to be the same but in this case the 
stream time skips backwards. if its removed it will continue correctly until it 
reaches 38 then the end timer will begin. ???

Original comment by electrot...@gmail.com on 20 Aug 2012 at 3:27

[GoogleCodeExporter]

Therefore in the playtracker until 2 seconds has passed it will be the 
suggested seek time

if (_clip.type == ClipType.VIDEO || _clip.type == ClipType.API) {
                // this is a sanity check that we have played at least one second
                if (getTimer() - _startTime < 2000) {
                    return _timePassed;
                }
                return _controller.time;
            }

Therefore it will end early because its not obtaining the stream time which 
will only update after a seek completion, im not sure what its for, I thought 
it was for the beginning of playback only ?

Original comment by electrot...@gmail.com on 20 Aug 2012 at 3:33

[GoogleCodeExporter]

This whole function might need to be fixed up I think it also affects 
pseudostreaming

public function get time():Number {
            if (! _progressTimer) return 0;

            var timeNow:Number = getTimer();
            var _timePassed:Number = _storedTime + (timeNow - _startTime)/1000;

            if (_clip.type == ClipType.VIDEO || _clip.type == ClipType.API) {
                // this is a sanity check that we have played at least one second
                if (getTimer() - _startTime < 2000) {
                    return _timePassed;
                }
                return _controller.time;
            }

            if (! _progressTimer.running) return _storedTime;
            return _timePassed;
        }

Original comment by electrot...@gmail.com on 20 Aug 2012 at 3:35

[GoogleCodeExporter]

I don't think think that time update on a seek is needed it functions fine 
without it. 

Original comment by electrot...@gmail.com on 20 Aug 2012 at 3:38

[GoogleCodeExporter]

The first example 3.2.7 works perfectly fine: playhead always jumps back to 
beginning, and the first frame is displayed.

Original comment by blacktrashproduct on 20 Aug 2012 at 3:44