play and seek: no seek

[GoogleCodeExporter]

$f().play(arg) now works, but
$f().play(clip); $f().seek(); does not.

http://flowplayer.blacktrash.org/dev/play-seek.html
(using latest Build time: December 25 2011 09:58 AM GMT)

It looks like seek() is not queued for execution (like in a callback). So one 
has to resort to ugly and unreliable workarounds like:

$f().play(clip);
setTimeout(function () {
  $f().seek(100);
}, 1000);

Original issue reported on code.google.com by blacktrashproduct on 2 Jan 2012 at 10:41

[GoogleCodeExporter]

What is at least an issue is that the seek fails *silently*.

Via javascript the best way to wait for the clip is to store a potential seek 
position in a global variable:

seekpos = 0;

and then configure the onStart event like so:

clip: {
  onStart: function () {
    if (seekpos) {
      this.seek(seekpos);
      seekpos = 0;
    }
  }
}

and instead of $f().play(clip); $f().seek(100); do:

seekpos = 100; $f().play(clip);

It makes sense that we can only seek in a clip which has already started, but 
it's not obvious api-wise that and when $f().seek() fails (silently).

Original comment by blacktrashproduct on 2 Jan 2012 at 11:49

[GoogleCodeExporter]

Do a seek once you get metadata, spoken about this before ;) let me know. 

Original comment by dani...@electroteque.org on 3 Jan 2012 at 2:06

[GoogleCodeExporter]

Confirming this is messed up also. something to do with rtmp for sure. 

Original comment by dani...@electroteque.org on 5 Jan 2012 at 4:40

[GoogleCodeExporter]

It triggers onMetaData when seeking within onMetaData so has to be called once 
only. will try another way. 

Original comment by dani...@electroteque.org on 5 Jan 2012 at 11:33

[GoogleCodeExporter]

oh I get it you want to call asynchronously. This is likely a feature request

$f().play(clip, 60);

or 

$f().play(clip);

cue

$f().seek(60);

Original comment by electrot...@gmail.com on 6 Jan 2012 at 3:31

[GoogleCodeExporter]

Here is the problem, you are trying to do this asyncrhonously, which will not 
work, you call play, then call seek, while its closing the previous stream and 
changing to the new one,  during this change the seek request happens, then the 
stream is closed. It needs to be done synchronously. 

So either do them in the event methods which works fine in onStart, or create a 
feature request to have ti done for you within the api method 

$f().play(clip, 60);

or 

$f().play({ url: "theurl", seek: 60 }); I think that is a cleaner solution ! 

Original comment by electrot...@gmail.com on 6 Jan 2012 at 3:44

[GoogleCodeExporter]

I'll set this up as a feature request for now. 

Original comment by electrot...@gmail.com on 6 Jan 2012 at 3:44

[GoogleCodeExporter]

Original comment by electrot...@gmail.com on 6 Jan 2012 at 3:45

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

has this been resolved?

Original comment by f...@b3dmultitech.com on 2 Apr 2012 at 6:31

[GoogleCodeExporter]

Hi there, its been setup as a feature request

Original comment by dani...@electroteque.org on 2 Apr 2012 at 6:57

[GoogleCodeExporter]

I think we should concentrate on getting onStart to work as reliable as 
possible - which will be tricky enough. It can be argued that onStart is 
exactly the event to use to avoid the race condition between play() and seek().

Original comment by blacktrashproduct on 18 Apr 2012 at 12:08

[GoogleCodeExporter]

Just confirming there is a 200ms limitation in the core api seek method which 
the plugins call upon, I'm not sure why its there, this is preventing seeking 
directly on a stream time of 0. 

I don't even think onStart is a clean solution because it needs flags to 
prevent a stack error. There should still be a possible way in the api to 
trigger to play a clip and seek to a particular position, as it needs to happen 
in a synchronise fashion it has to happen internally. 

http://code.google.com/p/flowplayer-core/source/browse/flowplayer/trunk/src/acti
onscript/org/flowplayer/controller/NetStreamControllingStreamProvider.as#506

Original comment by dani...@electroteque.org on 18 Apr 2012 at 3:18

[GoogleCodeExporter]

does anybody know how to fix it?

Original comment by kabindra...@gmail.com on 31 Aug 2012 at 7:47

[GoogleCodeExporter]

Is there any fix?

Original comment by pianon...@gmail.com on 4 Dec 2013 at 3:32