Thread: [Mplayerplug-in-devel] JavaScript concurrency issues & initialization delay
Brought to you by:
kdekorte
From: Forest B. <fo...@al...> - 2007-09-28 13:35:55
|
Hi, I am using JavaScript to control the plug-in. I find that JS locks up pret= ty 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 plu= g-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 =3D= =3D 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 --=20 Forest Bond http://www.alittletooquiet.net |
From: Kevin D. <kde...@gm...> - 2007-09-28 14:14:18
|
-----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----- |
From: Forest B. <fo...@al...> - 2007-09-28 15:46:06
Attachments:
logfile.txt
|
Hi Kevin, On Fri, Sep 28, 2007 at 08:14:08AM -0600, Kevin DeKorte wrote: > Forest Bond wrote: > > 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? > > 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. Thanks for spending time on this. 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 -- Forest Bond http://www.alittletooquiet.net |
From: Kevin D. <kde...@gm...> - 2007-09-28 15:52:12
|
-----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----- |
From: Forest B. <fo...@al...> - 2007-09-28 16:05:21
|
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 |
From: Forest B. <fo...@al...> - 2007-09-28 16:39:23
|
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 |