ETH6 Low SNR on two channels only

[tzr916]

ETH6 with v14_4_6_21 firmware (refuse to try latest based on some reports here).
Win7 64 bit
ETH and WMC PC plugged into same Gigabit switch
One Comcast cable line into rack with one -3dB splitter: side A to ETH / side B to internet modem.

Signal levels/SNR on modem and ETH are IDEAL except for two SD channels 367 & 369 (both in the 135000 frequency range). This results in WMC errors like:
beginning of recordings fail, WMC goes to next available tuner and success.
or
recording begins normally, but a few times in the recording there are bad spots (missing video, weak tv signal error).

When it fails at the beginning and chooses another tuner, I can see the SNR, on the first tuner it tried to use, was really low (like 29dB or 30dB). I got home today and caught it happening in real time. Error message on the screen said Weak Tv Signal. So I brought up the ETH summary page and the SNR was actually 29dB on tuner #5 (see image below):


Notice how all the tuners have good SNR! Strange, huh? And after taking that screenshot, I changed the channel, then went back to channel 369 and the SNR was back up to normal! So weird... Also, it doesn't matter which Tuner WMC tries to use, almost every time it tries either of those channels it messes up. I was previously using a special drop amp and a few splitters before but the upstream power was too hot for my internet modem, it kept resetting and killing the internet, so I scaled back to one simple splitter. That's when this issue started with the two channels.

Current modem levels:



So how do I get my ETH numbers and modem upstream levels good without F'ing up my ETH Signal Levels? Is there anything Comcast can do in this situation?

[tzr916]

Nevermind... I should have double checked the connections out on the side of the garage, found and extra splitter going to "nowhere". Removed and have decent numbers now. Will keep an eye on recordings on the two channels.

[JohnW248]

Nevermind... I should have double checked the connections out on the side of the garage, found and extra splitter going to "nowhere". Removed and have decent numbers now. Will keep an eye on recordings on the two channels.

This is one of the miracles of QAM. You can create a notch filter by a bad cable, a crimped cable, a nail in a cable, etc. A dead short might kill everything up to OOB frequencies and above will be fine.

Glad you found the problem which is why I preach make sure the RF plant is tight and clean first.

[tzr916]

Might have spoken too soon. Puzzled

Looking at channel 367 recording right now and the SNR is varying between 29-32 dB. Doesn't seem any better than before I took out the "extra" splitter. I will check the recording later to see if it's got any bad spots.

All other channels are still solid at 37-38 dB SNR.
Modem numbers - Downstream SNR 37dB, Power +7dBmV and upstream power 47dBmv

Might end up putting the drop amp with passive return back in tomorrow...

[tzr916]

Still having problems. I have tried all sorts of combinations of splitters, and two different amps (active return and passive return). Last thing I can possibly do is run a brand new cable from the point of entry to my rack.

[tzr916]

Guess I have to open a ticket with Ceton.

I have replaced:
50ft shielded RG6 coax from POE to rack
splitter to keep signal power between +12 to -12 dBmV on ETH
amp to keep modem upstream power from getting too high
2x barrel connectors
3x 5ft coax patches between splitter/amp/ETH/modem

Still getting WMC errors popping up saying "not recorded - no signal" and "partial recorded - weak/no signal" ONLY on those two channels.

SNR on those two channels can be 30-35dB, while ALL other channels are up at 38dB.

[JohnW248]

It looks like there might be a problem with 135 mH....maybe there is some old "notch" filter from a by gone era when the system used those to take out pay channels to non-subscribers, or line amp problem, etc. I'd start with the cable company and get someone that can do a spectrum scan and see if there is a dip at that point. There might be a tuner issue, but I'd start with the RF first and rule that out. BTW the signal level and SNR are not constants. They will vary over time/temp. So if you watch over a full day you'll see the signal levels change and the SNR change although what you're seeing is way off from what would be expected from the rest of the signals.

[tzr916]

Thanks. I just wonder why this only recently started happening? I have had this setup for more than 2 years and not seen this bad of a situation on these two channels. Just the normal sporadic ETH reboots.

Looks like my ETH6 is DEAD. Meanwhile modem is up and running with good numbers... Tried rebooting ETH multiple times. Tried straight through coax, no splitters, no amps.... Can't get signal now at all, no channels.

I woke up to six "Program not recorded - there was no tv signal" error messages in WMC for channel 367. And this is what my ETH summary looked like:



And the ETH log looked very strange:

