[mythtv-users] CPU load when watching TV

[Rod Smith]

On Sunday 13 December 2009 07:54:46 am lee wrote:
> On Sat, Dec 12, 2009 at 05:07:18PM -0700, Brian Wood wrote:
> >
> > I'm not sure why you'd want to do that, Myth swallows the mouse cursor
> > intentionally, who wants that on screen when watching TV? Myth is not
> > designed for mouse control, it expects you to use a remote.
>
> It would be very nice to be able to use the menues with the mouse
> rather than keyboard only. I haven't set up the remote control yet ---
> and I don't exactly see what the use of it would be. And not all TV
> cards do have a remote.

You may want to describe your physical setup. Your comments make me think 
you're either using MythTV in a very awkward way or your viewing area is 
physically unusual (like at a desk rather than a typical living room TV 
viewing area). My impression is that most MythTV frontends are used like 
TiVos or other set-top DVRs -- they reside near the TV, which is placed a few 
feet from the user who sits on a sofa or chair across the room. This 
arrangement makes controlling the system via keyboard and/or mouse awkward, 
particularly if those devices use wired connections. THAT is the use of a 
remote -- you can navigate the menus, etc., just as you would on a TiVo, a 
cable box, a VCR, etc., without dealing with a large keyboard and mouse or 
awkward cables that are an invitation for somebody to trip over them.

There are several approaches to setting up a remote for MythTV use, and not 
all of them involve a TV card's IR receiver or remote. Broadly speaking, 
there are two approaches:

- Use Linux Infrared Remote Control (LIRC) -- This uses a dedicated IR
  receiver, such as one that comes with many TV cards or something you
  buy or build separately, to receive signals from either a matched
  remote control or something random you've got lying around or that you
  buy separately. LIRC generates pseudo-keypresses in response to the
  remote's signals, so you can map the remote's keys to whatever keyboard
  keystrokes you like.

- Use an IR (or radio-frequency) keyboard and universal remote -- Wireless
  keyboards can be used to control MythTV, and by programming a universal
  remote to emulate your wireless keyboard, you can control MythTV by remote
  without setting up LIRC. This is easier on the Linux side, but you'll
  probably have to spend some time configuring the remote, and your choices
  of remotes that work is more limited.

You may want to peruse the wiki's section on remotes 
(http://www.mythtv.org/wiki/Category:Remote_Controls) for more information. 
Many of that page's sub-pages are dedicated to specific remotes, but you 
should pay particular attention to the pages on LIRC 
(http://www.mythtv.org/wiki/LIRC) and on programming remotes as keyboards 
(http://www.mythtv.org/wiki/Programming_Remotes_as_Keyboards).

FWIW, I use the wireless (infrared) keyboard approach, with a universal (JP1) 
remote for most day-to-day operations. I keep my keyboard handy for those 
tasks that require typing. My impression is that the LIRC approach is the 
more common one, though.

> > Top will show you what's using what, start with that.
>
> It showed that kwin was using a lot of CPU ... Other than that, it
> only shows top itself as running.

The top program displays a changing list of processes and their CPU use, 
sorted by criteria you select (top defaults to CPU load). If you're playing 
back video, the playback processes will almost certainly float to the top of 
the list. For instance, here's an example from my desktop system, while 
playing back SD video:

http://www.rodsbooks.com/top.png

This shows quite a few statistics, most of which you can ignore. To tell 
what's chewing up CPU time, look at the list of processes that begins about 
1/4 of the way down the screen. Item #1 in this list is mythfrontend, which 
is consuming 23% of the CPU time. Item #2 in this list is Xorg, at 10%. The 
kmail process is at 6% (it was probably checking for new mail at that moment; 
it's usually much lower than that), and everything else is at 1% or less.

If you don't see similar results, with mythfrontend at the top, X just below 
that, and everything else much less, then something is weird -- or if other 
processes approach or exceed the CPU load imposed by X and/or mythfrontend, 
then they might be legitimately or illegitimately consuming a lot of CPU 
time. If X approaches or exceeds mythfrontend's load, then it's possible that 
X is misconfigured, particularly if that load is high. (I'd define "high" 
as "over 10%" for your system, given that your system is faster than mine.)

Note that you must be able to simultaneously view MythTV and a text-mode shell 
to do this. Since you say you're running MythTV in a window, this shouldn't 
be a problem for you. On my regular frontend, I use a remote login from a 
laptop to do such checks. Switching to a text-mode login hides X and can 
produce weird results.

> > On Sat, Dec 12, 2009 at 07:56:25PM -0500, Rod Smith wrote:
> >
> > Note that using VDPAU just
> > shifts much of the decoding burden from the CPU to the GPU. Since you say
> > your concern is with power consumption, I'm not sure this would really be
> > an improvement. You could always measure it with an appropriate meter, of
> > course.
>
> I'll have to find out more about options to save power first and then
> get a meter to see what's actually going on. I'd like to use suspend
> to disk, but it seems too dangerous. Maybe suspend to RAM is better,
> but what if the power fails? I could have the disks spin down, but
> they are being accessed too much to reasonable do that.

Why do you say that suspend-to-disk is dangerous? If you've got specific 
references saying it's unreliable, I'd be interested in seeing them. If not, 
I wouldn't worry about it. I use suspend-to-disk on a laptop and it seems 
fine. The only times I've had problems have been when I've accidentally 
booted into the wrong OS after suspending to disk. When that happens, the 
second OS thinks that shared volumes haven't been shut down properly, 
resulting in a disk check, which then causes Linux to get confused about the 
state of the disk. On a dedicated MythTV box, this wouldn't be an issue.

As to power failures, the effect of a power failure after suspend-to-RAM vs. 
running normally would be about the same, so compared to keeping the system 
running at all times it wouldn't be any worse. Many people keep their Myth 
boxes on UPSes, which can help mitigate power failure problems.

> > In my experience, database
> > updates are the biggest problem, because they tend to run without being
> > niced.
>
> That shouldn't matter? Or is the database really under a lot of load
> sometimes?

The biggest load is when mythfilldatabase runs -- typically about once a day, 
depending on how you configure it. When mythfilldatabase runs, it downloads 
your guide data and inserts it all into the database, which consumes a fair 
amount of CPU time, in bursts, over a period that can extend to several 
minutes, depending on how many channels you receive and how long it's been 
since the last run. There's also a brief burst of database load when you do 
things like schedule new recordings, but I personally don't do this while 
watching TV. (It could happen on a system with multiple frontends, though -- 
you could be watching on a combined frontend/master backend and somebody else 
could schedule a recording on another system.)

-- 
Rod Smith