Tuning Adapter status: "waiting for channel map". WHY??

[DSperber]

Spectrum SoCal, many channels delivered via SDV (requiring tuning adapter), many not (can be tuned simply with coax connected to Ceton). Two HTPC Win7 machines, (1) "production" Lenovo M910t with Ceton InfiniTV6 PCIe and tuning adapter, (2) "secondary" ASUS Z170-Deluxe with Ceton InviniTV6 ETH and tuning adapter.

Because of the two main "TV WMC nodes" in my house (requiring two coax runs to the two HTPCs) I have a primary splitter dividing the outside feed into the house. And many years ago Spectrum added an in-line amplifier to the primary coax cable (before the primary splitter), so that both feeds were sufficiently strong (since there were other downstream splitters for phone and internet).

Machine (2) Z170 is currently unable to tune any SDV-delivered channels, because the tuning adapter is not being initialized successfully for some reason. Instead, the Tuning Adapter tab of the web browser GUI shows "waiting for channel map" (and no channels or maps loaded) although everything else indicates 100% success.



In contrast, Machine (1) M910t works perfectly (almost... see below) as far as the tuning adapter is concerned. No problem tuning all SDV-delivered channels. And of course the Tuning Adapter tab of the web browser GUI looks perfect.



That's the problem. So is "waiting for channel map" a software problem on the Z170? Seems unlikely. Nothing at all has changed.

So if it's a hardware problem, what might it be? The tuning adapter on Z170 has been replaced but with no effect. Could possibly be a hardware malfunction with the Ceton ETH??

I had Spectrum out here for several hours today, trying to shoot the "waiting for channel map" problem along with another strange anomaly: channel 101 (USA, which is NOT SDV) can no longer be tuned at all on the M910t machine. And channel 101 can just barely be tuned on the Z170 (WMC keeps trying all 6 tuners until it finds one that works or they all fail, and almost always finds at least one that works... but tuner failures on channel are occurring all the time). They investigated the main feed from the outside, and determined it was VERY HOT signal strength. They've opened a ticket with outside maintenance line people, to get this addressed.

In response to the discovery of the "hot signal" he removed the in-line amplifier, saying it was obviously not needed and perhaps could be overloading both the tuning adapters and the Ceton tuners... perhaps explaining the channel 101 anomaly. This made no difference on M910t which still can't tune channel 101, and did improve Z170 which now seems to find a working tuner after only 2-3 tries (still not perfect, but much better than before since at least it "succeeds").


The Z170 machine was originally built in 2017 using an internal Ceton 6-tuner PCIe card until mid-2020 when the Ceton ETH was acquired (in order to support my project of having WMC running successfully in a VMWare Win7-VM guest machine under Win10 host). But normally the Z170 machine is booted to Win7, and has been running flawlessly that way for the past 4 years, originally with the Ceton PCIe card and then later with the Ceton ETH tuner, and always with the tuning adapter. Until just recently with this new "waiting for channel map" symptom.

I only began noticing both of these major problems this week, with the start of the Olympics and many hundreds of programs to be recorded across the 6 channels of the NBC family. It was the inability to record channel 101 (USA) on M910t that prompted me to try and deal with this problem by reactivating Z170 specifically to record just the Olympics programs airing on 101. So how long the "waiting for channel map" symptom on Z170 may actually have been present, I don't know. For sure it's certainly there now.

I've tried the usual kick-start workarounds, like reinstalling the 1088 Ceton software. No effect.

When time permits (and this may not occur until after the Olympics are over) I plan to swap the tuning adapters currently in use for the Z170 and M910t. If the "waiting for channel map" persists with the Z170 using the previously normal tuning adapter from the M910t, while the previously failing Z170 tuning adapter now works perfectly when used on the M910t, well that totally eliminates the tuning adapters as the possible hardware culprit. It would now likely point to either the Ceton ETH or some cabling issue relating to the Z170.

I'm desperately all ears, hoping somebody out there has similar experience with tuning adapters and whatever might be the underlying cause for "waiting for channel map"?

