mplayerplug-in for mozilla

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Forest Bond wrote:
> Hi,
> 
> I am using JavaScript to control the plug-in.  I find that JS locks up pretty
> good when I do things like this:
> 
> setInterval(ChannelNext, 5000);
> 
> ChannelNext changes the mplayer URL and calls Play().  Is it ok to call play
> methods from a separate thread?  The JS console in xulrunner becomes
> unresponsive when I do this.  As you are probably aware, JS doesn't provide a
> non-threaded delay capability, which makes timed loops difficult if the plug-in
> doesn't like threads.
> 
> There is another issue as well.  I am instantiating the plug-in by using
> document.createElement("object") and then filling in the necessary element
> attributes.  As expected, the browser creates a plug-in instance.  However,
> there appears to be a delay between instantiation and the time the plug-in
> becomes usable.  My first call to GetURL() fails because mplayer.GetURL ==
> undefined.  The actual length of time that this is the case appears to be
> somewhat unpredictable, although it has never been very long, although all of my
> media is local.
> 
> Thoughts?
> 
> Thanks,
> Forest

You might want to check the playState variable prior to switching
channels..

As far as calling methods from thread, I don't know if that is supported
or not. I don't know of anything that would prevent it, but threads are
always tricky.

Kevin


- --
Get my public GnuPG key from
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG/Qv+6w2kMH0L1dERAnlaAJ4vRnXKvqIzR8l5Ob3iEcJM5DQhYACffsmK
D7e6C8OKaEgdI/c3TH68/64=
=ZAmf
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Forest Bond wrote:
> I think it might just be a bug.  I've attached the logfile.
> 
> It's definitely not releated to setTimeout, because I hit the same issue with or
> without that call.  What's interesting is that I can make the problem go away by
> placing an alert(...) call after calling Stop().  I don't know why that would
> be.
> 
> My code is doing something like this:
> 
> --------------------------------------------------------------------------------
> if(mplayer.isplaying()) {
>   mplayer.Stop();
>   while(mplayer.playState != 1) {
>     ;
>   }
> }
> //alert('after Stop: ' + mplayer.playState);
> 
> mplayer.Open(new_url);
> 
> mplayer.Play();
> while(mplayer.playState != 3) {
>   ;
> }
> --------------------------------------------------------------------------------
> 
> As I mentioned above, uncommenting that alert(...) call makes the problem go
> away.  Very strange.
> 
> What do you think?
> 
> -Forest

I agree that it is really odd.. have you tried putting a "sleep" inside
the while loop? I'm not sure if javascript has that or not, but if so
then maybe there and then maybe one more after the loop is done. I think
100usec should be enough.

Kevin

- --
Get my public GnuPG key from
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG/SMi6w2kMH0L1dERAopvAJ9s2FAXdEFaWal2GHlz8/qVNasGBwCcChmv
ZLJgzJYi1xJ+3+ZHTiSDp8g=
=nuFo
-----END PGP SIGNATURE-----

Hi,

On Fri, Sep 28, 2007 at 09:52:02AM -0600, Kevin DeKorte wrote:
> Forest Bond wrote:
> > I think it might just be a bug.  I've attached the logfile.
> >=20
> > It's definitely not releated to setTimeout, because I hit the same issu=
e with or
> > without that call.  What's interesting is that I can make the problem g=
o away by
> > placing an alert(...) call after calling Stop().  I don't know why that=
 would
> > be.
> >=20
> > My code is doing something like this:
> >=20
> > -----------------------------------------------------------------------=
---------
> > if(mplayer.isplaying()) {
> >   mplayer.Stop();
> >   while(mplayer.playState !=3D 1) {
> >     ;
> >   }
> > }
> > //alert('after Stop: ' + mplayer.playState);
> >=20
> > mplayer.Open(new_url);
> >=20
> > mplayer.Play();
> > while(mplayer.playState !=3D 3) {
> >   ;
> > }
> > -----------------------------------------------------------------------=
---------
> >=20
> > As I mentioned above, uncommenting that alert(...) call makes the probl=
em go
> > away.  Very strange.
> >=20
> > What do you think?
> >=20
> > -Forest
>=20
> I agree that it is really odd.. have you tried putting a "sleep" inside
> the while loop? I'm not sure if javascript has that or not, but if so
> then maybe there and then maybe one more after the loop is done. I think
> 100usec should be enough.

No, JS doesn't have a sleep function...  I've thought about using a funky e=
vent
producer/consumer model, but I'd really rather not ...  Does the logfile gi=
ve
you any info?

-Forest
--=20
Forest Bond
http://www.alittletooquiet.net

On Fri, Sep 28, 2007 at 09:52:02AM -0600, Kevin DeKorte wrote:
> Forest Bond wrote:
> > I think it might just be a bug.  I've attached the logfile.
> >=20
> > It's definitely not releated to setTimeout, because I hit the same issu=
e with or
> > without that call.  What's interesting is that I can make the problem g=
o away by
> > placing an alert(...) call after calling Stop().  I don't know why that=
 would
> > be.
> >=20
> > My code is doing something like this:
> >=20
> > -----------------------------------------------------------------------=
---------
> > if(mplayer.isplaying()) {
> >   mplayer.Stop();
> >   while(mplayer.playState !=3D 1) {
> >     ;
> >   }
> > }
> > //alert('after Stop: ' + mplayer.playState);
> >=20
> > mplayer.Open(new_url);
> >=20
> > mplayer.Play();
> > while(mplayer.playState !=3D 3) {
> >   ;
> > }
> > -----------------------------------------------------------------------=
---------
> >=20
> > As I mentioned above, uncommenting that alert(...) call makes the probl=
em go
> > away.  Very strange.
> >=20
> > What do you think?
> >=20
> > -Forest
>=20
> I agree that it is really odd.. have you tried putting a "sleep" inside
> the while loop? I'm not sure if javascript has that or not, but if so
> then maybe there and then maybe one more after the loop is done. I think
> 100usec should be enough.

This seems to do the trick, although I'm not entirely happy with it because=
 it
introduces all kinds of race conditions.  I'll probably have to implement an
instruction queue.

---------------------------------------------------------------------------=
-----
if(mplayer.isplaying()) {
  mplayer.Stop();
  while(mplayer.playState !=3D 1) {
    ;
  }
}

x =3D function() {
  mplayer.Open(new_url);

  mplayer.Play();
  while(mplayer.playState !=3D 3) {
    ;
  }
}

setTimeout(x, 100);
---------------------------------------------------------------------------=
-----

-Forest
--=20
Forest Bond
http://www.alittletooquiet.net