I use MythTV for all my TV watching needs. I am a full time student and work a full time job. That does not leave much time to watch TV. With the commercial flagging and auto commercial skip functions turned on in Myth I rarely ever even see a commercial anymore. Another plus is it takes about 40 minutes to watch an hour long show.
Recently I was attempting to watch one of the HD recorded programs from my secondary frontend machine and the video would pause for a couple of seconds every 10 to 15 seconds. I could hear the hard drive in the master backend machine screaming along.
I don’t have an overly advanced Myth setup, but I do have two analog tuners (PVR-500 single PCI card) and a single digital tuner (Pinnacle 800i PCI card). Neither of these require the CPU to do any encoding of the video so the CPU requirements are minimal. The I/O on the computer can easily get overloaded though! If all three of my tuners are recording at once the raw write bandwidth is 2 x (4500-6000) bits/sec + up to 17.89 mb/sec for 1080i. Total is ~20 mb/sec up to a max of 29.89 mb/sec (3.74 MB/sec). Not really too much of load yet; especially for a SATA-II drive. The next thing that will be consuming I/O bandwidth is commercial flagging.
In a nutshell Myth plays the entire show through and flags where it thinks the commercials are. That is a very simple explanation, but it works incredibly well. It also requires a read of the recording from the HD. My BE machine has an AMD Athlon64 x2 5000+ and I have it set to run a maximum of 2 commercial flagging jobs at once. My FE has an AMD Athlon64 x2 5200+ and I have it set to run only a single job, leaving one core free for watching TV. Total commercial flagging jobs that can run at once is 3. So add reading of three shows from the HD to the total I/O load. The CPUs I have can comm flag SD or HD content very near real time so they need the data as fast as it records. Total I/O load is now up to ~60 mb/sec (7.94 MB/sec). So far my single SATA-II drive should be able to keep up, but this is only basic PVR recording. I still have to account for watching a show and fragmentation.
Now that my system is pushing roughly 8MB/sec to/from the drive I start watching a show. If it is 1080i HD then add another 17.89 mb/sec (2.24 MB/sec) of read. This is where I started to notice the choppy playback.
There are several things that can be done with the Linux settings as well as from within MythTV to alleviate some of the problem. One of the first things I looked at was fragmentation of the XFS filesystem where I saved the recorded video. XFS is a very high performance filesystem when working with large files (recordings are from 2GB – 10GB per show). The problem is the default XFS options allocate space in small chunks when saving the file. There is no other data saved to the drive that holds my recordings. The smallest file I can see being added to the drive is ~2GB (30 min SD show). For this reason I added the mount option to tell XFS to allocate 1GB chunks when saving files. This would create between 2 and 10 fragments per file instead of the potentially enormous number of fragments. Default allocation size is 64KiB rather than 1GB. This is what the line in /etc/fstab looks like now:
root@mythfront:~# grep sdb1 /etc/fstab
/dev/sdb1 /var/lib/mythtv/recordings xfs logbufs=8,noatime,nodiratime,allocsize=1G 0 0
The other options turn off recording the access time of files and directories and using 8 buffers for the file system journal. The extra journal buffers cost some RAM, but my system has 2GB which is plenty.
I also used the xfs_fsr command to check the fragmentation of the filesystem:
root@mythfront:~$ xfs_db -r /dev/sdb1
actual 947896, ideal 95491, fragmentation factor 89.93%
The ‘-r’ option is needed to view (read only) a mounted filesystem. As you can see the fragmentation is rather large. The command to defrag an XFS filesystem is xfs_fsr. It has a couple of options, but the only one I cared about was ‘-t [seconds]‘ which allows me to tell XFS how long to run. After several runs like this:
xfs_fsr -m /etc/mtab -t 7200 -f /var/tmp/.fsrlast_xfs …
/var/lib/mythtv/recordings start inode=0
xfs_fsr startpass 0, endpass 0, time 9334 seconds
I now have a much better optimized filesystem. Current fragmentation is:
root@mythfront:~# xfs_db -r /dev/sdb1
actual 109246, ideal 95568, fragmentation factor 12.52%
Much better! If you change the allocation size of the XFS filesystem and your Myth system is constantly recording there is little need to manually defrag. As shows are deleted the new ones will automatically be written in 1GB chunks. I may loose a little space by doing this, but that could be alleviated by setting the allocsize down to 512M or if recording mainly SD content 256M. It has only been a few days since I fixed these settings, but I have not seen any problems.
The next thing I will do is add some spare 250GB drives into my desktop tower case so that I can use them for recordings as well. Myth, through the magic of storage groups, will save one recording to each physical drive. This will create less I/O per drive but move some of that to the network. I guess a gigabit switch is also in order. I will post some details once I get the next upgrade done.