And how about that channel 101 mystery? Without the in-line amplifier, the M910t node (which has two splitters) produces a signal strength of about -11.5db (which is very low) and SNR of about 39db (which is very good). I'm going to try putting the in-line amplifier into this second split coax path out of the primary splitter, as this path with its two additional splitters needs a boost. Perhaps that may coax channel 101 back to "normalcy" for the M910t. As to why it's just channel 101, well that may be a Spectrum-related distribution problem on that channel frequency that I have no control over.

All of this may relate to the "hot signal" coming from the outside, which may have happened due to Spectrum outside work over the past 6 months.

Really distressing, as I have been running many WMC machines with Ceton 4-tuner and 6-tuner cards over the past 11 years since 2010, all truly flawlessly until now.

NEED HELP OR IDEAS!!

[DSperber]

Could it maybe be one or both of the two splitters downstream on the M910t coax branch out of the primary splitter?

Maybe something about the frequency of channel 101 specifically that is being interfered with by the two splitters? Not entirely unreasonable a thought.

Perhaps if I try changing one (I could see if one of them was "non-professional") because I have the splitter installed by Spectrum this afternoon at the Z170 (trying to solve the "waiting for channel map" problem) when instructed to do so by the cablecard tech specialist. Surely that one is for sure usable to replace one of the two involved with the M910t.

I will examine those two splitters, just to see what they are.

[DSperber]

Might the "waiting for channel map" have something to do with the ethernet connectivity of the Ceton ETH?

I say that because at the Z170 node I only just recently replaced a Netgear GS105 switch plus Netgear WNDR4300v2 router (running in Access Point mode, to provide strong WiFi to the vicinity area) with a larger GS108. While the Ceton ETH is connected to the tuning adapter via USB, it is also connected to the PC via ethernet LAN. I can't see how any of this could explain "waiting for channel map" but perhaps it's indicative of an ethernet issue of some kind.

I'm really just grasping at straws, trying to imagine what's been changed in the recent past which might explain why suddenly "waiting for channel map" is the status. What could either trigger or prevent or block the next step in the handshake of the tuning adapter with Spectrum head-end?

[DSperber]

And how about that channel 101 mystery? Without the in-line amplifier, the M910t node (which has two splitters) produces a signal strength of about -11.5db (which is very low) and SNR of about 39db (which is very good). I'm going to try putting the in-line amplifier into this second split coax path out of the primary splitter, as this path with its two additional splitters needs a boost. Perhaps that may coax channel 101 back to "normalcy" for the M910t. As to why it's just channel 101 that is extra picky and sensitive, well that may be a Spectrum-related distribution problem on that channel frequency that I have no control over.

Well, I appear to have emerged victorious on this one!

As my intention described above, I put back the in-line amplifier (rated at +10db) but this time only on the primary splitter coax output branch going to the M910t. That path goes through two more splits until arriving at the input of the tuning adapter and from there then out to the Ceton PCIe card. I have the DTA/Ceton in series, not as separate outputs of yet another splitter.

Anyway, the tuned channels now show a signal strength of -0.7db, somehow more than 10db higher than the -11.7db they were at when the amplifier in front of the primary splitter was completely removed. I can't explain why the +10db boost is not split in some proportional way when passing through the two additional splits on the way to the DTA/Ceton, but whatever the explanation it now shows -0.7db for tuned channels in the Ceton browser GUI. And that seems to be a very good level.

And, miraculously, channel 101 has returned! And not just hit-or-miss and maybe-it-will fail. Seems to be 100% reliable again, like it always was, and like all other channels always are.

So it may be that the particular frequency of channel 101 is uniquely sensitive to signal strength being either much too low or much too high. And apparently around 0db is the "sweet spot".

At least that's how things look right now, on M910t. I've already reactivated channel 101 Olympics recordings and it started right up, without incident. So fingers crossed this is the explanation, and also the solution. And if so, then I'll probably have to deal with things changing if Spectrum maintenance returns in a few days to correct some outside street level to get it back in spec. That must also be the original fairly recent "change" which occurred outside of my control, and which started all of this "no tuner" instability (not just on 101, but on other channels mostly of the SDV-delivered variety). I'll bet it overloaded the tuning adapter as well, which could be why SDV channels also failed with "no tuner".

