This is a message.

Forum user: andybisson

Basic information

Registered Mar 10, 2009
Last login Jun 17, 2009
Forum posts 12
Direct URL http://www.flowplayer.org/forum/users/9048

Latest forum posts

Posts:

Registered:

One solution

Posted: Jun 17, 2009

It would appear that a solution to this problem is to start playback with the player.toggle() call. Thereafter the pause/resume method works as expected.

Andy

Posts:

Registered:

Transport control from a streaming plugin

Posted: Jun 17, 2009

Is there an approved method of firing transport functions from within a streaming plugin? I am currently starting a player in 'pause after start' mode and subsequently calling
resume(new ClipEvent(ClipEventType.RESUME));
in order to begin playback. This has the desired effect and the transport button becomes a pause symbol. However, when the transport button is then manually operated it issues a resume. Subsequent manual operations work as intended.

Thanks,
Andy

Posts:

Registered:

Update

Posted: May 26, 2009

I have now found more info about error 2082 and it is being thrown by the LocalConnection. I could fix this if I could receive some notification that the player is closing (and then explicitly close the connection.) Is it possible to receive notification of closing? (I am not particularly familiar with ActionScript)

Andy

Posts:

Registered:

Flash Error 2082 in IE7

Posted: May 26, 2009

I have a Flash plugin that allows two flowplayer instances to synchronise by means of back to back LocalConnections. In this way I can ensure that pauses for buffering are synced and only one set of transport controls is required. I can get this to work in Chrome, Firefox and IE8 but not in IE7. The failure is an error 2082 and the player cannot load the media.

Other information
An example can be seen at http://staging.icmfreedom.com/our_beta/10521
The players are embedded in an Ext.js form which can be closed without closing the browser window or navigating away.
Once an error 2082 occurs it recurs until the browser is closed.
Closing the player and opening another video from the tree is a reliable method of provoking the error.

I believe the bug is due to something being left open as the problem sometimes goes away if you leave it alone for 10 minutes. I guess something is getting garbage collected in the interim. Is there a way to get an explicit on-close notification in my plugin so that I can close my LocalConnection objects as these seem to be indirectly responsible for the failure?

Thanks,
Andy

Posts:

Registered:

» » » » Amazon S3 query strings still dont work in 3.0.4-dev flowplayer

Posted: Apr 20, 2009

Thanks
I hadn't found that post but it completely resolves my problem.

Posts:

Registered:

» » Amazon S3 query strings still dont work in 3.0.4-dev flowplayer

Posted: Apr 20, 2009

Sorry, I forgot to mention that newer version don't work either. The reason I specifically mention 3.0.4-dev is that this was previously given as a version in which query strings worked http://flowplayer.org/forum/8/14016

Thanks,
Andy

Posts:

Registered:

Amazon S3 query strings still dont work in 3.0.4-dev flowplayer

Posted: Apr 20, 2009

Amazon S3 signed urls do not work in the 3.0.4-dev flowplayer.
The bug is very easy to demonstrate -
Download the 3.0.4-dev release.
Edit example/index.html to modify the url as follows:

 href="http://blip.tv/file/get/KimAronson-TwentySeconds73213.flv?AWSAccessKeyId=3DJR0A1W8HSUIN6JXRG2&Signature=4gXH9xgQrmbw5xeZqwjIi6ZX33g=&Expires=1240228015"

The video no longer plays.

Using this URL directly in a browser works fine so the issue is not at blip.tv

Posts:

Registered:

resolved

Posted: Mar 18, 2009

plugins object was sometimes getting trashed later. Oops!

Posts:

Registered:

Streaming plugin not loading from config

Posted: Mar 18, 2009

I am following the YouTube example and have created a player synchronisation plugin. I configure two instances using the following function to create the config:

  function createConfig(id, url) {
    var config = { 
      log: { level: 'info' },
      plugins: { 
        synchronised: {
          url: 'flowplayer.synchronised.swf' 
         } 
      },      
      clip: {
        scaling: 'fit',
        url: url, 
        autoPlay: true, 
        autoBuffering: true,
        bufferLength: 10,
        provider: 'synchronised', 
        synch: true,                // run in synchronised mode
        master: id === 2            // set as synch master
      }
    };

I get the error "The provider specified in this clip is not loaded" twice (once per player) and yet the second player does load and play.
Log messages in my plugin demonstrate that it has indeed loaded and is playing the clip.
Why? :(

Thanks,
Andy

Posts:

Registered:

Correction...

Posted: Mar 17, 2009

Ok, this doesn't work.
The correct fix is to escape all of the " entities with backslashes in the definitions of something-or-other-quoted.

I would give an example but this comment editor doesn't seem to want me to.

Posts:

Registered:

» » » » » » » » » Compiling instructions

Posted: Mar 16, 2009

A bit late but this fixes the build without hacking the source files:
Change line 145 of build.xml to

<arg line="-define+=CONFIG::versionStatus,'${version-status-quoted}';" />

The extra semi-colon seems to fix it. No idea why - just following a suggestion found elsewhere. It seems to be an ActionScript bug.

Posts:

Registered:

Initial onBufferFull event?

Posted: Mar 10, 2009

I want to start high and low bandwidth videos together in the presence of buffering delays. I am trying to capture the initial onBufferFull events so that I can then start both players when both events have arrived. This event only seems to occur after the player has been in the play state. Calling startBuffering() or setting autoBuffering in the config does not fire the event.
Is this supposed to work? If not, is there another way to achieve the same end? Starting and then immediately pausing the player seems to work but is not very pretty to look at. I guess I could hide() the player during the initial blip but I can't help thinking that there must be a better way.

Thanks,
Andy