Using Netflix on netflix-desktop results in a runaway process for Silverlight' s plugin-container

[Adam Rigg]

With a bitrate capped at 1050 through Netflix Quality Settings, the system becomes unresponsive after about 20 minutes of watching Netflix. When the Silverlight process runs away, CPU usage approaches 100% with frame rates dropping to below 10 and gradually falling to around 0 over the course of about a minute. Audio playback remains relatively unaffected (with only a few short 0.5-2 sec dropouts if the situation is allowed to degrade without killing plugin-container), but player controls, Firefox controls and the X11 GUI controls become unresponsive. Killing the plugin-container process restores both X11 and WINE to a responsive state, but playback cannot be resumed right away without falling back into the same condition. For the player to work for another 20-30 minutes, I have to either wait a few minutes or restart X11. Restarting Firefox, wine-compholio and X11 is not necessary with a wait of about 5 minutes.

The onset of the issue happens much more quickly with bitrates above 1050, but is not much different until I drop the bitrate below 560. Below 560, CPU usage continues to be abnormally high and frame rates are relatively low, but the system does not lock up completely. Pausing the video from time to time and adjusting video quality settings are about the only things that prevent the runaway process altogether. Disabling pulseaudio* and falling back on ALSA does not stop the runaway process but does improve the sound quality and synchronization to some extent.
https://account.netflix.com/VideoQuality

I'm not entirely sure that this bug is unique to netflix-desktop, since you can find a variety of reports like this for capable OS X and Windows machines. I should note that similar framrate issues are happening for me using a virtual machine loaded with Windows XP, but not with other streaming video content sites, even at 720p.

2.1GHz Core2 Duo w/ 4GB RAM, SATA 2 HD, 1360x768@60HZ VGA Display, Intel 4500MHD running Ubuntu Precise w/ LXDE (bugs happen w/ both Compiz & OpenBox).

*NOTE: Disabling pulseadio in LXDE results in lxpanel eating up CPU cycles, which gets better after killing the panel and respawning it. Given the LXDE bug with pulseaudio, I'll try again with a different Desktop and post back with a comment here.

[Adam Rigg (adamrigg)]

netflix-desktop version is 0.6.1~precise

Tested again on KDE, Trinity KDE (3.5 fork), Gnome3 and Razor-qt. Guess I could still try XFCE...

netflix-desktop worded best on Trinity, where I got better frame rates (average 24fps) and longer play before things started locking up with the 1050 bit rate. Normal KDE had the best compositing, but it didn't play as long. No frame tearing or other artifacts with either one. Gnome compositing was decent too, but plugin-container was short lived (before jerky playback stuttered to a halt).

The Netflix player loads a whole lot faster in Trinity and in KDE, but there was still the issue of waiting to start back up again to stay off the runaway process. Player controls worked better too--The mouse cursor has a habit of disappearing when exiting full screen with the Esc key in all environments, but less so with the KDEs.

The most common timing for the Silverlight mishaps had been around 20min into a video, which made me wonder if Caffeine had anything to do with it. Sure enough stopping Caffeine and disabling DPMS from the command line has been buying me a little more play time, but it hasn't completely resolved the issue.

[Adam Rigg (adamrigg)]

I finally came up with a workaround that will let me get through an entire TV show without restarting Firefox or waiting around a few minutes after sending the TERM signal to plugin-container (i.e., "killing").

Use kcmshell4 khotkeys (or search "custom shortcuts") to assign 3 hotkeys. Here I use function keys, but adding a modifier key would help to avoid conflicts with other shortcuts--F11 doesn't work while the Netflix player is running, but the shortcuts are global and you might need it for something else:

F10: killall plugin-container
F11: killall -s STOP plugin-container; i8kctl fan 2 2 (or a command to speed up the cpu fan)
F12: killall -s CONT plugin-container

Frame locks up but audio is still playing?
:press F10, wait a few seconds and then press F12 to resume. Repeat until playback returns to normal.

System's all wonky and can't recover?
:press F10. If Silverlight was still suspended and frame remains on screen, press F12 to initiate the TERM signal.

A few caveats: Player controls and Firefox controls won't work again until Silverlight stops with TERM or once you get to the end of a video. The window manager might not like "pausing" the process like this and could react in unpredictable ways, so you'll probably have to alt+tab to other applications and GUI elements might not redraw properly--Works great in KDE 4.8.5 though. The fan command is just a guess and will only work on Dell laptops--I noticed that resuming with F12 worked best after the fan started going faster...I don't have any serious cpu temperature issues when reading the output of sensors, but it's about 100% consistent for me to have to wait until the fan kicks up before resuming, which is only something that happens when running Netflix Desktop.