Anyway, fingers crossed that I've got it solved and fixed, and that stability has returned with 0db signal strength (again, 39db SNR).

Now if I could only figure out "waiting for channel map".

[unclebun]

What do the lights on the tuning adapter indicate? If it's not locking onto the signal and interacting with the network, WMC will never get a channel map.

More than likely there is a problem with the splitters on the way to the tuner that had the problem. You alleviated it with the signal booster, but the other splitters might need replacement. Depending on the types of devices fed by those splitters, you might benefit from the use of asymmetric splitters.

[DSperber]

To answer your questions:

(1) As far as the lights on the Z170 TA (connected via USB cable to the Ceton ETH network tuner), the amber light is now on solid. This is the light that blinks for almost 7 minutes until "locking" is successful, after which it goes solid.

However there is also a red light next to the amber light. Once the amber light stops blinking and goes solid, the red light now blinks once every 10 seconds or so. It seems likely that this is an error indicator of some type, which corresponds to the "waiting for channel map" external symptom. And of course, on the M910t TA (connected via USB cable to the PC inside of which the Ceton PCIe card is installed) there is only the solid amber light. No blinking red light.

Any idea what the blinking red light might be trying to communicate? I think it means "incomplete command in progress", most probably a request from the Ceton ETH for the channel map to be downloaded. And something is preventing that from successfully completing, on that Z170 PC and with that Ceton ETH and with any tuning adapter. Some piece of hardware, most likely, is no longer working properly.

(2) The cable topology to the Z170 only passes through the one primary splitter, one output of which feeds the M910t node (internet, phone and Ceton PCIe TV) and the other output of which feeds the Z170 node (Ceton ETH TV). That second coax branch to the Z170 goes right into the DTA, and the output of the DTA goes right into the Ceton ETH. And Ceton ETH connected via USB cable to the DTA, and via ethernet cable to the 192.168.1.1 LAN gateway router, where it has an IP address of 192.168.1.10. Z170 is also ethernet-connected to the LAN where it has an IP address of 192.168.1.26.

Originally, there was an in-line +10db amplifier between the main coax coming into my home and that primary splitter. That amp has now been removed, so the main coax coming into my home now goes directly into that primary splitter. And that splitter output coax branch going to the Z170 TV-only node does NOT go through any other splitter, but simply goes directly into the DTA->CetonETH.

And as I posted above overnight, I've reinserted the +10db amplifier into a new location, right at the output coming out of the primary splitter that then goes to the M910t phone/internet/TV node. So its 10db boost is applied before both of the two downstream splitters which occur later on that branch. Use of the amp in this location is what has now produced 0db signal strength for the Ceton PCIe, and thankfully return of "normal tunability" to channel 101. But this whole coax branch is for the M910t and its working perfectly DTA. It is unrelated to the other coax branch which goes to the Z170 and its problematic "waiting for channel map" DTA with the blinking red light.

[unclebun]

I have a feeling the issue lies between Spectrum and your tuning adapter. It used to be possible to send a refresh signal to your equipment via their support website, but I just looked for it and it seems to not be there any more. Apparently they have moved that functionality into the My Spectrum App for the phone. As well as disconnecting the USB and power to it for 30 seconds and then reconnecting it to reboot it. Apparently on the app you can see all your connected devices and whether they are functioning correctly.

You could also look on the Ceton diagnostic app on the computer to see what it is receiving from the tuning adapter.

But if a refresh from Spectrum doesn't get the flashing light to stop, I'd take the tuning adapter in to your local Spectrum store and trade it for a new one.

[DSperber]

Not surprisingly, I've pulled cables (ethernet, coax, USB, power) many times in hopes of kick-starting something. No success.

Also, Monday afternoon Spectrum was here for several hours, but with little success. I did request that if he had an MTR-700 DTA on the truck that I'd like to replace the one I had. He did have a "brand new" one and we swapped it. Unfortunately it made no difference, and I still have "waiting for channel map" status.