Jan 5 18:32:20 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:32:20 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:32:20 ocur[21]: ocur: [3] Carrier lock is 1
Jan 5 18:32:20 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:32:21 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:32:21 ocur[21]: ocur: [3] Carrier lock is 0
Jan 5 18:32:23 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:32:23 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:32:23 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:32:24 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:32:24 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:32:25 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:32:25 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:32:26 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:32:27 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:32:28 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:32:28 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:32:28 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:32:29 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:32:29 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:32:29 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:32:30 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:32:30 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:32:31 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:32:31 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:32:33 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:32:33 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:32:34 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:32:34 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:32:34 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:32:35 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:32:35 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:32:36 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:32:36 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:32:37 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:32:37 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:32:38 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:32:38 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:32:39 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:32:41 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:32:41 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:32:42 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:32:43 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:32:43 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:32:43 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:32:44 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:32:44 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:32:44 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:32:45 ocur[21]: ocur: [3] Carrier lock is 1
Jan 5 18:32:45 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:32:46 ocur[21]: ocur: [3] Carrier lock is 0
Jan 5 18:32:46 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:32:46 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:32:47 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:32:47 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:32:47 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:32:48 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:32:49 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:32:50 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:32:50 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:32:51 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:32:52 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:32:52 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:32:52 ocur[21]: ocur: [3] Carrier lock is 1
Jan 5 18:32:52 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:32:54 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:32:54 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:32:54 ocur[21]: ocur: [3] Carrier lock is 0
Jan 5 18:32:55 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:32:55 ocur[21]: ocur: [3] Carrier lock is 1
Jan 5 18:32:55 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:32:56 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:32:56 ocur[21]: ocur: [3] Carrier lock is 0
Jan 5 18:32:57 ocur[21]: ocur: [3] Carrier lock is 1
Jan 5 18:32:57 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:32:58 ocur[21]: ocur: [3] Carrier lock is 0
Jan 5 18:32:58 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:32:59 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:00 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:33:00 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:01 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:33:01 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:33:02 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:33:02 ocur[21]: ocur: [3] Carrier lock is 1
Jan 5 18:33:02 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:03 ocur[21]: ocur: [3] Carrier lock is 0
Jan 5 18:33:03 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:04 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:04 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:33:05 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:05 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:33:07 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:08 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:33:08 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:09 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:33:09 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:33:10 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:33:10 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:33:11 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:33:11 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:33:11 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:33:12 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:33:12 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:33:12 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:33:13 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:33:13 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:33:14 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:33:14 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:14 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:33:15 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:33:15 ocur[21]: ocur: [3] Carrier lock is 1
Jan 5 18:33:15 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:33:16 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:33:16 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:33:16 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:33:16 ocur[21]: ocur: [3] Carrier lock is 0
Jan 5 18:33:16 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:17 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:33:17 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:33:17 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:33:18 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:33:20 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:33:20 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:33:20 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:21 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:33:21 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:33:21 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:22 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:33:22 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:23 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:33:23 ocur[21]: ocur: [3] Carrier lock is 1
Jan 5 18:33:24 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:33:24 ocur[21]: ocur: [3] Carrier lock is 0
Jan 5 18:33:24 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:25 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:33:26 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:33:27 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:28 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:33:28 ocur[21]: ocur: [3] Carrier lock is 1
Jan 5 18:33:28 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:29 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:33:29 ocur[21]: ocur: [3] Carrier lock is 0
Jan 5 18:33:30 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:33:31 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:32 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:33:33 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:33:33 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:33:33 ocur[21]: ocur: [3] Carrier lock is 1
Jan 5 18:33:33 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:34 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:33:34 ocur[21]: ocur: [3] Carrier lock is 0
Jan 5 18:33:34 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:35 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:36 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:33:36 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:33:37 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:33:37 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:33:39 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:33:39 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:33:41 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:33:41 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:33:44 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:33:44 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:33:44 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:33:45 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:33:45 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:33:45 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:33:45 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:46 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:47 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:33:48 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:33:48 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:33:48 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:33:49 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:33:49 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:33:49 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:50 ocur[21]: ocur: [0] Carrier lock is 1
Jan 5 18:33:50 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:51 ocur[21]: ocur: [0] Carrier lock is 0
Jan 5 18:33:51 ocur[21]: ocur: [5] Carrier lock is 1
Jan 5 18:33:53 ocur[21]: ocur: [2] Carrier lock is 1
Jan 5 18:33:53 ocur[21]: ocur: [3] Carrier lock is 1
Jan 5 18:33:53 ocur[21]: ocur: [5] Carrier lock is 0
Jan 5 18:33:54 ocur[21]: ocur: [3] Carrier lock is 0
Jan 5 18:33:54 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:55 ocur[21]: ocur: [2] Carrier lock is 0
Jan 5 18:33:56 ocur[21]: ocur: [4] Carrier lock is 0
Jan 5 18:33:57 ocur[21]: ocur: [1] Carrier lock is 1
Jan 5 18:33:57 ocur[21]: ocur: [3] Carrier lock is 1
Jan 5 18:33:57 ocur[21]: ocur: [4] Carrier lock is 1
Jan 5 18:33:58 ocur[21]: ocur: [1] Carrier lock is 0
Jan 5 18:33:58 ocur[21]: ocur: [4] Carrier lock is 0

[tzr916]

Collected Ceton Dignostic Info.

Installed latest firmware on ETH. No change. All channels, no signal yet modem is working.

Collected Ceton Diagnostic Info again.

Called Comcast to verify my cable card and they are actually playing a pre-recorded message that they are currently having a Tv outage in my area and expect to be normal 3 hours from now.... So maybe THIS full outage is not my hardware. Shall see if the bad signal on the two channels remains after service is restored.

