Mailing List Archive

Some real-life HDTV bandwidth/reliability observations
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@pobox.com> | +1 650 776 7763 | San Francisco CA US
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Some real-life HDTV bandwidth/reliability observations [ In reply to ]
I have two tuners, HD3000 and FusionLite5 and went thru similar issues
in sept/oct. The solution which worked for me was to increase
TFW_DEF_BUF_SIZE value to 32MB. There were other suggestions such as
using a different elevator program or file system. Once I changed the
variable to 32mb, all the IOBounds were history ! I still dont do any
commflagging or file deletion while recoding HDTV programs. Deleting
files on xfs is a breeze though compared to ext3. Search users/dev
list for the variable.

On 1/19/06, Yeechang Lee <ylee@pobox.com> wrote:
> 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@pobox.com> | +1 650 776 7763 | San Francisco CA US
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users