[mythtv-users] Some real-life HDTV bandwidth/reliability observations

[Yeechang Lee]

Please consult the list archive for more on my setup. Quick recap:
* Frontend/backend: 3.0GHz Hyperthreaded Pentium 4 with 512MB running
  Fedora Core 4 and MythTV 0.18.1 from ATrpms
* Program sources: Two Motorola DCT-6200 boxes through FireWire
  (Point-to-point at 200Mbps).
* MythTV storage: Infrant ReadyNAS 600 gigabit Ethernet-capable NAS in
  ext3 over RAID 0, mounted via CIFS [1]
* Network: D-Link PCI Express gigabit Ethernet card and SMC gigabit
  Ethernet switch

My experiences:
* Frontend/backend (frontend presumably swapped out to disk, DPMS on)
  and storage are idle: Two HDTV (from the premium movie channels,
  say) programs record simultaneously without IOBOUND errors. One
  high-bandwidth [2] HDTV program, or one high-bandwidth and one
  regular HDTV, seems OK; I haven't empirically tested two yet, but
  believe it should also be all right.
* I'm watching a HDTV program and I'm also copying non-MythTV files
  from the Infrant to another machine on the network: One HDTV program
  and one non-HDTV program record simultaneously without IOBOUND
  errors, generally speaking, except a burst for 4-6 seconds at
  occasional five-minute multiples as Brandon Beattie and I have
  discussed here recently. Two HDTV recordings at once result in
  steady IOBOUND errors.
* I delete a program from the frontend: A few lines of IOBOUND errors
  regardless of what I am recording. Interestingly, deleting files
  outside mythfrontend doesn't seem to be a problem, as I think I've
  recently noted.
* Frontend/backend is idle, and I'm also copying non-MythTV files from
  the Infrant to another machine on the network: Two HDTV programs
  record simultaneously without IOBOUND errors. One high-bandwidth
  HDTV program (such as anything from HDNet) generates slightly more
  serious (up to about 10 seconds) IOBOUND bursts at occasional
  five-minute intervals.
* A single medium-load commflag job is running and I'm also copying
  non-MythTV files from the Infrant to another machine on the network:
  One HDTV program records with 4 to 6-second IOBOUND bursts at
  occasional five-minute multiples.

Bandwidth use:
* Digital non-HDTV channels generate the smallest files at about
  900-1000MB/hour for a movie channel and up to 1200MB/hour for a
  cartoon (with probably a lower-quality feed).
* Analog channels such as TCM generate about 2900MB/hour due to the
  extra noise. HDTV movie channels generate about
  4400MB-4700MB/hour.
* A high-bandwidth HDTV channel generates 7400-7700MB/hour . . .
* Except for ABC (and, presumably, Fox), whose 720p programs record at
  about 5.8GB/hour.

Other notes:
* I've seen the occasional mangled channel change (typically a digit
  dropped) over FireWire when using live TV, but haven't seen it yet
  with a recording.
* I still *do* see the dreaded "recording previews fine but kills
  mythfrontend on playback or at first OSD display [or at best, OSD
  doesn't come up at all]" issue with perhaps one of every dozen
  recordings. I haven't noticed any particular pattern regarding
  channels, but this is my #1 annoyance with MythTV at the moment,
  and--if I may plea to the developers and/or the ATrpms
  packager--ample justification for an interim hotfix release for the
  0.18.x series as opposed to having non-SVN users wait for the fix I
  understand is in SVN to appear with 0.19. (By contrast, I can live
  with "frontend crashes after two or three source changes during live
  TV" and "changing channels in live TV mangles the sound, requiring
  an escape and reentry into live TV to fix" issues; as an old TiVo
  hand I know just how useless live TV generally is.)

[1] Please see the list archives for why I use CIFS and not NFS.

[2] Such as anything from HDNet or Discovery HD Theater and,
interestingly, most network affiliates over cable. I presume OTA
broadcasts' bandwidth demands would be even greater.

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