HVR-1600 analog no signal

Just got a pair of hvr-1600 to replace my failing pvr-150s and the analog side seems a no go. They are both 1199 (74301) models and I have compiled what I think is the latest media_build. Did this: git clone git://linuxtv.org/git/media_build.git cd media_build ./build.sh (btw, seemed to work fine in Ubuntu 11.04)

The drivers seem to load fine and the only issue that my untrained eyes can see is that the cards are reporting no video signal. I have not messed with the firmware. The file dates are Nov 2010 for the firmware and seem newer than that I could find at linuxtv (Jun 2010) or ivtv (2008) Here's the log:

I have the reverse problem in Fedora 14 (HVR-1600 model 1388): the analog side works totally fine (at /dev/video0) while I can't get the digital side to tune properly. The digital side has occasionally been able to record in SD and HD, but since the tuning is wrong Mythtv refuses to record, or it records the wrong program. Does your digital side work?

Eric Morgan <gemorgan99 [at] gmail> wrote:

>Hey all, > >Just got a pair of hvr-1600 to replace my failing pvr-150s and the analog >side seems a no go. They are both 1199 (74301) models and I have compiled >what I think is the latest media_build. >Did this: >git clone git://linuxtv.org/git/media_build.git >cd media_build >./build.sh >(btw, seemed to work fine in Ubuntu 11.04)

> Thanks for the reply. I had already tried the s-video input but I'm > not sure I was doing it right. If I cat from /dev/video32 I can't > play the file using vlc. Also, there's this: > > server:~$ v4l2-ctl -i=1 -d /dev/video0 --verbose ^ | Don't put in an '=' sign.

Also with cx18 driver v1.5.0, the YUV /dev/video32 node has the mmap() interface added to it (for tvtime, etc.), which is sort of a major change for /dev/video32. Let's not troubleshoot using /dev/video32, just to eliminate any unknowns with the new functionality.

Just use mplayer on the MPEG /dev/video0 node to view video for testing:

On Fri, 2011-06-03 at 23:01 -0700, Greg Fruth wrote: > I have the reverse problem in Fedora 14 (HVR-1600 model 1388): the > analog side > works totally fine (at /dev/video0) while I can't get the digital side > to tune properly. > The digital side has occasionally been able to record in SD and HD, > but since the tuning > is wrong Mythtv refuses to record, or it records the wrong program. > Does your digital > side work?

MythTV is not a good troubleshooting tool - too many moving parts, so to speak.

Instead, use the basic dvb utilities to create a channels.conf file from the stdout of [dvb]scan and do some basic tests:

Unfortunately my only late model HVR-1600 is in Europe with Hans for worldwide analog signal tuning verification. I don't have one in hand at the moment. (Maybe I'll just go buy another one this week).

> Unfortunately my only late model HVR-1600 is in Europe with Hans for > worldwide analog signal tuning verification. I don't have one in hand > at the moment. (Maybe I'll just go buy another one this week). > > > Regards, > Andy >

Hi Andy,

I've been out of circulation for a while and am just catching up on my list messages now. Any news from Hans on that testing with the 1388?

Also, have you heard anything about the digital tuner on the 1388 being capable of DVB-S as well?

On Sat, 2011-06-04 at 21:34 -0700, Jeff Campbell wrote: > > Unfortunately my only late model HVR-1600 is in Europe with > Hans for > worldwide analog signal tuning verification. I don't have one > in hand > at the moment. (Maybe I'll just go buy another one this > week). > > > > Regards, > Andy > > > Hi Andy, > > I've been out of circulation for a while and am just catching up on my > list messages now. Any news from Hans on that testing with the 1388?

Hi Jeff,

I know Hans received it on the week of 16 May, but informed me on 31 May he hadn't tested it yet.

Hans,

Any notion of when you'll be able to verify non-NTSC-M analog TV standards on the newer HVR-1600?