[tzr916]

Just to clarify- updated ETH firmware from v14_4_6_21 to v14_10_3_163.

Comcast tv service has been restored.

Signal levels on ETH appear to be normal again. I set recordings on the two bad channels and they both completed without issue. Watched the SNR while recordings in progress and they stayed up around 37-38dB.

Holding off on submitting ticket to Ceton for now.

[JohnW248]

Now you should update the FW to 15.1.13.152 (see thread on this forum for link to that FW isn't it isn't offered by the diagnostic tool yet). This FW has the revision to omit the CGMS compliance which has caused many people trouble with programs that are supposed to be clean copy freely. Often some old commercial will have some CGMS in a control line that got moved to digital and resulted in the problem. Both SD and Ceton have removed the requirement to obey based on an engineering change that Eric submitted to cable labs.

[tzr916]

Ya, I have been reading that thread and kinda scared to try it, due to the numerous "bad experience" comments. I have never had any improper copy flag issues, AFAIK. I'll probably give the version I just loaded at least a few days and then maybe think about giving that new version a try.

[tzr916]

It looks like there might be a problem with 135 mH....maybe there is some old "notch" filter from a by gone era when the system used those to take out pay channels to non-subscribers, or line amp problem, etc. I'd start with the cable company and get someone that can do a spectrum scan and see if there is a dip at that point. There might be a tuner issue, but I'd start with the RF first and rule that out. BTW the signal level and SNR are not constants. They will vary over time/temp. So if you watch over a full day you'll see the signal levels change and the SNR change although what you're seeing is way off from what would be expected from the rest of the signals.

Happened again this morning. I am ruling out old notch filter, old line amp, SNR varying due to temp, and my coax wiring/splitters/amps. Yes, SNR can vary one or maybe two dB due to temp,but not 10dB and if it were any filter or cable issue, it just doesn't make any sense that the first time WMC grabs the tuner SNR is 29dB then it errors out and grabs another tuner and SNR is suddenly 39dB.

Maybe it's time for me to buy a backup ETH6, throw it into my system and see what happens.

[tzr916]

Just to clarify- updated ETH firmware from v14_4_6_21 to v14_10_3_163.

All recordings and live tv since this firmware update have sporadic pixellation, audio drop outs, picture freeze. Going to try v15.1.13.152 but have a feeling I will be going back to v14.4.6.21

[tzr916]

Updated ETH to v15.1.13.152 and pixellation seems to be gone. Unfortunately had no effect on my very low SNR on channels 367/369. I have opened ticket with Ceton. So far, they say it is cable provider issue.

Can anyone explain how Tuner X has SNR of 32dB and AT THE SAME TIME, Tuner Y has SNR of 38dB (on the same channel)???

How can that be a cable provider issue?

[JohnW248]

The SNR is a function of the incoming signal and not the tuner. If you take tuner X with a SNR or 30 dB and retune it to signal XXY you'll see the SNR change. That's why I think it is a function of the frequency of the channel and something in the line at that frequency. RF at higher frequencies does non-logical things. For example you can drive a nail through the COAX and it will continue to function but at some frequencies it won't work...why? because that nail has formed a capacitance and forms a LC filter that only works at a certain frequency which is a function of the cable length between your tuner and the cable problem. (After all a capacitor is just two plates with an electrolyte in between the plates and in the case of the nail the two plates are the conductor center and the shield. That's how cable companies and telephone companies can find the location of a cable fault.) There are also dip filters that were used in the analogue days that notched out movie channels and were installed outside the subscriber home. When the subscriber ordered the channel, a tech was dispatched to remove the trap. These things still are out there from the old NTSC days and cause a number of problems. That's why you need to get a GOOD Tech from Comcast and explain the frequency you're having trouble with and let them see what their spectrum meter shows for that channel.

[tzr916]

Talked to chat earlier this morning. Setup tomorrow afternoon for comcast to come out. Hopefully he can find and kill the gremlins.

[tzr916]

Using ceton webpage, set 4 tuners all to channel 367. If you look at the capture it clearly shows how all tuners have good SNR except Tuner #3.

How can this be a provider issue???



I even pressed STOP on Tuner #3, waited a few seconds and started again. Still very low SNR.

[JohnW248]

Manually tune all six tuners to that channel from the web gui (the tuning will still register signal and snr after showing stopped) and then do a diagnostic scan and send that to Ceton along with a sap shot of the status page you supplies.

For a quick "fix" while waiting for a reply, go into MC and open the guide, right click on channel 367 and choose edit channel and then choose edit sources and then uncheck that tuner number and save and save. MC won't use that tuner when tuning that channel.

But that test make it look like it is an issue with that tuner (does that tuner work for other channels? is 367 the only one?)

[tzr916]

This test is exactly what Ceton requested- Set all tuners to one channel and captured diagnostic. Sent last night. Waiting for reply.

As I have observed many times:
-the very very low SNR happens no matter which tuner is selected.
-the very very low SNR happens only for channels 367 & 369.

another test of all tuners, here there are two tuners with very very low SNR: