[mythtv-users] CPU load when watching TV

[lee]

On Sun, Dec 13, 2009 at 02:42:47PM -0500, Rod Smith wrote:
> 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).

Well, having the computer in the living room and connected to the TV
would be rather unusual. I'm sitting at a desk and am using the
computer as a computer, doing things while eventually watching TV, or
somtimes using it to watch TV only.

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

True, but I'd need another computer for that to place in the living
room. When I want to watch something on TV, I create a DVD for that.

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

The TV card has a remote control --- some time I'll see if I can get
it to work with lircd. I've even seen a configuration file for lirdc
for the TV card I have. But I don't have a need for it since I can use
the keyboard and the trackball on the computer.

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

Mythfrontend and kwin are around 10--20% when playing back a recording.

top - 14:04:45 up 1 day, 21:13,  8 users,  load average: 0.06, 0.23, 0.50
Tasks: 208 total,   1 running, 204 sleeping,   0 stopped,   3 zombie
Cpu(s):  3.0%us,  3.1%sy,  0.0%ni, 89.9%id,  0.0%wa,  0.5%hi,  3.6%si,  0.0%st
Mem:   4054432k total,  4024564k used,    29868k free,    17172k buffers
Swap: 31246416k total,    88888k used, 31157528k free,  3096808k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
23189 lee       40   0  566m  57m  23m S   17  1.5  30:36.82 kwin               
 7271 lee       40   0  787m 137m  42m S   14  3.5   3:04.45 mythfrontend       
23044 root      40   0 3210m  51m  10m S    5  1.3  19:02.28 Xorg               
 5585 mythtv    40   0  582m  27m 9884 S    1  0.7   2:35.99 mythbackend        
 7804 root      20   0     0    0    0 S    1  0.0   0:01.24 cx88[0] dvb        
 7849 root      40   0 19100 1388  968 R    1  0.0   0:00.07 top                
  272 root      20   0     0    0    0 S    0  0.0   0:11.33 kondemand/3        
23349 lee       20   0  692m  90m 9.9m S    0  2.3   3:02.44 seamonkey-bin      
26709 lee       40   0 29816 2148 1716 S    0  0.1   1:03.17 xosview            
    1 root      40   0 10328  232  184 S    0  0.0   0:01.55 init               
    2 root      40   0     0    0    0 S    0  0.0   0:00.03 kthreadd           
    3 root      RT   0     0    0    0 S    0  0.0   0:00.08 migration/0        
    4 root      20   0     0    0    0 S    0  0.0   0:00.27 ksoftirqd/0        

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

Just look at all the warnings in the help of the kernel
configuration. When you change the hardware while suspended to disk or
if you don't reboot using the memory image stored in the swap
partition, your file systems will be corrupted. There's no way I could
take a risk like that. I don't know, but I guess something simple like
removing an USB stick while suspended will be enough to lose all your
data.

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

Still all your data can easily be lost, if you believe the
warnings. It wouldn't be a desaster on a dedicated box, but I don't
have one ...

Another problem is to wake up the computer when it's time to record
something. How do you do that?

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

Hm, that's probably true. Maybe I should try at least suspend to RAM.

> Many people keep their Myth 
> boxes on UPSes, which can help mitigate power failure problems.

Yeah, I still need an UPS.

> > 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.)

So far, I haven't noticed any of that. I'm only getting EPG data as
there doesn't seem to be any other useable source available.