<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 13-05-13 04:28 AM, John Pilkington
wrote:<br>
</div>
<blockquote cite="mid:5190B23C.3080505@tesco.net" type="cite">On
13/05/13 08:45, Stephen Worthington wrote:
<br>
<blockquote type="cite">On Sun, 12 May 2013 21:40:46 -0500, you
wrote:
<br>
<br>
<blockquote type="cite">Our box is a 4 CPU 3.4GHz i5, 8G ram,
Ubuntu 12.10, with a PCIe InfiniTV
<br>
4-tuner card (which produces mpeg-ts content). It usually has
XBMC
<br>
running idle on it and mythtv. We also do background Handbrake
encodings
<br>
and editing with Avidemux (as needed). I notice that under
some
<br>
circumstances, our recordings have considerable noise,
especially during
<br>
the first few minutes. My theory is that this occurs when
consecutive
<br>
movies are recorded, or perhaps when more than one is recorded
at once.
<br>
I do have the default set to record 1 minute before and after
a show, so
<br>
we could be using two tuners and double the I/O for a minute
for
<br>
consecutive recordings. On some occasions we might record two
<br>
consecutive shows on two channels simultaneously, so I guess
we could
<br>
briefly have 4 recordings at once.
<br>
<br>
After a recording is complete, I make a copy of the .mpg to
the same
<br>
disk to simplify the task of my wife copying the file to her
machine for
<br>
Avidemux (avoids symlink issues). I also create an Avidemux
index file.
<br>
<br>
I see that mythbackend runs with a normal *nice* value and
with *ionice
<br>
idle*. I just modified my post-record script to run the copy
and
<br>
avidemux create index with ionice idle and nice 10. Perhaps
this will
<br>
solve my problem. But I am curious why mythbackend doesn't run
with a
<br>
normal *ionice* value. Is the content from the InfiniTV
considered I/O
<br>
by ionice and impacted by it? Does mythtv buffer frames as
needed when
<br>
the I/O is backed up a bit?
<br>
<br>
If I have to I'll rearrange the disks or acquire more or
faster (SSD)
<br>
disks. But I'm not sure if *ionice**idle* requires ALL I/O to
be idle,
<br>
or if it is on a per-device basis. Today I have a disk for the
normal
<br>
Ubuntu stuff (root, /usr, /home, /tmp). I have one, /pvr, for
mthtv and
<br>
a staging area for movies to be edited or encoded and one for
movies
<br>
after they have been encoded for XBMC. They are not fast disks
(5400)
<br>
</blockquote>
<br>
You did not say how many hard drives you are recording to. If
you
<br>
only have the one hard drive with the system on it and are doing
all
<br>
your recordings to that drive also, then yes, you are probably
<br>
overloading the drive. Modern hard drives are very fast at
sequential
<br>
writing, but when they have to move the heads back and forth
between
<br>
four different recordings, plus the usual system accesses and
the
<br>
occasionally heavy database use by MythTV (especially if the
scheduler
<br>
runs), then they do get overloaded and blocks of recordings go
<br>
missing. The head movement speed has not increased nearly as
much as
<br>
the sequential write speeds have as drive technology has
improved. The
<br>
fix is normally to add one or more extra hard drives to record
to, and
<br>
move enough recording files over onto the new drives so that
there is
<br>
reasonably equal spare space on all the recording partitions.
<br>
<br>
Also, it is very important to use JFS or XFS for recording
partitions,
<br>
as deleting huge video files from EXT partitions frequently
causes so
<br>
much activity that it will prevent recordings from working. If
you
<br>
are set up with an EXT type partition for recordings, then you
can
<br>
help with that problem by setting the option for slow deletes.
Sorry,
<br>
I can not remember exactly where in the setup screens to find
it. If
<br>
your recording drives are full and having to expire old
programs, that
<br>
can happen during recordings and on an EXT partition that will
cause
<br>
problems without the slow deletes option. Just one delete at
the same
<br>
time as one recording on an EXT partition can cause problems.
<br>
<br>
Do you also run mythcommflag (commercial skip processing
enabled)? If
<br>
so, change its options in MythTV to use a lower priority also.
And as
<br>
you seem to have lots of RAM, you might like to set it to start
at the
<br>
same time as the recording starts. If you do that and have
enough
<br>
RAM, mythcommflag will be getting all its data from the buffers
in RAM
<br>
before the data is written to disk, so it will not be reading
disk all
<br>
the time and moving the heads on the drives.
<br>
</blockquote>
<br>
It seems strange to me that your backend is running with ionice
set to idle; during recording there are many operations that are
time critical, even if there is lots of buffering. Where did that
setting come from? ionice idle ought to be only for operations
that can be delayed without causing problems, such as commflagging
and transcoding completed recordings.
<br>
</blockquote>
I modified the /etc/init/mythtv-backend.conf to add a call to <b>ionice</b>
and <b>renice</b>. I confirmed that this did change the priorities
using <b>top</b> and <b>ionice -p</b>.<br>
<br>
script<br>
test -f /etc/default/locale && . /etc/default/locale
|| true<br>
ionice -c 2 -n 2 -p $$<br>
renice -n -5 -p $$<br>
LANG=$LANG exec /usr/bin/mythbackend --syslog local7 --user
mythtv<br>
end script<br>
<br>
I am guessing that Upstart itself is running with ionice -c idle and
mythbackend was inheriting it. I will see how this works out.<br>
<br>
<br>
<br>
<br>
</body>
</html>