Re: Deadlock in mplayerplug-in 3.50, when 2 embeds want to swap their "src" content.

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

[email protected] wrote:
| <[email protected]>
| <[email protected]> <[email protected]>
| Message-ID: <[email protected]>
| X-Sender: [email protected]
| Received: from 62.233.177.6 [62.233.177.6] with HTTP/1.1 (POST); Thu,
29 May
| 	2008 16:05:30 +0200
| User-Agent: SKYHOST RC Webmail/0.1
| Content-Type: text/plain; charset="UTF-8"
| Content-Transfer-Encoding: 8bit
|
|> First of all mplayer normally forks itself, so seeing two processes is
|> normal. And I am using your code to test and although I think the
|> stability could be much improved in your code by checking the state of
|> the plugin so that your not slamming it so hard. Make sure it is in a
|> state that can be shutdown. While it is connecting is not a good time.
|> Have you looked at the DOCS/tech/javascript.txt file?
|
| Yeap. I know the javascript.txt and the playState issues etc., you are
| right... I only did the smallest possible example, which can reproduce the
| problem.
| And than, I was using it for further discussion...
|
|> Also, something else you might want to do is to use the media events
|> rather that a raw timer... such as onMediaComplete
|> <embed onMediaComplete="javascript:swapvideo();" name='video1' ....
|
| In my case (in one of my project) I have to synchronize everything with
| real timer, not with "media" size.
| I am using 2 embeds as a double buffer.. One typicaly is hidden (trying to
| prepare the content for next use) and second is covered..
| Everything is working like "slide show" when the material have to be
| switched quickly (without additional delay for buffering, launching
mplayer
| etc).
| And this example was used only for some kind of stretch/stress tests (I
| would be using it for 10-15 days instantly when the movies has 20min ->
| 2hours size, and switching the content after 1-2 hours, or per demand. but
| I didn't have a possibilites to spend 1 month with only testing it.)
|
|> I even tried your code on my newer version of mplayerplug-in named
|> gecko-mediaplayer and the code managed to crash it as well, mainly due
|> to the rapid switching of video without checking the state of the object.
|
| I've also checked on gecko-mediaplayer (which uses dbus for comunication
| with mplayer itselfs).
| Nevertheless I can use Stop(), Quit() method and be more aware of
playState
| but I still not sure if it fix my problem.
| The "rapid" switching doesn't have a meaning.. it was only the ugly and
| naughty test which can show me the possible problems in the future.
|
| ... Ofcourse I am really happy that you have helped me.. I really
| appreciate your knowledge and your time spended on fixing.
| Thanks for supporting me.
|
| BR
| Zbigniew

Sounds like you are in a pretty controlled environment. Something you my
try is adding 'nocache=1' to the embed statement so that the media is
loaded directly from disk and nothing is cached. Or you might try using
'filename' instead of 'src' since filenames are assumed to be local and
may help with this problem of switching media.

also you could try the mplayerplug-in.conf option 'nomediacache=1' and
see if that alters anything.

Normally I would not recommend those options for data coming from a
website, but in this case, they would be proper to use.

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

iD8DBQFIPsfu6w2kMH0L1dERAtCsAJ9DDliBBifeI/DksfPAr/NjBjP4lACff5R/
C1qhkA8b//Y9KYT4BYi7ny8=
=p9cE
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/