[mythtv-users] Commflag-related IOBOUND errors

[Yeechang Lee]

Brandon Beattie <brandon+myth at linuxis.us> says:
> Every time a recording, transcode, commercial detection, and so on start
> or finish the recordings table is updated.

The IOBOUND errors I mentioned that are occurring at five-minute
multiples (and one-minute multiples before I changed the "check every
x seconds" setting in the backend from the default) occur independent
of any recording starts or stops. As previously mentioned I have set
commflag jobs to only occur in the early morning, and I never do
transcode.

> If you use EIT monitoring with a HD tuner than every time this
> finishes it can cause the recording scheduler to be re-run.

Sorry, don't know what EIT monitoring is; I use FireWire with my HD
cable boxes.

> Adding RAM will not help at all. This is purely a system and disk IO
> issue.

This both gladdens my wallet while dimming my hopes for
always-pristine (subject to the vagaries of cable provider
compression) HD recordings regardless of circumstance.

> Also, the PCI bus can be occupied and cause data from the card to be
> lost if the system IO can't be freed up quick enough to handle the
> data.  HD tuner cards have a rather small cache on them.  If
> anything occupies the system IO longer than 500ms then you risk
> losing data from the HD tuner, and Myth and the scheduler does this
> at times.

Hmm. If it's not a swapping issue, perhaps I should turn the
ringbuffer size on the frontend back up to the maximum? I thought that
only applied to Live TV. Is there a separate ringbuffer setting I am
not aware of in 0.18.1? (Live TV is set to record locally, but I
wonder if maybe it's better to trade network bandwidth for disk IO
bandwidth and set it to go to the same place the recordings go to?)

> The best way to fix this?  Keep the drive for the database on a
> different disk than one used for recordings.

Done. I keep the database on a local SATA drive, but the recordings go
to an Infrant 600 2TB over gigabit Ethernet . . .

> Use XFS or JFS.

. . . and which uses ext3, not JFS (as I use pretty much everywhere
else), as its filesystem. (Although the Infrant folks use
straightforward md-compatible RAID on the 600 [and even their
proprietary X-RAID on the X6 is md-readable], I think they've tweaked
with the ext3 filesystem code a bit. When I delete a recording, the
system gives me back control as quickly as when I recorded to my JFS-based
RAID array, but only for a split second; then there is a distinct
'hang' for a few moments as the deletions occur. And yes, this does
cause a few bursts of IOBOUNDs when I am doing HDTV recording at the
time.)

> Make sure nothing else IO intensive is running when the schedular
> runs.

That's easy; the MythTV box doesn't do anything else but MythTV, and
the Infrant is going to be dedicated solely to Myth (at least once
I've moved my remaining non-Myth video collection off it).

> Intel based systems have less of a problem than AMD from what I've
> seen (Intel systems with hyper threading that is).

Check that; the MythTV box is a 3.0GHz Pentium 4.

> Reiser is a good choice though for the filesystem holding the
> database, since it does a better job with sub GB size files.  =

Like I said, I am using JFS pretty much everywhere else, and that
includes the MythTV box's local disk.

I wonder if this is a latency issue? Unfortuantely I can't tweak up
the latency on my PCI Express gigabit Ethernet card with setpci; I've
tried.

-- 
Yeechang Lee <ylee at pobox.com> | +1 650 776 7763 | San Francisco CA US