Hi Andy,

First, I thought you might be interested in some testing I've done. I 
configured my card to match yours, i.e. standard, bit rates, stream 
type. And I still had static on channel 29. Then I ran through all the 
cable channels and tried to quantify the levels of static I heard on 
each station. It's subjective and I want to repeat it, and spend a 
little more time on each channel, because sometimes the longer I stay 
with a channel, there's a chance the static will clear up to some 
degree. Anyway, here are my notes from my first pass:

No sound on 18, 41
Static not noticeable on 2, 3, 5, 16, 17, 20, 21, 54, 56, 59, 60, 61, 
62, 63, 64, 65, 66, 67, 68, 69, 70, 81, 82, 83, 84
Not noticeable on 22 (although ivtv-tune did not report "Signal detected")
Slight on 23, 25, 56, 57, 87
Some on 4, 7, 8, 10, 11, 13, 14, 15, 24, 26, 27, 33, 34, 41, 43, 46, 47, 
49, 51, 52, 53, 55
Annoying on 6, 29, 30, 31, 32, 36, 37, 38, 40, 42, 58
Not noticeable to annoying on 19 changed with image and/or speaker
Really annoying to annoying on 12, 28 changed with image
No sound to really annoying to annoying on 35
White noise & video on 39, 71-80, 85, 86, 88-116, 118-125, same on TV 
(no signal detected by ivtv-tune)
I should get 39 (HSN), 85 (JWLTV), 95 (TBN), 107 (GEMSTV) but not the others
No sound to really annoying on 44
No sound to annoying on 45
Really annoying to annoying on 48
Really annoying to some on 50
No sound on 117 (test pattern)

Hope they make sense. If it will help, I'll put them in a spreadsheet. 
Maybe a subjective scale from 0-4? Here are my definitions:

0, Not noticeable: I can't hear static at normal volume
1, Slight: I might not notice it if I weren't listening for it.
2, Some: I notice it, but it's lower than the other sounds.
3, Annoying: About the same volume as other sounds.
4, Really annoying: louder than the other sounds.

> Please double check the guidelines here:
> 
> http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality

Will do.

> An unterminated splitter output can cause reflections that show up as
> elevated noise floor.

That is a possibility. I don't think we have TVs hooked up to all the 
outputs from the 8 way splitter, although I'm 99% sure they all go to 
one room or another.

> First, I have had a 4 way spliteer where one (and only one) of the
> output ports was bad.  It was a brand new expensive one too. :(

That's why I swapped connections between my two boards. It didn't 
matter. The PVR-150 produced good recordings using what had been the 
HVR-1600 connection, and the HVR-1600 still produced static on what had 
been the PVR-150 connection.

> You, however, may want to just try bypassing you in line amplifier and
> seeing if the static goes away.

I can probably do this as a test, move the computer to the office and 
use the cable modem's unamplified connection. If it works, I'll have to 
go into the attic to effect a more permanent solution. Not something I 
look forward to, it's got this fluffy insulation that gets all over the 
place.

>> Hmm, I do have an old Gemini cable box. I think it's 20+ years old.
>> Would it be a useful data point if I hooked it up to the HVR-1600?
> 
> Well.  We know a cable box will only output on channel 3.  There is no
> chance for intermodulation products and you will also only exercise the
> low VHF part of the analog tuner.  Your problem on channel 29 manifests
> with the UHF part of the tuner with many channels available.  If the
> static persists with the cable box attached, we'll know it's not a
> signal problem if one assumes the analog tuner is not defective.

So it wouldn't be a waste of time, right? I'm afraid I'm not an EE 
although I do have an engineering degree. I sort of get the gist of what 
you're saying, but I don't really understand.

I'll probably try this first, since it's easier than moving the computer 
around.

> It works, both sliced and raw.  I've got to make improvements for
> non-NTSC standards though.

I've tried to figure out the difference between sliced & raw. I searched 
a while back, but never found a good explanation. I think I understand 
what sliced is. It's what MythTV uses. FWIW, I've written a little 
program that extracts the data and passes it off to libzvbi, used by xawtv.

> The interlock on insertion of private packets only in the PS is strictly
> a cx18 driver software thing.
> 
> I know the insertion will corrupt the MPEG TS and would likely not do
> well with the MPEG-1 streams.  So I put in an interlock to only let it
> happen with the PS.  If there are stream types where you know from
> experience ivtv wouldn't corrupt the stream, let me know and I'll add it
> back for cx18.
> 
> Here's what I think about enabling private packet insertion without in
> depth analysis of anything other than the PS and TS:
> 
> OK  0: MPEG-2 Program Stream
> No! 1: MPEG-2 Transport Stream
> No? 2: MPEG-1 System Stream
> ??? 3: MPEG-2 DVD-compatible Stream
> No? 4: MPEG-1 VCD-compatible Stream
> ??? 5: MPEG-2 SVCD-compatible Stream

Well, I can confirm that the IVTV driver does add the VBI private 
packets to the DVD compatible stream and that MythTV will display the 
CCs. I haven't used the MPEG-1 stream types, so can't comment.

One way to decide might be how badly it might break applications like 
mplayer, xine, myth, dvdauthor or ccextractor. For example, it should be 
possible to author a DVD using DVD compatible streams. However, in 
practice, dvdauthor, in particular, requires front end applications to 
separate the video and audio streams, then put them back together using 
mplex (this is something that mytharchive does). I came across someone 
who had patched dvdauthor to avoid this CPU and disk intensive step. One 
of these days, I was going to check it out. If the patch works with DVD 
streams that have no private VBI streams, but does not work with those 
DVD streams that have VBI streams, then either that fact should be 
documented, so people can make intelligent decisions about configuring 
apps like myth, deciding which is more important, the time it takes to 
burn a DVD or capturing CCs or Teletext.

Burning DVDs with CCs is a feature near and dear to my heart. I think 
the best solution would be if the Hauppauge hardware encoders embedded 
CCs in the video stream according to the EIA-608 standard. But they 
don't. I believe Panasonic DVD recording appliances do. If I play back a 
DVD burned by a Panasonic on another manufacturer's player, I will get 
CCs. So they both must implement a common standard like EIA-608. 
Panasonics also produce better video quality with better compression 
than the PVR-150. But they're appliances which are a lot less flexible 
than a computer.

OK, I'm rambling, but maybe it will fuel more dialog on the topic?

Helen

_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Reply via email to