Now interestingly, it appears that the Ceton Diagnostics utility is engineered separately and differently from the web interface of the Ceton ETH/PCIe tuner itself. So, while the web interface claims that the tuning adapter is "waiting for channel map", the diagnostics utility shows that its actually successfully received the channel list for 1542 channels:



And just as interestingly, I can actually tune to an SDV channel (e.g. 406, as shown in the screenshot) through the diagnostics utility. In contrast, the web interface for the tuner itself cannot resolve any channels.

I've tried running WMC from my Win10/VMWare/Win7-VM environment which always previously worked and is completely separate and independent from the true Win7 side of things, and it shows the same "waiting for channel map". This suggests it's NOT some recent issue in my genuine Win7, or BitDefender, or software.

I've gone ahead and purchased a brand new Ceton ETH on eBay. Can't hurt to have a spare anyway, but this will allow me to see if it's a failing ETH which is responsible that would be fixed with a new ETH

I've also purchased a new true USB-B to USB mini-A cable, to replace the adapter plus cable that I'm currently using. Again this really shouldn't be relevant, but who knows.

I've got some old "system image" backups, going back both a few months and a few years (even before replacing my PCIe with the ETH). I can always experiment with them, just to see if somehow they make a difference.

[DSperber]

Latest attempt at kick-starting the channel map download... I worked with Spectrum cablecard support today. On the off-chance that somehow the cablecard was involved in preventing the channel map from downloading, I requested that he re-pair the cablecard to the host. So he did that, in two steps first UN-PAIRING and then RE-PAIRING.

Unfortunately, like everything else I've tried up until now it also had no effect. Still shows "waiting for channel map".

[DSperber]

Today's steps: take the "new" TA installed by Spectrum on Monday along with the current longtime working cablecard back to the Spectrum store, to both be replaced. The hardware version on the Monday "new" TA was only 256 (probably been in his truck for years), which hasn't been "current" for many years. Current hardware version is 258. Certainly the new one I got from the store today is 258, so that's good.