Using F11 to pause Netflix instead of the player controls takes the load off the CPU and could potentially fix issues before they start when you get up for refreshments.

[Adam Rigg (adamrigg)]

Pausing, exiting the Netflix Player's fullscreen (i.e., Esc, not the browser fullscreen) and then minimizing the browser before sending the STOP signal improves the reliability of the workaround above, avoiding X11 glitches.

[Erich E. Hoover (ehoover)]

Hi Adam, I'm sorry it's taken me so long to post here - I've been very busy lately. I have not seen the issue that you're experiencing, though I haven't watched a full length show since I first got Netflix working. It's possible that there's something that's changed in Wine (which I keep up to date) that's causing this problem, but I would have thought to hear from other people if that's the case. Is it possible that you're experiencing a driver issue?

[Adam Rigg (adamrigg)]

I just disabled Fullscreen Close Plugin and set browser.sessionstore.resume_from_crash to false, which is helping a little (the latter for resuming after browser crashes without having a second tab restoring the player window). I was kinda wondering if it was the fullscreen plugin (probably not the case) but I was mainly shooting for easier access to the window controls during experiments with killall -s STOP/CONT commands. I added statements to my hotkeys to echo signal messages into a debugging log, so hopefully that will help me figure out where the plugin is going bonkers:

killall -s STOP plugin-container; i8kctl fan 2 2; echo "STOP" >> ~/test/netflix-debug.log
echo "CONT" >> ~/test/netflix-debug.log; killall -s CONT plugin-container
killall -s TERM plugin-container; i8kctl fan 2 2; echo "TERM" >> ~/test/netflix-debug.log

Not sure about the drivers--I'm not experiencing the same kinds of errors in other applications outside of WINE, though I have had some issues with Google Chrome's latest Pepper Flash releases, which prompted me to make a change to the audio driver line in /etc/modprobe.d/alsa-base.conf in response to a comment on a bug against pulse-audio, but it didn't seem to do anything for Chrome or for netflix-desktop (added "enable_msi=0" to snd-hda-intel model=dell-vostro) --Adobe Flash and HTML5 video worked great before and after the alsa-base.conf change, with no change to netflix-desktop.

Intel Mobile 4 Series Integrated Graphics Media Accelerator 4500MHD (rev 07) shows up in dmesg as Intel GM45 Chipset, and that the agpgart-intel driver is loading. I know there was a change to that driver during some distribution upgrade maybe a year or two ago which forced me to manually add in some of the VGA output settings, but it's worked fine since then for quite a while (and I'm running below the max resolution specs published by Intel). I suppose there's a chance that it could be related to my Logitech Universal USB receiver, which requires a modprobe hack to keep it from locking up on me--It also likes to switch itself out of sync with the laptop keyboard layout, requiring a quick tap of a deadkey on the laptop to get it back to the system default setting, and I have had more issues with keyboard controls than the GUI controls for Netflix Player.

I guess I could experiment a little with CPU throttling after unplugging the Logitech USB receiver, maybe throttling down rather than just playing with the fan when it starts dropping all kinds of frames and locking up on me or to disable throttling while I'm plugged in and watching video. It doesn't happen much within say, the first 30 minutes of a video, but the CPU load builds and the instabilities happen more frequently the longer I watch, to maybe every five minutes toward the last 15 minutes of a 45 minute show. Closing the browser between episodes rather than autoplaying through to the next video in a series helps to minimize issues.

I've seen a couple other bugs which seem related to the issues I get (lowframe rates & something about freezing up while audio is still playing), but they did not quite match the specific symptoms that I get, since it's usually a recoverable erro...

[Adam Rigg (adamrigg)]

Whoops. didn't realize how big that log file got. Substituting a .tar.gz...

[Adam Rigg (adamrigg)]

