Kevin DeKorte wrote:
> Giuseppe Ghib=F2 wrote:
>> I've strong problems with it, especially with latest mplayer(s)
>> [I tried mplayer 1.0-1pre8, as well as 1.0-1rc1:
> Strong problems hum... Send more bug reports then. The more reports, th=
> more can be fixed.
yep. Although with strong I meant that the "browser" became unresponsive.=
>> For instance on this:
> With today's CVS code this site works perfectly for me. I have fixed a
> problem with the xv output (which is due to a change put in mplayer 1.p=
>> I get that it starts mplayer, but then the box where it
>> should embed the windows remain black, and everything
>> is blocked. What are blocked are also the
>> "back button" and the "blosing tab button". This happens in either fir=
>> as well as in seamonkey 1.0.5. Basically it's like the brower is "free=
>> and it's not responsive until handly I don't kill the
>> mplayer process. What is strange is also that if I run manually
>> the command from the shell (which is the same command called from mpla=
>> mplayer -wid 0xe003e4 -vf scale=3D420:-3 -vo xv,x11 -zoom -ao esd,alsa=
,oss,arts,null -osdlevel 3
>> -nojoystick -noconsolecontrols -cookies -softvol -slave -user-agent NS=
>> -cache 1024 http://mediaserver.kataweb.it/tgrep/reuters/modaturistispa=
> Sounds like the xv problem. Try again with current CVS. Although, you
> should have tested with just x11 just to sure there was a problem.
I was already using the latest CVS version.
The .src.rpm file that I plan to use as candidate for Cooker, once the of=
release will be released, is this one:
>> it plays correctly in the browser window.
Well, indeed the first time you run it, starting the browser
for the first time after a boot, it works, but next times it's
blocked, several mplayer process are launched each time and the browser
remain blocked (i.e. back button, or closing window button don't
respond) until the mplayer process(es) is(are) killed.
This happens for any of the video of the site:
Note that I've also cleaned either the: a) browser cache,
b) .mplayer dir, c) the .mozilla/pluginreg.dat
as well as .mozilla/firefox/pluginreg.dat. A similar behaviour is
achieved also for this site:
and then clicking in any of the "350K" links (it needs also
the FlashPlayer9, though the videos are played under mplayer).
Note that the last line of verbose output I got on console, using debug=3D=
READ: [AO ESD] latency: [server: 0.56s, net: 0.00s] (adjust 0.56s)
READ: AO: [esd] 44100Hz 1ch s16le (2 bytes per sample)
READ: Starting playback...
Setting file mode back to blocking
and then there is only the black video frame (dunno whether
mplayer is placed in "pause" or something like that, is there
a way to find what it is happening to it under these conditions?)
Effectively switching to -vo x11 make things better, although
the window positioning and the window frame sizes sound to be slightly
different, for instance the black stripes at each side of the
video box sound to be bigger in x11 than in xv. Note that video
card is nvidia, but I get a similar behaviour also under a Matrox
G550, although on another machine.
What I don't understand is why if I run the mplayer instance
from console using exactly the same mplayerplugin command line (with "xv"
enabled) as well as with the same "-wid" argument, the mplayer is not blo=
as it is when it's called from the plugin.
>> Also I see a new "AUDIO" button (sound it's a MUTE button) near the "F=
>> button, but pressing it, doesn't happen anything.
> Ah, you're not using it right. There is currently no click event. Spin
> your mouse wheel up and down and you'll see that it works. Eventually, =
> will switch the click to do something, but nothing at the moment.
Effectively you are right and using the wheel would work. But I also wond=
er how to
do when the wheel is not available (as usually on notebooks).
Maybe you can just add two tiny buttons at the side of the volume button:
pressing on [<] will lower the volume, while pressing on [>] will raise i=
> The more problems identified before release, the better the release wil=