On 14/11/12 14:44, Andrew Z wrote:
> David,
> i'm using the one from adobe. See here:
> yum repolist
> <skip>
> repo id repo name status
> Dropbox Dropbox Repository 4
> adobe-linux-x86_64 Adobe Systems Incorporated 2
>
> installing:
> flash-plugin x86_64 11.2.202.251-release adobe-linux-x86_64 6.9 M
>
> and it's the one i'm bi%% heartlessly about.
> can you try this one
> (http://www.youtube.com/watch?v=NBO9z4Hy9rI&feature=share&list=PLB7667BC178F2658F
> <http://www.youtube.com/watch?v=NBO9z4Hy9rI&feature=share&list=PLB7667BC178F2658F>)
> in HD full screen for say 15 minutes? Works fine when in anything but full
> screen for me.
I'm using these packages:
flash-plugin-11.2.202.251-release.x86_64
firefox-10.0.10-1.el6_3.x86_64
This is an up-to-date SL6.3 x86_64 system with sl and sl6x repos enabled.
I tested that youtube video in fullscreen and it ran without any issues for
about 30 minutes in 480p mode with 1920x1200 resolution. But with 720p mode,
it halts completely (audio and video) on my laptop within 5 minutes - but only
with certain circumstances. I then found this error in
~/.xsession-errors:
WARNING: pipe error (67): Connection reset by peer: file
/builddir/build/BUILD/xulrunner-10.0.10/mozilla-esr10/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
line 419
Checking it with gdb, attaching to the xulrunner-2/plugin-container process, I
see something which looks like a locking issue - probably caused buffer
underflows due to network issues.
(gdb) bt
#0 __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1 0x00007fcebdc463be in _L_lock_995 () from /lib64/libpthread.so.0
#2 0x00007fcebdc46326 in __pthread_mutex_lock (mutex=0x7fcebcc0dd70) at
pthread_mutex_lock.c:101
#3 0x0000003761c23f79 in PR_Lock (lock=0x7fcebcc0dd70) at
../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:174
#4 0x0000003e12982f56 in Lock (this=0x7fcebcc1b840) at
../../dist/include/mozilla/Mutex.h:106
#5 Lock (this=0x7fcebcc1b840) at ../../dist/include/mozilla/Monitor.h:70
#6 MonitorAutoLock (this=0x7fcebcc1b840) at
../../dist/include/mozilla/Monitor.h:125
#7 mozilla::ipc::RPCChannel::OnMaybeDequeueOne (this=0x7fcebcc1b840) at
/usr/src/debug/xulrunner-10.0.10/mozilla-esr10/ipc/glue/RPCChannel.cpp:402
#8 0x0000003e12a308b2 in MessageLoop::RunTask (this=0x7fffb048c200,
task=0x7fceaefae6d0) at
/usr/src/debug/xulrunner-10.0.10/mozilla-esr10/ipc/chromium/src/base/message_loop.cc:318
#9 0x0000003e12a32bd6 in MessageLoop::DeferOrRunPendingTask (this=<value
optimized out>, pending_task=<value optimized out>)
at
/usr/src/debug/xulrunner-10.0.10/mozilla-esr10/ipc/chromium/src/base/message_loop.cc:326
#10 0x0000003e12a32fa7 in MessageLoop::DoWork (this=0x7fffb048c200) at
/usr/src/debug/xulrunner-10.0.10/mozilla-esr10/ipc/chromium/src/base/message_loop.cc:426
#11 0x0000003e12a4352a in base::MessagePumpForUI::RunWithDispatcher
(this=0x7fcebcc300a0, delegate=<value optimized out>, dispatcher=<value
optimized out>)
at
/usr/src/debug/xulrunner-10.0.10/mozilla-esr10/ipc/chromium/src/base/message_pump_glib.cc:199
#12 0x0000003e12a30852 in RunHandler (this=<value optimized out>) at
/usr/src/debug/xulrunner-10.0.10/mozilla-esr10/ipc/chromium/src/base/message_loop.cc:201
#13 MessageLoop::Run (this=<value optimized out>) at
/usr/src/debug/xulrunner-10.0.10/mozilla-esr10/ipc/chromium/src/base/message_loop.cc:175
#14 0x0000003e11ff90fd in XRE_InitChildProcess (aArgc=6, aArgv=<value
optimized out>, aProcess=<value optimized out>)
at
/usr/src/debug/xulrunner-10.0.10/mozilla-esr10/toolkit/xre/nsEmbedFunctions.cpp:524
#15 0x0000000000401314 in main (argc=7, argv=<value optimized out>) at
/usr/src/debug/xulrunner-10.0.10/mozilla-esr10/ipc/app/MozillaRuntimeMain.cpp:81
(gdb)
I also noticed that if youtube could cache up more data (you know the grey
shading in front of the red progress marker) ... This issue did not happen.
So I'd expect there to be an issue in xulrunner, not the flash plug-in itself
and only when there is a lag in the data stream.
In 480p mode I saw buffer-underflows as well - but those times it would just
lag for less than 0.5 second and then continue.
kind regards,
David Sommerseth
> On Wed, Nov 14, 2012 at 5:23 AM, David Sommerseth
> <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>
> On 14/11/12 10:58, Todd And Margo Chester wrote:
> > On 11/13/2012 08:57 PM, Andrew Z wrote:
> >> hello,
> >> is there an alternative for ( lots of grumpy swearing omitted ) flash
> >> plugin in FF? with the latest 11.2.202.251 x86 release the HD videos in
> >> full-screen a crashing.
> >> [bitching on]
> >> first i deal with an invasion of Avatars - "the blue people" and now
> >> $$$ thing won't even play for longer than 4 minutes in full screen
> >> [bitching off]
> >
> >
> > Hi Andrew,
> >
> > Oh good. I get to help someone for a change.
> >
> > The recent Flash player is a DISASTER. Can't seem to get
> > anyone to fix it either.
> >
> > Back off to flash-plugin-11.1.102.63-0.1.el6.rf.x86_64.rpm
> > (or 32 bit, if that's what you are running) and turn off auto
> > updates.
> >
> >
> http://apt.sw.be/redhat/el6/en/x86_64/dag/RPMS/flash-plugin-11.1.102.63-0.1.el6.rf.x86_64.rpm
> >
> >
> > # rpm -e flash-plugin
> > # rpm -ivh flash-plugin-11.1.102.63-0.1.el6.rf.x86_64.rpm
> >
>
> Seriously, what's wrong with using the official Adobe Flash player? I
> see you're using one from the rpmforge/fusion repo.
>
> 1. Go here: http://get.adobe.com/flashplayer/
> 2. Select "YUM for Linux" and click download.
> 3. Install that RPM
> 4. as root: yum erase flash-*
> 5. Disable all those extra elrepo, atrpms, rpmfusion/rpmforge
> repositories (look inside the files in /etc/yum.repos.d/ )
> 5. as root: yum install flash-plugin
> 6. Enjoy a more reliable flash.
>
> This way you get no 32bit nonsense on 64bit installations. And you get
> something which works quite more reliable. I'm using the Adobe Flash
> player (64bit) on a couple of my private laptops. And I'm watching
> fullscreen TV broadcasts in hi quality resolution (3.5Mbit/s streams)
> scaled up to my 1920x1200 display ... and if there are issues, that's
> been related to not getting the needed bandwidth.
>
> I've mostly had just troubles with those additional repos, so I only
> enable them when it's needed. Otherwise, SL repos + EPEL repos gives a
> really stable and reliable systems At least, that's been my experience.
>
>
> kind regards,
>
> David Sommerseth
>
>
|