I've recently started to experience some related issues with DRM streaming Flash content without WINE, so I'm starting to agree that this is driver related now. Hesitant about mucking around with the more complicated issue of video drivers, I fooled around with the Logitech USB receiver idea, but that was a long shot at best (i.e., didn't work).

I noticed that there were some quantal drivers in the precise-updates branch of the repos, so I gave that a shot, but that gave me some pretty huge issues with starting up X11. Now, after reverting back to the xserver-xorg-video-intel driver from xserver-xorg-video-intel-lts-quantal, netflix-desktop doesn't work at all--just crashes when I try to play a video. I'm guessing that something didn't fully revert when I was trying to switch back from the quantal driver.

See also:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel-lts-quantal/+bug/1154380
https://bugs.launchpad.net/ubuntu/+source/wine/+bug/1127232/comments/2

[Adam Rigg (adamrigg)]

I'm pretty sure it's a bug in the kernel driver rather than the xorg driver. 3.2.0-39-generic definitely has the issue in a pretty severe way, but 3.5.0-26-generic (from generic-lts-quantal) is working much better. I'm seeing vast improvements with processor usage overall.

There are a few changes to the i915 driver listed in the kernel.org changelog for 3.2.40, so the pre-proposed Ubuntu kernel package is probably worth checking out also. The lts-quantal kernel still has a few issues, but Silverlight seems to recover on its own from choppy playback much of the time now. My workarounds also seem to be much more effective.

https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.40
https://launchpad.net/~kernel-ppa/+archive/pre-proposed?field.series_filter=precise

The crash issue listed above after upgrading the xorg driver was related to libGL.so.1 getting replaced by one of the dependencies. A package management bug made it kind of a pain to resolve, but I can use netflix-desktop again after working around a much more critical bug in Ubuntu itself (https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1130419).

[Adam Rigg (adamrigg)]

Probably I should link to the changelog for the ubuntu pre-proposed rather than the kernel.org (i.e., "mainline" one):

https://launchpadlibrarian.net/133476233/linux_3.2.0-40.63~pre201303090400_source.changes

It looks like Ubuntu's 3.2.0-40 is based on Linux 3.2.40, with the same changes to the i915 driver --I just didn't notice the version number difference before.

[Adam Rigg (adamrigg)]

Since the lts-quantal kernel driver is not a complete fix, I started looking into ways of automatically capping the CPU usage to keep the system responsive and to attempt to prevent a runaway process. Turns out that somebody else has already done some really good work in this area:
http://cpulimit.sourceforge.net/

cpulimit is in the standard repositories, and it has some experimental support for child processes. You'd have to use the pid of plugin-container to get it to work in isolation, but going after wineserver works with the experimental support:
cpulimit -e wineserver -l 7

cpulimit will wait in the background for named processes to begin but not with the pid method. The nice thing about going after wineserver with cpulimit, is that you can still use STOP & CONT signals on the child process (i.e., plugin-container). The only real drawback is that the percentage values don't work the same for process groups, so you have to start with a very small %cpu value and work your way up until you get around 24fps (maybe around 10 for a 2.1GHz cpu). Setting the value too small will drag the bitrate down too though if you don't choose it manually from the hidden menu (ctrl+alt+shift+s for the bitrate menu and ctrl+alt+shift+c for the framerate).

It looks like you can distinguish between Linux FF and Wine by plugging `pidof plugin-containe` into the arguments for the pid version of the command. I'm not really sure why it shows up with the 'r' missing or why "killall plugin-container" works with the pidof mismatch.

cpulimit can work pretty well with misbehaving Flash content too.

[Erich E. Hoover (ehoover)]

Adam, do you think cpulimit can be used to effectively "fix" this issue without impacting performance too much for users not having this issue? If you can come up with a generic way for me to implement this then I'd be happy to add it to the package.

[Adam Rigg (adamrigg)]

It wouldn't be a complete fix for whatever the underlying issue is, but at the very least, it could be used to prevent systems from becoming unresponsive, fixing the runaway process problem. Setting the cap to a higher value would prevent it from interfering with users who are not experiencing any issues, as long as you compensate for the difference in usage with SMP by calling nproc to detect the number of cores or processors. Since limiting child processes is still experimental, and since cpulimit won't recognize the named processes for the firefox.exe or plugin-container, loop around until pidof exits with 0 (process exists) and check to make sure the user didn't close Firefox before plugin-container gets called (plugin will keep same pid for remainder of FF session). Something like this could work (replace 40 with %cpu per process):

#!/bin/bash
netflix-desktop &

numcpus=$(nproc)
FFCAP=40
PLUGCAP=40

fflimit=$[numcpus*FFCAP]
pluglimit=$[numcpus*PLUGCAP]

until [ `pidof firefox.exe` ];do
pidof firefox.exe
done

cpulimit -p `pidof firefox.exe` -l $fflimit &

until [ `pidof plugin-containe` ];do

pidof plugin-containe

pidof firefox.exe > /dev/null
if [ $? != 0 ]; then
 break
 exit $?
fi

done

cpulimit -p `pidof plugin-containe` -l $pluglimit

[Rafael Fernandes Maia Mores (rafael-mores)]

Allow me to post my solution to this:

Disable plugin-container by changing these vars to these values:

dom.ipc.plugins.enabled = false
dom.ipc.processCount = 0

Leave the others intact.

On the netflix start page, press Ctrl+L then type about:config, accept the warning and search for these vars to change them.

WIth this, the process no longer tries to use other processor cores and the FPS is fine on my Ubuntu 12.04 LTS x64 running on a AMD Phenom II 1090T 6-core processor.

The downside to it is that if the plugin freezes, firefox will freeze also.

I hope this helps!