> Also, have you heard anything about the digital tuner on the 1388 > being capable of DVB-S as well?

Jeff,

Even if the TDA18271 tuner chip can support DVB-S, the CX24228 digital demodulator on the HVR-1600 does not.

There are at least 15 I2C busses in your system. That's alot. I am > going to assume there are a lot of various PCI/PCIe cards and/or USB > peripherials installed in this machine. >

I have the two hvr-1600's and that's it.

Do you have a known good S-Video source hooked up with an active signal > and a known good cable? >

I'm relatively sure the source is good. It was all hooked up to a the same system with a pair of PVR-150's which I assume were going bad (unstable signal, wavy picture). On this setup, one card's tuner was connected to the cable out of a cable box, and the other directly to cable. I wasn't using the box's s-video out. I've hooked both cables directly to a TV and the signal looks good there. I have not tested the s-video out of the cable box but assume it's ok. I'll see if I can find something to hook it to.

There is a bit of splitting going on before the cards see the cable. Perhaps these cards need a bigger signal? Maybe the wavy pictures of the PVR-150's was a drop in signal and not the tuners going bad?

I see you've been reading data from the MPEG device node. Are you > getting a black screen, a grey screen, or (I hope not) a red screen? >

Interestingly, one card shows a black screen (video1) and the other shows the red screen (video0).

Thanks for the pointers! What I'm trying to get working is the unencrypted channels that are available on my terrestrial digital cable, which are evidently QAM-256.

I used "w_scan -fa -A2 -c US -X -o 7" to generate a channels.conf file. w_scan successfully finds all the digital channels I expect to see, both HD and SD. I then use azap to tune, but it seems the audio portion is missing. The "audio pid" that azap reports is 0x0000:

% mplayer /dev/dvb/adapter0/dvr0 MPlayer SVN-r33254-snapshot-4.5.1 (C) 2000-2011 MPlayer Team Can't open joystick device /dev/input/js0: No such file or directory Can't init input joystick mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control.

On Sun, 2011-06-05 at 17:25 -0700, Greg Fruth wrote: > Andy, > > > Thanks for the pointers! What I'm trying to get working is the > unencrypted channels that are available > on my terrestrial digital cable, which are evidently QAM-256.

Yes, from what little I've seen, QAM-64 is not used very much.

Note that re-broadcasts of you local Over-The-Air digital channels may be on the cable as ATSC 8-VSB. Cable companies may choose to not convert them to QAM.

> > I used "w_scan -fa -A2 -c US -X -o 7" to generate a channels.conf > file. w_scan successfully finds all the > digital channels I expect to see, both HD and SD.

I've never used w_scan myself. Please be advised, that unless you have a very recent w_scan, ATSC 8-VSB scanning might have problems. See here for the discussion and fixes, if needed:

You are free to change the PCI latency for the CX23418 (maximum burst of PCI clock cycles the CX23418 is allowed to use the PCI bus segment at a time) to whatever you need using 'setpci'. Most people don't, unless they really need to tune PCI bus performance.

I'll write up something later tonight, if/when I have time. (I usually only have time for about 1 properly researched email answer per day.)

The only thing a user can do immediately, for a red-screen cx23418, is unload the cx18 driver and reload the cx18 driver. (My *speculation*, for when the red screen happens, is that the cx25843 core is not operating due to some race between the cx23418 and cx18 driver when initializing. I *speculate* it is due to intermittent system latencies or transient PCI bus conditions. I truly do not understand the mechanism, as I have only ever encoutered the problem once myself in 4(?) years or so of doing this.)

Note that if cx18-alsa is loaded, cx18-alsa has to be unloaded first. Pulse-audio makes that a PITA, because it holds the device open and respawns when killed.

But sometime around last summer I moved to a new kernel the the red- screen problems went away. I don't know exactly what kernel fixed it, but I see that a config dated Aug 15, 2010 was 2.6.35-gentoo-r1, and I don't appear to have moved to a 2.6.36 series kernel until late December. I'm guessing that 2.6.35+ fixed it, for me.

