[mythtv-users] PVR-500 picture quality

[Devin Heitmueller]

On Mon, Feb 1, 2010 at 9:17 AM, Brian Wood <beww at beww.org> wrote:
> On Sunday 31 January 2010 09:09:31 pm Mw wrote:
>
>>
>> I see a significant drop in quality with my 500. Specifically, diagonal
>> banding from lower left to upper right. It may be related to the type B
>> Philips tuners on it. The very early PVR-350 I was using was almost spot
>> on. Hardly any artifacts at all.
>
> Diagonal "banding", which has been mentioned by several users, is commonly
> referred to as "beats". This is caused by a steady carrier falling within the
> video passband of the analog channel. The unwanted signal can be caused by
> several things, usually heterodyne "beat products" caused by the mixing of 2
> or more signals. This can occur in the cable TV amplifiers (trunk amps,
> bridgers or line extenders), in an amplifier at the customer's premises or in
> the front end of the tuner in the PVR itself. The "LNA" in the PVR-500 is also
> a possible source of such beats.
>
> Whatever device is causing the beats will usually be very sensitive to the
> level of the signals presented to it.
>
> Such problems can also be caused by the cable system not maintaining their
> levels accurately, audio carriers might be running at a higher levels than
> they should be, special carriers used by "sniffer" systems often cause such
> problems.
>
>>
>> > The PVRs use a consumer grade encoder, which I would expect to behave
>> > this way, the degradation is not enough to bother me, considering the
>> > source is analog CATV, which is not all that great to start with.
>>
>> Noise in the source from the headend can greatly impact the quality of
>> the PVRs. Typically, the analog SD from my Comcast feed is pretty noisy.
>> The encoders on my 500 seem to be very sensitive to this noise and
>> compression artifacts are obvious.
>
> Noise does not  generally compress well, and noisy signals will cause problems
> in many ways. Analog cable signals, especially far out on a cascade, are
> generally pretty bad, and the encoders can't tell the difference between signal
> and noise, and try to reproduce the undesired noise, usually making things
> worse.
>
>>
>> Every now and then, one of the HE techs isn't paying attention and the
>> signal becomes really, really clear. Almost as clear as unscrambled 480i
>> digital. The artifacts are hardly noticeable on these recordings  but
>> the banding remains. Eventually, the technician will fiddle with the mux
>> chain until the signal gets crappy again.
>>
>
> It might be a HE tech, but there are many other factors. Cable attenuation
> varies with temperature, and the systems used to compensate these changes are
> imperfect, so the levels you receive will vary with temperature, time of day
> and even the amount of cloudiness (sunshine on a black jacketed cable causes
> its temperature to change independent of the ambient air temperature). It's
> hard to pin down precisely, there are just too many variables.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

One thing that I try to help debug these issues is I keep a small
Windows XP partition on all of the boxes I have capture hardware
installed in (which I am legally allowed to do since all the PCs came
with XP anyway).  When I see a problem, I can reboot into Windows and
see if it occurs as well with the default software that comes with the
tuner.  This will help narrow down whether the issue is hardware or
driver specific.

This thread has talked about variability in signal conditions as well
as the capabilities of the hardware in general.  However, you should
also consider that many of these problems *could* be driver issues.
For example, I debugged a quality issue last week in the saa7113
driver where the end result was flipping one register bit to enable
one of the filters that should have been enabled by default (and was
under Windows).  And that problem had been there for *years* since
nobody with the appropriate experience had taken the time to notice
and then debug the problem (and it was "good enough" for most users).

In other words, don't discount the possibility that the performance is
crappy because the driver is not properly programming the hardware.
The reality is that in many cases the developer does just enough work
to get the capture card "working", and misses things that an trained
eye is likely to notice.  And not to disparage any of the driver
developers (I am one in fact), most of us would not fall into the
category of "a trained eye".

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com