[mythtv-users] CPU load when watching TV
mythtv at rodsbooks.com
Mon Dec 14 16:01:48 UTC 2009
On Monday 14 December 2009 08:22:52 am lee wrote:
> On Sun, Dec 13, 2009 at 02:42:47PM -0500, Rod Smith wrote:
> > 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.
Not for MythTV users. I believe this was the source of some minor
miscommunications in earlier posts; people assumed you were running as they
do, and you weren't.
> 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.
In this situation, I agree that a remote would provide little benefit.
> > 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
> 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.
To me, this sounds very awkward. Some people build dedicated front-end systems
for this purpose. Such systems don't even need a disk; they can be booted
over the network. Another approach is to use a video distribution system to
move the video from the computer in one room to the TV in another room. A
friend of mine has a setup like that; his Myth box is in his basement and he
watches it upstairs.
Of course, if you're happy watching TV at your desk, there's no need for any
of this. The beauty of MythTV is that it provides a lot of options, so you
can set it up for lots of different situations.
> > The top program displays a changing list of processes and their CPU use,
> > sorted by criteria you select
> 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
If this is typical, and nothing was spiking or at an unusually low value for
playback, then I'd say that MythTV is consuming very little CPU time. On a
dedicated Myth box, the 17% CPU time consumed by kwin would be unacceptable.
(In case you don't know, kwin is the KDE window manager, which displays
borders around windows, enables you to move and resize them, etc.) Most
dedicated MythTV systems use less resource-intensive window managers, such as
openbox. I'm actually surprised that kwin is consuming so much CPU time. Does
its CPU consumption go down when you stop playing back video? It could be
there's some inefficient coding in there that's causing its CPU needs to
skyrocket with a dynamic display. For comparison, I'm using XFce and its
xfwm4 window manager on my desktop system, and its CPU use doesn't even make
the list that's displayed by top in a standard window. Ditto for openbox on
my dedicated MythTV box.
That said, your overall CPU use is low enough that I wouldn't recommend
switching away from KDE, or changing its window manager, just for this. If it
caused stuttering or other CPU contention issues, it might be worth
switching, and likewise if this were a dedicated MythTV system. Since you use
the computer as a desktop system, though, changing your window manager will
require you to change the way you use the system, at least a little, and
that's not worth it.
> > 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
I don't read the warnings as being that dire. The fsck utility does a good job
of recovering from such damage, and has done so on my laptop a couple of
times. Of course, if you think you're likely to frequently forget you were in
a suspended state and change hardware, then playing it safe makes sense. For
me, this wouldn't be an issue on a dedicated MythTV box, but it could be on
> > > That shouldn't matter? Or is the database really under a lot of load
> > > sometimes?
> > The biggest load is when mythfilldatabase runs
> 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.
I'm in the US and so use Schedules Direct and mythfilldatabase. I'm less
familiar with how Myth handles EPG data.
More information about the mythtv-users