As I ponder this more, I think it is a cx18 driver problem that userspace mitigates.

The cx18 driver initializes the cx23418 chip and then doesn't load the firmware until somethings opens a device node. On all my systems a daemon queries the device node as soon as it appears, forcing an immediate firmware load.

I wonder if the cx23418's internal processors are just free-running, trying to execute garbage, until the firmware load process starts. If the firmware load comes very late, this might be causing the red screen symptom.

I'll work up a patch to eliminate that possibilty tonight or tommorrow.

I'll try to unloading and reloading drivers tonight. I'll figure out a better way to test the cable signal too.

Any idea what's up with a green screen? When I was originally cat'ing directly from video1 it was black but all the myth recordings are green. I can try to capture with cat again to see if it's black if it'll help... On Jun 7, 2011 8:36 AM, "Andy Walls" <awalls [at] md> wrote:

1. removing all but one capture card from your system (PVR-150 or HVR-1600 doesn't matter at the moment), and see how well that one card performs. Make sure it is away from any disk controller or video graphics cards. (Trying to reduce EMI inside the PC case.)

You might also want to disconnect the coaxial cables and just use a composite or SVideo source for the test. (Trying to eliminate any ground loops.)

I'm just guessing that the PVR-150 problems you described may have been caused by EMI or a grounding problem.

> Any idea what's up with a green screen?

Not really. Since the CX23418 uses YUV (YCrCb) as an intermediate format before MPEG encoding, a memory region filled with 00 00 00 as YUV values would end up as dark green (I think).

The red screen is definitely a bad symptom though.

> When I was originally cat'ing directly from video1 it was black but > all the myth recordings are green. I can try to capture with cat again > to see if it's black if it'll help...

> On Tue, 2011-06-07 at 13:50 -0700, Eric Morgan wrote: > > I'll try to unloading and reloading drivers tonight. I'll figure out a > > better way to test the cable signal too. > > As something that may be worthwhile, you might also wish to try > > 1. removing all but one capture card from your system (PVR-150 or > HVR-1600 doesn't matter at the moment), and see how well that one card > performs. Make sure it is away from any disk controller or video > graphics cards. (Trying to reduce EMI inside the PC case.) > > You might also want to disconnect the coaxial cables and just use a > composite or SVideo source for the test. (Trying to eliminate any > ground loops.) > > I'm just guessing that the PVR-150 problems you described may have been > caused by EMI or a grounding problem. > > > > > Any idea what's up with a green screen? > > Not really. Since the CX23418 uses YUV (YCrCb) as an intermediate > format before MPEG encoding, a memory region filled with 00 00 00 as YUV > values would end up as dark green (I think). > > > The red screen is definitely a bad symptom though. > > > > When I was originally cat'ing directly from video1 it was black but > > all the myth recordings are green. I can try to capture with cat again > > to see if it's black if it'll help... > > Nope. Don't bother. > > Regards, > Andy > > Ok! I played with the system some tonight and took some notes.

o machine was booted with blacklisted cx18 a day or so ago so shut it down. o removed the card with the red screen and left the green screen card in its original slot o booted, still with cx18 blacklisted. o loaded cx18 module and captured from the tuner -> BLACK SCREEN o switched to s-video -> GREEN SCREEN o removed cx18_alsa and cx18 and reloaded -> Same results as 3 and 4. o removed this card and put it in the other slot and booted still with cx18 blacklisted o s-video -> LIGHT GREEN SCREEN o tuner -> RED SCREEN! o removed the cx18 modules and reloaded o s-video -> GREY SCREEN o tuner -> PICTURE! (Doogie Houser <cringe>) o switch back to s-video -> BLACK SCREEN o put card back in other slot and booted blacklisted cx18 and modprobed the driver o tuner -> PICTURE! o s-video -> BLACK SCREEN o removed coax (straight from cable co.) from card to hook up cable box coax to card and screen goes BLACK o Thought to check the input on the cable box. o Actually plugged cable TV coax into cable box so it would have a signal to supply it's s-video out o s-video -> PICTURE!

So, it seems I can get it working with intervention after rebooting. Are people having trouble with the red screen appearing intermittently without being triggered by reboot? I assume this is the big issue you all are working on with this driver/card combo?

Doing a spot of renovating around the house and had to power my server down in case I tripped the wrong breaker. To complicate things, I had done the kernel upgrade from 2.6.38-10-generic to 2.6.38-11-generic but had not rebooted. When done, I powered the machine up and did my customary stopping of mythtv-backend, remove cx18_alsa and cx18 and reloading cx18 but one of my tuners is still red screen.

I pulled the plug completely on the machine in case a complete power down was needed but with no luck. And I have reverted to the 2.6.38-10-generic kernel that was working.

I had been operating since Jun 7 (no reboots :) with no problems.

What's the status of the red screen thing. Is there some workaround? Fix? I had read that there were fixes that were supposed to be included in newer versions of the kernel but no luck here.

> On Tue, Jun 7, 2011 at 3:38 PM, Andy Walls <awalls [at] md>wrote: > >> On Tue, 2011-06-07 at 13:50 -0700, Eric Morgan wrote: >> > I'll try to unloading and reloading drivers tonight. I'll figure out a >> > better way to test the cable signal too. >> >> As something that may be worthwhile, you might also wish to try >> >> 1. removing all but one capture card from your system (PVR-150 or >> HVR-1600 doesn't matter at the moment), and see how well that one card >> performs. Make sure it is away from any disk controller or video >> graphics cards. (Trying to reduce EMI inside the PC case.) >> >> You might also want to disconnect the coaxial cables and just use a >> composite or SVideo source for the test. (Trying to eliminate any >> ground loops.) >> >> I'm just guessing that the PVR-150 problems you described may have been >> caused by EMI or a grounding problem. >> >> >> >> > Any idea what's up with a green screen? >> >> Not really. Since the CX23418 uses YUV (YCrCb) as an intermediate >> format before MPEG encoding, a memory region filled with 00 00 00 as YUV >> values would end up as dark green (I think). >> >> >> The red screen is definitely a bad symptom though. >> >> >> > When I was originally cat'ing directly from video1 it was black but >> > all the myth recordings are green. I can try to capture with cat again >> > to see if it's black if it'll help... >> >> Nope. Don't bother. >> >> Regards, >> Andy >> >> > Ok! I played with the system some tonight and took some notes. > > o machine was booted with blacklisted cx18 a day or so ago so shut it down. > o removed the card with the red screen and left the green screen card in > its original slot > o booted, still with cx18 blacklisted. > o loaded cx18 module and captured from the tuner -> BLACK SCREEN > o switched to s-video -> GREEN SCREEN > o removed cx18_alsa and cx18 and reloaded -> Same results as 3 and 4. > o removed this card and put it in the other slot and booted still with cx18 > blacklisted > o s-video -> LIGHT GREEN SCREEN > o tuner -> RED SCREEN! > o removed the cx18 modules and reloaded > o s-video -> GREY SCREEN > o tuner -> PICTURE! (Doogie Houser <cringe>) > o switch back to s-video -> BLACK SCREEN > o put card back in other slot and booted blacklisted cx18 and modprobed the > driver > o tuner -> PICTURE! > o s-video -> BLACK SCREEN > o removed coax (straight from cable co.) from card to hook up cable box > coax to card and screen goes BLACK > o Thought to check the input on the cable box. > o Actually plugged cable TV coax into cable box so it would have a signal > to supply it's s-video out > o s-video -> PICTURE! > > o reinstalled the 2nd card (so config is the same) > o booted blacklisted still and modprobed > o video0 -> PICTURE! > o video1 tuner -> PINK SCREEN (correctly hooked to cable box) > o video1 s-video -> WHITE SCREEN (correctly hooked to cable box) > o modprobe removed cx18's and reloaded and... > o PICTURE! both cards, tuner and s-video. > > So, it seems I can get it working with intervention after rebooting. Are > people having trouble with the red screen appearing intermittently without > being triggered by reboot? I assume this is the big issue you all are > working on with this driver/card combo? > > Thanks a ton Andy. I really do appreciate the hard work you all do! > > Eric >

>Hi Andy, > >Doing a spot of renovating around the house and had to power my server >down >in case I tripped the wrong breaker. To complicate things, I had done >the >kernel upgrade from 2.6.38-10-generic to 2.6.38-11-generic but had not >rebooted. When done, I powered the machine up and did my customary >stopping >of mythtv-backend, remove cx18_alsa and cx18 and reloading cx18 but one >of >my tuners is still red screen. > >I pulled the plug completely on the machine in case a complete power >down >was needed but with no luck. And I have reverted to the >2.6.38-10-generic >kernel that was working. > >I had been operating since Jun 7 (no reboots :) with no problems. > >What's the status of the red screen thing. Is there some workaround? >Fix? I >had read that there were fixes that were supposed to be included in >newer >versions of the kernel but no luck here. > >Thanks for any help! >Eric > >On Tue, Jun 7, 2011 at 7:07 PM, Eric Morgan <gemorgan99 [at] gmail> >wrote: > >> On Tue, Jun 7, 2011 at 3:38 PM, Andy Walls ><awalls [at] md>wrote: >> >>> On Tue, 2011-06-07 at 13:50 -0700, Eric Morgan wrote: >>> > I'll try to unloading and reloading drivers tonight. I'll figure >out a >>> > better way to test the cable signal too. >>> >>> As something that may be worthwhile, you might also wish to try >>> >>> 1. removing all but one capture card from your system (PVR-150 or >>> HVR-1600 doesn't matter at the moment), and see how well that one >card >>> performs. Make sure it is away from any disk controller or video >>> graphics cards. (Trying to reduce EMI inside the PC case.) >>> >>> You might also want to disconnect the coaxial cables and just use a >>> composite or SVideo source for the test. (Trying to eliminate any >>> ground loops.) >>> >>> I'm just guessing that the PVR-150 problems you described may have >been >>> caused by EMI or a grounding problem. >>> >>> >>> >>> > Any idea what's up with a green screen? >>> >>> Not really. Since the CX23418 uses YUV (YCrCb) as an intermediate >>> format before MPEG encoding, a memory region filled with 00 00 00 as >YUV >>> values would end up as dark green (I think). >>> >>> >>> The red screen is definitely a bad symptom though. >>> >>> >>> > When I was originally cat'ing directly from video1 it was black >but >>> > all the myth recordings are green. I can try to capture with cat >again >>> > to see if it's black if it'll help... >>> >>> Nope. Don't bother. >>> >>> Regards, >>> Andy >>> >>> >> Ok! I played with the system some tonight and took some notes. >> >> o machine was booted with blacklisted cx18 a day or so ago so shut it >down. >> o removed the card with the red screen and left the green screen card >in >> its original slot >> o booted, still with cx18 blacklisted. >> o loaded cx18 module and captured from the tuner -> BLACK SCREEN >> o switched to s-video -> GREEN SCREEN >> o removed cx18_alsa and cx18 and reloaded -> Same results as 3 and 4. >> o removed this card and put it in the other slot and booted still >with cx18 >> blacklisted >> o s-video -> LIGHT GREEN SCREEN >> o tuner -> RED SCREEN! >> o removed the cx18 modules and reloaded >> o s-video -> GREY SCREEN >> o tuner -> PICTURE! (Doogie Houser <cringe>) >> o switch back to s-video -> BLACK SCREEN >> o put card back in other slot and booted blacklisted cx18 and >modprobed the >> driver >> o tuner -> PICTURE! >> o s-video -> BLACK SCREEN >> o removed coax (straight from cable co.) from card to hook up cable >box >> coax to card and screen goes BLACK >> o Thought to check the input on the cable box. >> o Actually plugged cable TV coax into cable box so it would have a >signal >> to supply it's s-video out >> o s-video -> PICTURE! >> >> o reinstalled the 2nd card (so config is the same) >> o booted blacklisted still and modprobed >> o video0 -> PICTURE! >> o video1 tuner -> PINK SCREEN (correctly hooked to cable box) >> o video1 s-video -> WHITE SCREEN (correctly hooked to cable box) >> o modprobe removed cx18's and reloaded and... >> o PICTURE! both cards, tuner and s-video. >> >> So, it seems I can get it working with intervention after rebooting. >Are >> people having trouble with the red screen appearing intermittently >without >> being triggered by reboot? I assume this is the big issue you all >are >> working on with this driver/card combo? >> >> Thanks a ton Andy. I really do appreciate the hard work you all do! >> >> Eric >> Hi Eric,

My hypothesis is that the CX23418 firmware needs to be loaded shortly after bringing the chip up.

Currently the driver bring the chip up and defers firmware loading; which probably leaves the chip executing random garbage that might screw up registers in the integrated CX25843.

I have had no time to implement that change and test it. However you can initiate the firmware load from userspace by opening a device node and performing an operation with v4l2-ctl or ivtv-tune or cat shortly after the driver loads. Note this "workaround" probably won't help with the newest HVR1600s that have the new analog tuner with the long calibration delay.

> > Hi Eric, > > My hypothesis is that the CX23418 firmware needs to be loaded shortly after > bringing the chip up. > > Currently the driver bring the chip up and defers firmware loading; which > probably leaves the chip executing random garbage that might screw up > registers in the integrated CX25843. > > I have had no time to implement that change and test it. However you can > initiate the firmware lohttp://www.google.com/ad from userspace by opening > a device node and performing an operation with v4l2-ctl or ivtv-tune or cat > shortly after the driver loads. > Note this "workaround" probably won't help with the newest HVR1600s that > have the new analog tuner with the long calibration delay. > > Regards, > Andy >

I was able to get running again by re-compiling the latest drivers from git. I don't have high confidence yet since my older drivers were working but then wouldn't. Keeping fingers crossed.

On Sun, 2011-09-25 at 12:28 -0700, Eric Morgan wrote: > Hi Eric, > > My hypothesis is that the CX23418 firmware needs to be loaded > shortly after bringing the chip up. > > Currently the driver bring the chip up and defers firmware > loading; which probably leaves the chip executing random > garbage that might screw up registers in the integrated > CX25843. > > I have had no time to implement that change and test it. > However you can initiate the firmware > lohttp://www.google.com/ad from userspace by opening a device > node and performing an operation with v4l2-ctl or ivtv-tune or > cat shortly after the driver loads. > Note this "workaround" probably won't help with the newest > HVR1600s that have the new analog tuner with the long > calibration delay. > > Regards, > Andy > > > > I was able to get running again by re-compiling the latest drivers > from git. I don't have high confidence yet since my older drivers were > working but then wouldn't. Keeping fingers crossed.

Hi,

Sorry for the late reply on the firmware question.

I don't have high hopes for the new driver "making it all better". Since the red-screen, if it happens, happens at boot. A power cycle is needed to clear it.

This really indicates the cx18 driver is racing with the CX23418 hardware or with the cx18 driver itself somehow. Nothing has changed with the driver init sequence in a long time.

> Thanks for the help again...

If I find time to change the driver to load the firmware early, I'll email that I need a patch tested. Hopefully sometime in October....