However I am now unable to "validate" the new cablecard. The new TA seems fine (both downstream and upstream status is locked and complete, but once again TR Status is "waiting for channel map".

Tuning adapter is once again solid amber light (good) but red light blinking every 10 seconds (bad). I've now inspected the "log" in the Ceton web interface, and there's definitely indication of failure. The blinking red light (which was NOT on and blinking earlier this evening, until I began to try unsuccessfully to get the new cablecard validated), probably corresponds to what shows up in the log as "tuning denied - RF receiver busy". Earlier when I looked at the log (before most recent reboot) I saw a similar message but this one said something like "tuning denied - Binding in progress" or something about what is probably the attempted validation of the cablecard.

The log shows that the channel map has actually been delivered, but something about its verification has failed. Interestingly the Ceton diagnostic utility says that the channel list of 1303 channels has been received. Clearly the diagnostic utility is coming through some side door different than the primary drivers and web interface use. But that number of 1303 channels also shows up in the Log, so again it looks like the ETH is doing something but unsuccessfully.

I've now changed every external piece of hardware and cable that I can, all with no change. The log certainly is revealing. The "waiting for channel map" is simply their naming of where the initialization in the driver happens to be.

I have a second Spectrum tech coming out this evening with two more M-1 cablecards, on the off-chance that the new one I picked up today actually is defective. We shall try to get one of them validated, to at least get past that issue. But quite honestly I think it must be the final remaining as-yet un-swapped hardware item in the system, i.e. the Ceton ETH itself which must have gone south on me. Thankfully the 100% brand new sealed one I found on eBay will be here on Monday. I hope I can remember how to go through the installation steps. I think I have to go through the whole "TV Signal" process in WMC, as I recall I had to do when I originally replaced my Ceton PCIe with this Ceton ETH.

So maybe tonight we'll resolve the new cablecard validation failure problem with one of the two new ones arriving with Spectrum this evening. Otherwise, maybe this is just a second strong symptom pointing to the "death" of my Ceton ETH (into which the cablecard which cannot be validated is inserted) as being responsible for now multiple different symptoms of some kind of a hardware failure.

Perhaps there's something wrong with the USB interface in the Ceton ETH, preventing it from communicating properly with the TA. The Log shows indications of some failures relating to trying to "reset USB". I do also have that brand new single 2-ended USB cable also arriving on Monday which is Type-B at one end (for the TA) and mini-A at the other end (for the Ceton ETH). No more combination of (a) mini-A to Type-A (F) adapter, and (b) Type-A to Type-B cable. I don't think this is the problem, but it can't hurt to swap EVERYTHING.

I guess Monday is the big day.

Thankfully I've still got my "production" HTPC (with its Ceton PCIe card inside) still operating properly, so that at least my Olympics recordings are still continuing.

[DSperber]

Just a status update for this ongoing saga:

(1) I had been unable to get the new cablecard "validated" which I'd obtained Thursday afternoon at the Spectrum store, despite being on the phone with two different cablecard department phone tech reps. So they had scheduled another human tech to come out to my home on Friday evening, to hopefully be able to resolve the problem.

Well, the human tech did show up Friday evening, but even though he was on his phone talking to his inside head-end counterpart was still unable to get the card "validated". Then the head-end guy asked for a repeat of both HOST and DATA values to be read to him (even though he'd obviously must have asked that to start their conversation), and amazingly it turns out the DATA value had either (a) not been provided correctly in the first place, or (b) not been entered with the proper procedure and code in their system which ties "HOST and DATA" to the cablecard. And of course I had already gone through the same steps multiple times with both of the cablecard phone techs I had talked to for 2 days and who also were unsuccessful in getting validation to complete.

Nevertheless, regardless of whichever explanation was true or important, finally the human tech in my house and the head-end guy on the phone realized the DATA value had been provided/entered incorrectly, AND CORRECTED IT "correctly this time" into whatever is the correct system and with whatever is the correct system code/procedure. Presumably it truly now was finally in their system correctly. Then I was asked to power-cycle the Ceton ETH, and sure enough when it came back up the new cablecard HAD BECOME VALIDATED!! Yay!! (NOTE: DATA is important, so be sure your phone tech guy truly knows how to enter it properly into their correct SECOND SYSTEM which handles that information!)

(2) Nevertheless, even with this second and now totally validated cablecard I still showed "waiting for channel map" in the Ceton web browser, along with a LOG that showed and suggested obvious problems (likely hardware caused) AFTER obviously getting the channel map completely properly absorbed, handled and validated. So "waiting for channel map" was really a reflection of a problematic "current state of things", rather than a suggestion that the channel map download process itself had never actually even started.

==> I am still waiting for my brand new Ceton ETH purchased last week on eBay, which was supposed to be here today. Fedex delayed the delivery by one day, so it will now be here tomorrow Tuesday. So I can't do anything more until then.

(3) I am currently "limping along" and recording USA (101) on Z170, scheduled for use 24/7 until this coming Sunday when the Olympics end. I don't want to tamper with anything and try something radical or be forced to reboot or go through the WMC "TV Signal" process for new tuners until after this week. I will have complete freedom to do anything that might be required next week after the Olympics are over, so that's what I'm going to do. The upcoming "major surgery" to install the new Ceton ETH has now been deferred for one week from today.

[DSperber]

So, one more update. This one is probably the end. Once the Olympics excitement and recording pressure ended I was able to devote my full attentions to the mystery described by this thread.

The new ETH did arrive and I tried it. Turns out it was still NIB from manufacture in 2013, so its firmware and hardware versions were both "original". I did have the latest firmware FW-IMAGE file (usable on both ETH and PCIe) and was able to apply it using the web GUI. However the old hardware can only be updated by the Ceton Diagnostic Utility, I believe through a HW-IMAGE file that was provided through the "update" tab of the Diagnostic tool. Unfortunately since the Ceton site is dead there is no way to accomplish this. So although the new ETH thus is current per firmware, it is original through hardware. I don't know if that makes any difference, really.

However the bottom line is that THE NEW ETH ALSO PRODUCED "WAITING FOR CHANNEL MAP". No difference, and no improvement, from my original ETH. So, this idea for a solution again proved unsuccessful.

Next idea: since my M910t machine (with PCIe inside) works fine and shows the correct "ready" for its own tuning adapter status, why not bring the ETH+TA from Z170 (where it is failing with 'waiting for channel map") to the M910t. After all, the ETH is simply on the LAN and can be accessed by either PC running the Ceton drivers/software. This would determine whether it is something in the Win7/WMC/Ceton software currently installed (and reinstalled many times) specifically on the Z170 which is at fault. So I did a new full "TV Signal" setup again on the M910t, and sure enough it saw the network 6 tuners from the ETH along with the 6 tuners from the PCIe. So I installed all 12 tuners.

However astonishingly the results were still the same! The PCIe and its TA showed "ready", and the ETH and its TA showed "waiting for channel map"!! Same single physical Win7 WMC, same coax feed, same Spectrum head end, but two different results regarding obtaining the channel map for SDV. So once again, no success here.

Then, thinking perhaps it was a LAN/network/coax issue since the physical ETH and its TA are located "upstairs" on the second branch of the primary amp/splitter coax output in my house whereas the PCIe and its TA are located "downstairs" on the first branch of the primary amp/splitter coax output, I took the ETH+TA downstairs so as to be physically using the coax branch currently successfully being used by the M910t+PCIe. I turned off the M910t and disconnected all "switches" out of the main Netgear router which distribute ethernet/LAN throughout my house. I then connected the coax which had been feeding the M910t+PCIe+TA to now feed the ETH+TA. And I plugged the ETH directly into one port of the router (i.e. no longer going through switches). And I connected the ethernet cable directly reaching the Z170 to a second port on the router.

So now I had essentially the most simple network topology possible, with zero switches and only the router involved with just two ethernet cables (one feeding the ETH and the second feeding the Z170). This should eliminate any "network IP collisions" or conflicts or confusion of any kind resulting from the use of multiple switches and ethernet cable runs as being culpable. And it should also eliminate a possibly failing second coax run to upstairs as a possible culprit. And now only one single WMC machine on the network, so only one 192.168.200.1.

And, sadly, the results were still exactly the same. No change. Remarkable. Still "waiting for channel map".

So I've now tried two different cablecards, three different TA, two different Win7 WMC machines, two different ETH boxes, three different USB cables, and network/coax connections going from reasonably sophisticated and complex down to absolute simplest possible "two devices both connected directly to the router". And it's made absolutely no difference whatsoever. My M910t+PCIe+TA shows "ready" and my Z170+ETH+TA shows "waiting for channel map".

Well, that seemed to exhaust all possible changes or swaps or theoretical workarounds or lab experiments, and nothing solved the problem. It definitely seemed to suggest there just was something inherently flawed or fundamentally incompatible about how an ETH+TA interfaces to Spectrum/SDV (which used to be TWC, so the SDV infrastructure really came from TWC) as compared to how a PCIe+TA works. One is successful and the other not. Amazing, I know, but that seemed to be the bottom line here.

So, in extreme frustration (because I really had wanted to have the ETH on the Win10 machine so that I could run VMWare and Win7-VM and use WMC inside of Win7-VM through the Win10 host) but apparently that simply was not to be. Not because of Win7-VM, but because of ETH+TA and its apparently inability to properly get the channel map required by SDV with Spectrum. Note that the ETH actually DOES WORK CORRECTLY FOR NON-SDV CHANNELS, so I am able to tune non-SDV channels through WMC. But I simply cannot tune SDV channels through ETH which really makes the setup unacceptable for a "production backup" or a primary WMC system.

Therefore, yesterday I bit the bullet and disconnected the ETH and reinstalled my second PCIe 6-tuner card inside the Z170. This is where I had come from originally back in June 2019 when I first acquired the ETH and began my Win10 project. I had previously been using the PCIe card in Z170 ever since it was built in early 2017, through June 2019, and it was my "production WMC machines" at the time and absolutely was capable of tuning SDV channels. So now I was going back to that setup.

And, not surprisingly at this point, EVERYTHING NOW WORKS PERFECTLY AGAIN!!! Sure enough the tuning adapter now shows "ready"!!! Same exact upstairs Z170 and coax branch and TA and cablecard as failed with the ETH producing "waiting for channel map", now once again works perfectly and shows "ready" simply by reverting back to PCIe. And all channels, both SDV and non-SDV, tune perfectly. Everything is exactly the same as when it was failing with the ETH, but substituting only the PCIe produces success. I think this speaks for itself.

My guess is that it was (and still is) a Ceton software problem. They perhaps had not seen enough SDV customers from assorted cable systems who could then report problems (like mine) which could then be debugged by Ceton engineers, in order to fix things (either driver or firmware) as required before going out of business. I suspect Spectrum is probably doing whatever they're doing properly, and when the SOFTWARE (i.e. Ceton driver running inside the computer, controlling USB through the computer's USB interface, and reading data delivered from the TA to the computer through the computer's USB interface, etc.) does it for the PCIe support all is well. The Ceton "software implementation" of the SDV channel mapping technique is apparently bug-free. However the Ceton "firmware implementation" appears to be flawed, specifically for SDV and the TA. Leave out the need for a TA to get SDV channels (e.g. I can disconnect the TA completely from the ETH and still tune to non-SDV channels simply read from the coax connected to the ETH) and the ETH firmware is fine. But obviously something is not fine insofar as what/how it works talking directly to the TA via direct USB connection.

In other words, the firmware specifically for the ETH hardware is most probably the "culprit" here, insofar as its interface to TA and SDV channel mapping. The equivalent "software" running in the PC itself when using a PCIe card, where the USB interface to the TA runs through Windows rather than the hardwired direct USB-connection from ETH to TA, that is the area of code which is responsible for this failure. I'm not sure any ETH users who have SDV/TA setups are operating successfully if my Spectrum experience is typical, but I'd love to hear from someone about a success story.

I yield. 100% stability and reliability and functionality has returned to Z170. Both ETH boxes are "retired" and being put out to pasture. I will perhaps see if anybody on eBay has any interest. I will apparently just retain both M910t and Z170 as two physical native Win7 machines (although I still have Win10 available dual-boot on Z170), running WMC native as it should be run. Thanks to EPG123 and SD this primary/backup setup should be able to survive indefinitely.

NOTE: as part of my Win10 project I also installed NextPVR version 4.2 in Win10, native. It supports my Hauppauge Quad-HD OTA/ATSC 4-tuner card natively in Win10. It could support the Ceton PCIe card as well, but only for non-encrypted ClearQAM which Spectrum is not. It doesn't support cablecard or SDV/TA. But NextPVR is no WMC (e.g. no support for "extenders") which is critical to any real usable system for it to be an acceptable alternative to actual Spectrum hardware normally used to provide home TV services.

Therefore, this thread is probably ended. Rarely do I not eventually "emerge victorious" when facing a technical problem to be solved, but in this case I was no match for the forces arrayed against me. Ceton is dead, Win7 is dead, WMC is dead, Spectrum knows nothing about Ceton, and so far nobody else in Spectrum/SoCal who is also using Win7/WMC like me apparently is using an ETH. They must be using PCIe like me, if they are "successfully tuning to SDV channels via TA" as now both of my PCIe machines are.

[d00zah]

I'm in a different Spectrum market, but here's a long shot to try.

After years of occasional flaky behavior w/ my ETH, including periodic bouts of "waiting for channel map" (for days, usually following power outages), the ETH power adapter finally failed HARD. Before it did, however, I observed various effects related to how the ETH interacts w/ the TA, including reporting 'Disabled' on the TA status page while still tuning non-SDV channels just before 'the end'. Regardless, the only suitable power adapter I had available to keep things going was a HIPRO 12VDC 3.3A brick. Temporary, but in the ~24 hrs of use, things have never been more stable. I'm now wondering if maybe 1.5A might be marginal for some ETHs? I've ordered a 2A replacement.

If you have a power adapter w/ a higher current rating (rather than another 'stock' adapter), it couldn't hurt to try it? YMMV

[unclebun]

I use Spectrum, though in a different area, with a Ceton ETH and have never had trouble. It is possible that since we came from Charter that our situation is different if your service had once been Time Warner. In addition, I do not use Windows 10. I use Windows 7. I believe you have not considered one possibility that since you are using Windows 10, the issue is a network issue from not running Windows 7 natively, but in a virtual machine. Using the PCI card tuner gets around that by not using the network.

[DSperber]

I use Spectrum, though in a different area, with a Ceton ETH and have never had trouble. It is possible that since we came from Charter that our situation is different if your service had once been Time Warner. In addition, I do not use Windows 10. I use Windows 7. I believe you have not considered one possibility that since you are using Windows 10, the issue is a network issue from not running Windows 7 natively, but in a virtual machine. Using the PCI card tuner gets around that by not using the network.

Perhaps I didn't clearly express my situation. I'm not running Win10 "for real". In mid-2019 I did embark on a project to see if I could run WMC inside Win7-VM (VMWare Workstation Player) on a Win10 host machine (Z170). That's where Win10 came into the story. And of course that's what forced me to trade the PCIe for an ETH.

The Z170 machine was a native Win7 desktop since I built it in early 2017 with a PCIe inside. It was my production WMC machine until late 2018 when instability struck my world, with unpredictable "freeze" of the system. That's a whole other story, but in the end I fought what I thought was a hardware-caused problem (but on all five of my personal PC's??? Two desktops and three laptops, all "freezing" randomly and unpredictably??) but which turned out to be caused by a software conflict between MalwareBytes Anti-Malware Premium and Macrium Reflect. After fighting this for six months I worked with the two software vendors and they figured it out and finally fixed it. So no more freezes since early 2019.

But thinking my Z170 was failing, in early 2019 I moved over to my M910t desktop (also with its own Ceton PCIe card), thus freeing the Z170 machine up to playing with for my Win10 project. This production M910t/PCIe is also a native Win7 desktop machine. It was only in mid-2019 when I got started on the Win10/Win7-VM experiment that I acquired my first ETH since it was a necessity to let WMC see the Ceton tuners on the network instead of via internal PCIe which didn't have driver support through VMWare.

No, the problem is not specific to running inside of Win7-VM. In fact, just to be sure it wasn't a screwed up native Win7/WMC on the Z170 I booted to Win10 and launched Win7-VM and looked at the Ceton ETH with web browser. And sure enough, it still showed "waiting for channel map". And behavior of WMC and Spectrum-provided channels otherwise was exactly what it was in native WMC running on the Z170 in native Win7: non-SDV channels were tunable, but of course not SDV channels since the channel map had not been properly absorbed.

Honestly, I'd like to know what, if anything, is truly the fix (whatever that means) for both of my ETH boxes which both fail the same way, to get them working correctly. For non-SDV channels no TA is required and ETH works fine, just not SDV channels. This actually is how it was way back when when Time Warner was my provider, back in 2010 when I started with WMC and a Ceton 4-tuner PCIe card in my very first Win7 HTPC machine when there was no TA. The addition of SDV needing a TA came much later, around the same time as I upgraded to a 6-tuner PCIe card to go along with the new digital tuning adapter which was required for SDV channels. And I was thrilled that the Ceton driver apparently fully understood how to communicate properly with the TA. At the time I never had any interest in an ETH.

I've even played with adding and subtracting full-bandwith splitters (essentially using them as 3.5db attenuators), adding and subtracting the in-line 10-db amplifier as well. All components are Spectrum-provided hardware accessories. The goal was to see if maybe a signal that was too high or too low for the sensitivity of the TA and/or Ceton tuners might explain anomalies. As things currently sit, signal strength is just about 0db (on both Z170 and M910t) for all channels, and PCIe works fine and ETH shows "waiting for channel map" (as it has no matter what the signal strength was, as low as -11db and as high as +6db). Seems that this wasn't the key.