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

<[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


-------------------------------------------------------------------------
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/