[pvrusb2] HVR-1950 Schedule Information Source

[Mike Isely]

On Wed, 6 May 2009, Roger wrote:

> On Wed, 2009-05-06 at 19:51 -0500, roccomoretti wrote:

   [...]

> 
> > A final, more pvrusb2-related note: the pvrusb2 driver enforces mutual 
> > exclusion between the digital and analog sides, due to hardware 
> > constraints. Usually the transition happens seamlessly, but if any 
> > program is using the digital tuner *for any reason*, you can't switch to 
> > the analog mode for as long as the digital tuner is in use. Scanning for 
> > EIT data counts as using the digital tuner. The issue comes if you tell 
> > MythTV to use the ATSC EIT info - it will constantly scan the EIT, 
> > holding the digital side open. You can turn the EIT scan off, but then 
> > updates to the EPG become unreliable. :-)
> 
> Again, thanks for the clarification on this as well!
> 
> I was troubled into thinking when I would have to schedule the MythTV
> backend to scan for ATSC EIT info.  Now that you've stated it's
> constantly scanning, I find this completely interesting!

And realize his very important point here: If MythTV is using the 
HVR-1950 to scan for EIT data, then the digital side will be busy during 
that time and the analog side will NOT be available.  This is a critical 
point, and based on previous discussions I have seen, MythTV will not 
realize it is doing this.  Net effect is a complete inability to 
reliably use the analog side of the device.  MythTV apparently won't 
keep track of its own usage of the device when EIT data is involved.

I should update the pvrusb2 web pages to point this out.  Several people 
here have been burned by this.  Just to make this clear: It is not a 
fault of the pvrusb2 driver, but rather this is a scenario (using EIT 
data) where MythTV may erroneously try to operate both sides of the 
device at once, which of course can't work.


> 
> 
> I've performed manual scheduling using MythWIKI for the past year.  It's
> much easier with the wiki page, after the initial learning curve.
> 
> Feeling more comfortable the HVR-1950 should work here after acquiring
> this missing info concerning EIT & finding XvMC works extremely well
> (nullifying the system requirements. ;-)

You DO realize you're debating an issue that amounts to a trivial 
$20/year, right?


> 
> I was considering a HDHomeRun, but then would figure I would have to
> upgrade my entire network to gigabit and then, as I run Gentoo syncing
> to a local portage, would create hiccups on the local net causing frame
> jitters during recordings.  Figure the pvrusb2/hvr-1950 will provide
> better stable recordings.

You'll get the same quality of recording from either type of device.

Two errors in logic here.

First, you don't need a gigabit network to use an HDHomerun.  I ran here 
using 100BaseT for quite a long time without any problem.  (I'm using 
gigabit everywhere now but this wasn't the reason why.)  If you're 
really worried about this, stick a second NIC in your backend system and 
use a crossover cable to direct-connect it to the HDHomeRun.  With that 
you'll have a private pipe to the tuner anyway.

Second, the data from an HDHomeRun - just like from an HVR-1950 or any 
pvrusb2-driven device - is a digital bit stream consisting of mpeg2 
data.  These are not raw video frames and are thus not sensitive to 
relative timing.  This is an important difference because mpeg2 data is 
internally self-timed.  Jitter / non-deterministic packet delivery will 
not harm the quality of the video stream at all.  So long as the sending 
side can buffer a second or two of data (should not be a problem) you 
won't lose anything.  And since the receiving end is a MythTV backend, 
it's going to buffer up a few seconds there anyway.  Hiccups should not 
be a problem - unless your backend gets overloaded but that's the same 
with a pvrusb2-driven device as well.

The behavior of the bit stream from an HDHomeRun will be functionally 
identical to what you get from a pvrusb2-driven device, i.e. in the end 
it's just an mpeg stream.  And a 100BaseT link should be fine.

  -Mike

-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8