setPlaylist does not set event handlers (setClip does) - probably regression

[GoogleCodeExporter]

What steps will reproduce the problem?
1.
$f().setPlaylist([{
  url: 'video.flv',
  onStart: function () {
    console.log('onStart fired');
  }
}]);
2.
$f().setClip({
  url: 'video.flv',
  onStart: function () {
    console.log('onStart fired');
  }
});

What is the expected output? What do you see instead?

Expected: 1. should fire onBegin event - as 2. does for 1 clip
Instead: setPlaylist does not set event handlers

See issue7, issue100 etc. - as it was considered fixed, this is a regression.

Original issue reported on code.google.com by blacktrashproduct on 21 Jul 2012 at 4:48

[GoogleCodeExporter]

In theory you should also be able to do:

$f().play({
  url: 'video.flv',
  onStart: function () {
    console.log('onStart fired');
  }
});

but this does not work at all, neither with single clips, nor with a playlist.

There's nothing in the docs afaics which forbids or warns about events when 
using those methods.

See also: http://flowplayer.org/forum/3/101859

Original comment by blacktrashproduct on 21 Jul 2012 at 5:00

[GoogleCodeExporter]

setClip: function(clip) {
            each(clip, function(key, val) {
                if (typeof val == 'function') {
                    bind(listeners, key, val);
                    delete clip[key];
                } else if (key == 'onCuepoint'){
                    $f(wrapper).getCommonClip().onCuepoint(clip[key][0], clip[key][1]);
                }
            });
            self.setPlaylist([clip]);
            return self;
        },

this seems to be rebinding events or something before going to setPlaylist. 
calling setPlaylist directly only seems to trigger a playlist replace event. 

Original comment by dani...@electroteque.org on 21 Jul 2012 at 5:13

[GoogleCodeExporter]

Ah, ok, if it's on the javascript side, I can look into it myself. Thanks for 
pointing that out.

Original comment by blacktrashproduct on 21 Jul 2012 at 5:57

[GoogleCodeExporter]

thats ok, as for the event on play its likely need to be rebinded like this too 
or else it will resort back to the common clip objects listener clip: {} which 
is what setClip is replacing. If you add events on playlist items they are 
treated different most likely ? 

Original comment by dani...@electroteque.org on 21 Jul 2012 at 6:00

[GoogleCodeExporter]

My plan is to split out the function you quoted for reuse in setPlaylist 
looping over the clips and possibly for play(). The latter might need more care 
as it accepts both  a clip object and a playlist. But in theory at least I 
should be able to get there as setClip does the right thing[tm].

Original comment by blacktrashproduct on 21 Jul 2012 at 7:10

[GoogleCodeExporter]

I would double check that, set playlist is direct calls to flowplayer, event 
callbacks work within a playlist config correct ?

Original comment by electrot...@gmail.com on 24 Jul 2012 at 5:16

[GoogleCodeExporter]

Right now I'm out of my depth. setClip calls setPlaylist([clip]) but 
setPlaylist needs an extra definition, and there the waters get muddy.

Currently setPlaylist is just one of the API methods:

    // core API methods
    each(("pause,resume,mute,unmute,stop,toggle,seek,getStatus,getVolume,setVolume,getTime,isPaused,isPlaying,startBuffering,stopBuffering,isFullscreen,toggleFullscreen,reset,close,setPlaylist,addClip,playFeed,setKeyboardShortcutsEnabled,isKeyboardShortcutsEnabled").split(","),
        function() {
            var name = this;

etc. etc.

I can take it out of the core methods and basically get the correct result in 
the console - but not in the player. Which make me think that the problem might 
be in Flash after all?

Original comment by blacktrashproduct on 24 Jul 2012 at 9:37

[GoogleCodeExporter]

Yes because its passed directly to the player so it's in the core i'm afraid. 
I'll run some tests in regards to the rebinding of events ...

Original comment by electrot...@gmail.com on 25 Jul 2012 at 6:58

[GoogleCodeExporter]

From the JS point of view, and perhaps generally, there is some kind of 
recursion problem: API setPlaylist should actually call API setClip for each 
playlist item. But API setClip already calls setPlaylist. setPlaylist as core 
method does not support events? Do we have to go via something like update conf?

I wonder why and how this problem was declared fixed at least twice before.

Original comment by blacktrashproduct on 25 Jul 2012 at 8:08

[GoogleCodeExporter]

setclip is also calling setPlaylist also after yes, it goes to the playlist 
manager within the player itself. I'll run some tests shortly. 

Original comment by electrot...@gmail.com on 25 Jul 2012 at 8:39

[GoogleCodeExporter]

from the looks of it, just like setClip, everything added to setPlaylist binds 
event from the common clip object which is configured within clip: {}

Original comment by electrot...@gmail.com on 25 Jul 2012 at 4:23

[GoogleCodeExporter]

What was the resolution here, change in the js api level ? 

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

[GoogleCodeExporter]

It looks to me a js api level thing, the clip model does not have such event 
callback properties these are handled via event listeners in flash, the 
callbacks in the js are passed to the api to handle and rebind the common 
events. 

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

[GoogleCodeExporter]

That's what I suspected initially and was confident that the solution would be 
to call setClip for each clip in the playlist. But setClip itself calls 
setPlaylist([clip]) with a single item, thus we have a recursion issue.

I'm stuck as to why setClip must call setPlaylist, but if I omit the call the 
updated playlist is present in the API (can be queried successfully via the 
console) but does not propagate to the player.

I believe this must be because the API generated code _always_ features a 
playlist, even if you only configure a single clip. Some flaw in the handling 
of common clip and playlists?

Original comment by blacktrashproduct on 10 Aug 2012 at 12:22