InfiniTV 6 Ethernet on Spectrum?

Ask fellow members about Ceton's infiniTV tuners here.
Forum rules
Ceton no longer participate in this forum. Official support may still be handled via the Ceton Ticket system.
mls001

Posts: 11
Joined: Fri Sep 19, 2014 5:27 pm
Location:

HTPC Specs: Show details

InfiniTV 6 Ethernet on Spectrum?

#1

Post by mls001 » Sun Jul 14, 2019 12:39 am

Can anyone tell me if they are still successfully running an InfiniTV-6 Ethernet on Spectrum? am having a problem that only impacts the Ethernet tuners and not the or USB tuners. Weird.

Thanks,

Mike

User avatar
mmurley

Posts: 94
Joined: Thu Aug 28, 2014 8:44 pm
Location: Fayetteville NC

HTPC Specs: Show details

#2

Post by mmurley » Sun Jul 14, 2019 1:21 am

I am.

User avatar
d00zah

Posts: 103
Joined: Fri Nov 07, 2014 7:20 pm
Location:

HTPC Specs: Show details

#3

Post by d00zah » Sun Jul 14, 2019 12:10 pm

ditto

unclebun

Posts: 39
Joined: Sun Jul 09, 2017 11:06 pm
Location:

HTPC Specs: Show details

#4

Post by unclebun » Thu Jul 18, 2019 1:07 pm

Me too

DSperber

Posts: 228
Joined: Thu Jan 16, 2014 1:35 am
Location: Marina Del Rey, CA

HTPC Specs: Show details

#5

Post by DSperber » Thu Jul 25, 2019 9:34 pm

mls001 wrote:
Sun Jul 14, 2019 12:39 am
Can anyone tell me if they are still successfully running an InfiniTV-6 Ethernet on Spectrum? am having a problem that only impacts the Ethernet tuners and not the or USB tuners.
I am as well. I have two HTPC's, one with Ceton-ETH and a second with Ceton-PCIe, am on Spectrum, and no issues.

If you would describe your "problem" that you say is ETH-only perhaps we could contribute to help.

mls001

Posts: 11
Joined: Fri Sep 19, 2014 5:27 pm
Location:

HTPC Specs: Show details

#6

Post by mls001 » Sat Jul 27, 2019 2:39 am

Thanks for responding. I am at a loss to understand what is going on.

I did post the detailed description of my problem here viewtopic.php?f=5&t=12285 but no one has responded.

Briefly, a little over a month ago my ETH-6 tuners on two different WMCs started hanging at "Waiting for Channel Map". The log shows errors (specifically a length error) decoding the channel map. What is difficult to understand is that each WMC has another tuner, One a PCI the other a USB and neither of those tuners are experiencing this error. The problem only impacts the two ETH-6 tuners. The two ETH-6 tuners and their associated WMC are on different networks with one even being on a dedicated NIC.

No amount of futzing around, reloading drivers, resetting, rediscovering, etc. has had any positive result.

Any suggestions you might have are sincerely appreciated.

Thanks,

Mike

User avatar
Bee_Dee_3_Dee

Posts: 245
Joined: Tue Feb 19, 2013 4:39 pm
Location:

HTPC Specs: Show details

#7

Post by Bee_Dee_3_Dee » Sun Aug 04, 2019 1:32 pm

mls001 wrote:
Sat Jul 27, 2019 2:39 am
Thanks for responding. I am at a loss to understand what is going on.

I did post the detailed description of my problem here viewtopic.php?f=5&t=12285 but no one has responded.

Briefly, a little over a month ago my ETH-6 tuners on two different WMCs started hanging at "Waiting for Channel Map". The log shows errors (specifically a length error) decoding the channel map. What is difficult to understand is that each WMC has another tuner, One a PCI the other a USB and neither of those tuners are experiencing this error. The problem only impacts the two ETH-6 tuners. The two ETH-6 tuners and their associated WMC are on different networks with one even being on a dedicated NIC.

No amount of futzing around, reloading drivers, resetting, rediscovering, etc. has had any positive result.

Any suggestions you might have are sincerely appreciated.

Thanks,

Mike
Have you tried the following?

1. Restart PC- then before launching WMC, Power-cycle TA and ETH-6 tuner. (Unplug both for 60 seconds then plug them back in.) Edit: "wait until the TA has completed its startup cycle and it has a solid LED" (ty jaimeknapp).

2. Before launching WMC, open Windows "Services" and Stop the "Windows Media Center Service". Then start it again. You don't need to wait any specific amount of time. A few seconds after stopping it is enough time to wait before starting it again. Just make sure it is fully restarted.

3. Launch WMC and open the guide and select a channel; and you'll see the info displayed, "Searching For Tuners"; then after about 30 seconds it will hopefully tune the channel.

GL
Last edited by Bee_Dee_3_Dee on Mon Aug 05, 2019 1:57 am, edited 1 time in total.

jaimeknapp

Posts: 111
Joined: Tue Feb 05, 2013 4:49 pm
Location: San Antonio, TX

HTPC Specs: Show details

#8

Post by jaimeknapp » Sun Aug 04, 2019 4:07 pm

I might add that between steps 1 & 2 you wait until the TA has completed its startup cycle and it has a solid LED. In my experience, the TAs and their power supplies in particular have been more prone to failure than the tuners themselves once you have them working.

User avatar
Bee_Dee_3_Dee

Posts: 245
Joined: Tue Feb 19, 2013 4:39 pm
Location:

HTPC Specs: Show details

#9

Post by Bee_Dee_3_Dee » Mon Aug 05, 2019 1:57 am

jaimeknapp wrote:
Sun Aug 04, 2019 4:07 pm
I might add that between steps 1 & 2 you wait until the TA has completed its startup cycle and it has a solid LED. In my experience, the TAs and their power supplies in particular have been more prone to failure than the tuners themselves once you have them working.
done. ty :)

mls001

Posts: 11
Joined: Fri Sep 19, 2014 5:27 pm
Location:

HTPC Specs: Show details

#10

Post by mls001 » Wed Aug 21, 2019 2:33 am

Gentlemen,

Thank you for your suggestion but unfortunately, it didn't alter the situation.

I followed the steps you recommended, as in

1 Restart the WMC PC
2 Unplug the power (only) of the Ethernet tuner and it's associated TA, waited about 10 minutes, powered them both back on.
3 Waited for the TA complete and the Amber light to go solid
4 Went in to Services and stopped both the WMC Receiver Service and Scheduler Service
5 Restarted both services
6 Launched WMC and tried to tune a channel.

This failed because the TA associated with the Ethernet tuner was "Waiting for Channel Map" and displaying the repetitive errors I listed in the other incident.

In fact, if I reboot the WMC PC and not start the Windows Media Center application, but instead

a Start the Ceton Diagnostic Tool
b Go to the webpage for the ethernet tuner
c Display the Tuning Adapter - Status is hung on "Waiting for Channel Map"
d Going into the log I can see:
Jan 1 00:00:37 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:00:37 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:00:37 ocur[21]: libcetontrif: WARNING: expected 16450 bytes 962 channels and only got 962 channels
Jan 1 00:00:37 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:00:37 ocur[21]: libcetontrif: ERROR: trif[6] Failed to unpack channel_table_rsp message (len 16384)
Jan 1 00:00:37 ocur[21]: libcetontrif: WARNING: Unhandled trif apdu. (0x58)
Jan 1 00:00:47 ocur[21]: cyrano: [zccard/s:INFO] SPDU - session_number(): 000d
Jan 1 00:00:47 ocur[21]: cyrano: [zccard/a:INFO] <- {cp_sync_req}
Jan 1 00:00:47 ocur[21]: cyrano: [zccard/a:INFO] -> {cp_sync_cnf}
Jan 1 00:00:47 ocur[21]: cyrano: [zccard/a:INFO] -> status = OK
Jan 1 00:00:47 ocur[21]: cyrano: [zccard/a:INFO] -> {/cp_sync_cnf}
Jan 1 00:00:52 ocur[21]: libcetontrif: trif[6] re requesting channel map
Jan 1 00:00:52 ocur[21]: libcetontrif: [channel_table_req]
Jan 1 00:00:52 ocur[21]: libcetontrif: [request_header]
Jan 1 00:00:52 ocur[21]: libcetontrif: trif_revision_code: 0x1
Jan 1 00:00:52 ocur[21]: libcetontrif: request_id: 0x4
Jan 1 00:00:52 ocur[21]: libcetontrif: [/request_header]
Jan 1 00:00:52 ocur[21]: libcetontrif: [/channel_table_req]
Jan 1 00:00:53 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:00:53 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:00:53 ocur[21]: libcetontrif: WARNING: expected 16450 bytes 962 channels and only got 962 channels
Jan 1 00:00:53 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:00:53 ocur[21]: libcetontrif: ERROR: trif[6] Failed to unpack channel_table_rsp message (len 16384)
Jan 1 00:00:53 ocur[21]: libcetontrif: WARNING: Unhandled trif apdu. (0x58)
Jan 1 00:01:08 ocur[21]: libcetontrif: trif[6] re requesting channel map
Jan 1 00:01:08 ocur[21]: libcetontrif: [channel_table_req]
Jan 1 00:01:08 ocur[21]: libcetontrif: [request_header]
Jan 1 00:01:08 ocur[21]: libcetontrif: trif_revision_code: 0x1
Jan 1 00:01:08 ocur[21]: libcetontrif: request_id: 0x5
Jan 1 00:01:08 ocur[21]: libcetontrif: [/request_header]
Jan 1 00:01:08 ocur[21]: libcetontrif: [/channel_table_req]

A subset of these messages are repeated over and over and the TA never receives a valid channel map.

I have swapped Ethernet-6 tuners, Tuning Adapters, the USB cable between the TA and the ETH-6 and power supplies multiple times - and the problem always "follows" the ETH-6. Further I have replaced COAX cables, swapped COAX cables with working PICe and USB tuners with no change in the symptoms. Finally, I have the same failure on two different WMC PCs, neither of which fail with PCIe or USB tuners.

Other than giving up on the ethernet tuners, I'm at a loss of how to proceed.

regards,

M

DSperber

Posts: 228
Joined: Thu Jan 16, 2014 1:35 am
Location: Marina Del Rey, CA

HTPC Specs: Show details

#11

Post by DSperber » Wed Aug 21, 2019 6:38 am

Just out of curiosity, have you requested a replacement cablecard for the ETH tuner? What about replacing the DTA as well?

The combination of cablecard and Ceton tuner (either PCIe or ETH) must be "paired" by Spectrum head-end (using the HOST ID and DATA values presented by the Ceton drivers during TV Signal setup in WMC) in order for this all to work, and it seems reasonable that if the cablecard goes south for some reason or simply becomes un-paired this might explain your current difficulties.

And of course the DTA must be working properly for SDV to behave as expected.

I have replaced cablecards and DTA's many times over the past decade of using WMC and Ceton cards on two HTPC's. This included in one HTPC the replacement of a 4-tuner PCIe Ceton card with a 6-tuner PCIe card, and then with a 6-tuner ETH tuner, and in the other HTPC the replacement of a 6-tuner PCIe Ceton card with a different 6-tuner PCIe card. Independently I've probably gone through six different DTA's on the two HTPCs and five different cablecards. Every time one piece of the puzzle got voluntarily changed or involuntarily replaced because of a hardware issue or suspected defect I've had to go through the re-pairing with TWC/Spectrum's head-end, and this has never gone smoothly when only the 1st-line phone people were involved.

I usually only eventually had success after a minimum of 30 minutes on the phone, and even then only when 2nd-level supervisory personnel were brought in to "override something". Seems the HOST ID and DATA values were somehow "not recognized" or "in the wrong format" or "had an extra digit" or some other nonsense. Eventually, something the supervisor did (which apparently the 1st-level folks couldn't do) did the trick, and I finally was able to tune successfully to SDV channels (which of course meant that the channel map had finally been downloaded properly and processed through all of the hardware/software/driver components involved).

My point is only that I'd try going with a brand new DTA and cablecard, and do the whole TV Signal setup/pairing thing from scratch.

mls001

Posts: 11
Joined: Fri Sep 19, 2014 5:27 pm
Location:

HTPC Specs: Show details

#12

Post by mls001 » Wed Aug 21, 2019 1:19 pm

Ah, yes I have. At the very beginning of the problem I picked up an additional Cable Card and TA and went through the self install route. As you described the situation is very much the norm. The support of Cable Cards has become somewhat of an arcane art and any interaction requires excessive effort and time tp complete the process.

In total, either via self install or with a Spectrum technician onsite, the Cable Cards have been replaced 4 times and the Tuning Adapter replaced three times with no change in symptoms.

If I only had a single InfiniTV 6 Ethernet, the overwhelming evidence would point to that being bad. But when this problem first began I had two InfiniTV 6 Ethernet tuners active. One in use on each of two WMC PCs. I noticed the failure on one system first, but the second tuner was still functioning normally. For a few days, at least. When the Spectrum Tech was onsite, he suggested swapping the two Ethernet tuners. This was done by powering off both tuners (and the associated TAs), swapping just the ethernet cables (as the WMC PCs were on different networks) and powering on the tuners, TAs and restarting the WMC PCs. After this process neither Ethernet tuner worked - both demonstrated the same "Waiting for Channel Map" issue no matter what WMC PC they were connected to. Continued attempts to diagnose/correct the issue (again, replacing Cable Cards, TAs, cables, etc.) have been unsuccessful.

User avatar
Bee_Dee_3_Dee

Posts: 245
Joined: Tue Feb 19, 2013 4:39 pm
Location:

HTPC Specs: Show details

#13

Post by Bee_Dee_3_Dee » Wed Aug 21, 2019 4:58 pm

is the following url new? ("[Spectrum] CableCARD Reference and Troubleshooting")
https://www.spectrum.net/support/tv/cab ... leshooting

DSperber

Posts: 228
Joined: Thu Jan 16, 2014 1:35 am
Location: Marina Del Rey, CA

HTPC Specs: Show details

#14

Post by DSperber » Sun Aug 25, 2019 6:28 pm

I happen to be working at my secondary HTPC with a Ceton ETH 6-tuner box with paired cablecard (the ETH replaced a Ceton PCIe 6-tuner card a few months back). I'm on Spectrum here in LA (Marina Del Rey) which is largely but not entirely SDV and so also have a Motorola MTR700 DTA. Everything is working fine. Also working fine is my "production HTPC" which has a Ceton PCIe 6-tuner card with paired cablecard, along with another MTR700 DTA. Everything is working fine there as well.

Just for the sake of comparison and discussion, and possibly spotting something in your setup which isn't as it should be, here are screenshots from (a) browser -> 192.168.1.3, which is my LAN IP address for the Ceton ETH tuner (static IP is still 192.168.200.1), and (b) Ceton Diagnostics. If you compare these to what you see on your machine, let's at least discover that there are (a) no significant differentcs, or (b) an interesting difference or two.

Image

Image

Image

DSperber

Posts: 228
Joined: Thu Jan 16, 2014 1:35 am
Location: Marina Del Rey, CA

HTPC Specs: Show details

#15

Post by DSperber » Sun Aug 25, 2019 6:28 pm

Image

Image

DSperber

Posts: 228
Joined: Thu Jan 16, 2014 1:35 am
Location: Marina Del Rey, CA

HTPC Specs: Show details

#16

Post by DSperber » Sun Aug 25, 2019 6:29 pm

Image
Image

Image

DSperber

Posts: 228
Joined: Thu Jan 16, 2014 1:35 am
Location: Marina Del Rey, CA

HTPC Specs: Show details

#17

Post by DSperber » Sun Aug 25, 2019 6:40 pm

From browser -> cablecard, here is "cablecard pairing":

Image


And here is "cablecard status":

Image


NOTE: observe that the cablecard ID (i.e. "unit address") as shown in "pairing" and "status" is slightly different from the "cablecard ID" value put out by the Ceton diagnostics utility (which also is presented during the TV Signal setup dialog, in theory to provide the value to be given to Specturm during head-end pairing). I suspect this is what is responsible for the confusion and difficulty to successfully pair the cablecard with the Ceton tuners while on the phone with Spectrum. They probably need to enter the "unit address" and we are giving them the "cabelcard ID", and non-supervisors don't seem to understand how to come up with the proper value which must be entered in their system. Of course that's just my speculation, but there's no question there are two similar but different values here involving the cablecard.

(a) unit address: 000-00187-44042-137
(b) cablecard ID: 000-018-744-042-5

mls001

Posts: 11
Joined: Fri Sep 19, 2014 5:27 pm
Location:

HTPC Specs: Show details

#18

Post by mls001 » Sat Aug 31, 2019 2:45 pm

DSperber,

Thank you so much for taking the time to help with the diagnosis and providing the screen prints. I have compared the information you provided with my configuration and unfortunately, I have not identified any differences that appear to be significant enough to cause this problem. I have attached similar screen prints from my system for your inspection in case I have missed anything.

You will notice that the ETH-6 for which I provided the information is running at a higher firmware level that yours. However, of my two tuners that failed, one of them was running at the same level as yours - 14.10.3.163 - when it failed. As part of my diagnosis / attempted repair actions, I have loaded three different levels of firmware without altering the symptoms: 14.4.6.21, 14.10.3.163 and 15.1.13.152 (all beta versions).

You will also notice that the ETH-6 is using a static IP address. When the tuners originally failed, each ETH-6 was on a different HTPC on a different network with an IP assigned by DHCP. (This sounds much like your configuration). In order to rule out network problems as the cause, I installed another NIC in the test system. This NIC is on a third completely separate network consisting of only the NIC, a crossover cable and the ETH-6. Again, this did not alter the symptoms.

Here are the screen prints:
Image
Image
Image

The real meat of the problem is only evident in the log. Specifically in the "libcetonrif" section beginning at about 33 seconds after startup. There certainly could be earlier messages indicating a problem, but nothing that jumped out at me as blatantly as this.

Jan 1 00:00:33 ocur[21]: libcetontrif: trif[6] Sending channel map request
Jan 1 00:00:33 ocur[21]: libcetontrif: [channel_table_req]
Jan 1 00:00:33 ocur[21]: libcetontrif: [request_header]
Jan 1 00:00:33 ocur[21]: libcetontrif: trif_revision_code: 0x1
Jan 1 00:00:33 ocur[21]: libcetontrif: request_id: 0x3
Jan 1 00:00:33 ocur[21]: libcetontrif: [/request_header]
Jan 1 00:00:33 ocur[21]: libcetontrif: [/channel_table_req]
Jan 1 00:00:33 ocur[21]: libcetontrif: [channel_table_rsp]
Jan 1 00:00:33 ocur[21]: libcetontrif: [request_header]
Jan 1 00:00:33 ocur[21]: libcetontrif: trif_revision_code: 0x1
Jan 1 00:00:33 ocur[21]: libcetontrif: request_id: 0x3
Jan 1 00:00:33 ocur[21]: libcetontrif: [/request_header]
Jan 1 00:00:33 ocur[21]: libcetontrif: table_status: 2
Jan 1 00:00:33 ocur[21]: libcetontrif: table_status: "not available, not received"
Jan 1 00:00:33 ocur[21]: libcetontrif: [trif_channel_table]
Jan 1 00:00:33 ocur[21]: libcetontrif: table_length: 0
Jan 1 00:00:33 ocur[21]: libcetontrif: trif_table_revision: 0
Jan 1 00:00:33 ocur[21]: libcetontrif: version_number: 0
Jan 1 00:00:33 ocur[21]: libcetontrif: total_number_of_blocks: 0
Jan 1 00:00:33 ocur[21]: libcetontrif: total_number_of_defined_channels: 0
Jan 1 00:00:33 ocur[21]: libcetontrif: block_number: 0
Jan 1 00:00:33 ocur[21]: libcetontrif: number_of_channels: 0
Jan 1 00:00:33 ocur[21]: libcetontrif: number_of_parsed_channels: 0
Jan 1 00:00:33 ocur[21]: libcetontrif: [/trif_channel_table]
Jan 1 00:00:33 ocur[21]: libcetontrif: [/channel_table_rsp]
Jan 1 00:00:39 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:00:39 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:00:39 ocur[21]: libcetontrif: WARNING: expected 16467 bytes 962 channels and only got 962 channels
Jan 1 00:00:39 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:00:39 ocur[21]: libcetontrif: WARNING: returning incomplete table with 962 channels
Jan 1 00:00:39 ocur[21]: libcetontrif: ERROR: trif[6] Failed to unpack channel_table_update message (len 16384)
Jan 1 00:00:39 ocur[21]: libcetontrif: WARNING: Unhandled trif apdu. (0000)
Jan 1 00:00:46 ocur[21]: ocur: STT time Sat Aug 31 02:24:24 2019 UTC
Jan 1 00:00:49 ocur[21]: cyrano: [zccard/s:INFO] SPDU - session_number(): 000d
Jan 1 00:00:49 ocur[21]: cyrano: [zccard/a:INFO] <- {cp_sync_req}
Jan 1 00:00:49 ocur[21]: cyrano: [zccard/a:INFO] -> {cp_sync_cnf}
Jan 1 00:00:49 ocur[21]: cyrano: [zccard/a:INFO] -> status = OK
Jan 1 00:00:49 ocur[21]: cyrano: [zccard/a:INFO] -> {/cp_sync_cnf}
Jan 1 00:00:52 ocur[21]: cyrano: [zccard/oobsi:INFO] Stopping oobsi filter ntt
Jan 1 00:00:52 ocur[21]: cyrano: [zccard/oobsi:INFO] Running oobsi filter ntt, handle 80000007
Jan 1 00:00:54 ocur[21]: libcetontrif: trif[6] re requesting channel map
Jan 1 00:00:54 ocur[21]: libcetontrif: [channel_table_req]
Jan 1 00:00:54 ocur[21]: libcetontrif: [request_header]
Jan 1 00:00:54 ocur[21]: libcetontrif: trif_revision_code: 0x1
Jan 1 00:00:54 ocur[21]: libcetontrif: request_id: 0x4
Jan 1 00:00:54 ocur[21]: libcetontrif: [/request_header]
Jan 1 00:00:54 ocur[21]: libcetontrif: [/channel_table_req]
Jan 1 00:00:55 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:00:55 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:00:55 ocur[21]: libcetontrif: WARNING: expected 16467 bytes 962 channels and only got 962 channels
Jan 1 00:00:55 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:00:55 ocur[21]: libcetontrif: ERROR: trif[6] Failed to unpack channel_table_rsp message (len 16384)
Jan 1 00:00:55 ocur[21]: libcetontrif: trif[6] check status interval elapsed: sending 1 reset 0
Jan 1 00:00:55 ocur[21]: libcetontrif: [tr_status_req]
Jan 1 00:00:55 ocur[21]: libcetontrif: [request_header]
Jan 1 00:00:55 ocur[21]: libcetontrif: trif_revision_code: 0x1
Jan 1 00:00:55 ocur[21]: libcetontrif: request_id: 0x5
Jan 1 00:00:55 ocur[21]: libcetontrif: [/request_header]
Jan 1 00:00:55 ocur[21]: libcetontrif: [/tr_status_req]
Jan 1 00:00:55 ocur[21]: libcetontrif: WARNING: Unhandled trif apdu. (0000)
Jan 1 00:00:56 ocur[21]: libcetontrif: [tr_status_rsp]
Jan 1 00:00:56 ocur[21]: libcetontrif: [request_header]
Jan 1 00:00:56 ocur[21]: libcetontrif: trif_revision_code: 0x1
Jan 1 00:00:56 ocur[21]: libcetontrif: request_id: 0x5
Jan 1 00:00:56 ocur[21]: libcetontrif: [/request_header]
Jan 1 00:00:56 ocur[21]: libcetontrif: [tr_status]
Jan 1 00:00:56 ocur[21]: libcetontrif: function_length: 8
Jan 1 00:00:56 ocur[21]: libcetontrif: tr_status_revision: 1
Jan 1 00:00:56 ocur[21]: libcetontrif: version_number: 1
Jan 1 00:00:56 ocur[21]: libcetontrif: downstream_status: 0
Jan 1 00:00:56 ocur[21]: libcetontrif: downstream_status: "Downstream RF locked and receiving valid downstream messages"
Jan 1 00:00:56 ocur[21]: libcetontrif: upstream_status: 1
Jan 1 00:00:56 ocur[21]: libcetontrif: upstream_status: "Upstream not connecting"
Jan 1 00:00:56 ocur[21]: libcetontrif: authentication_status: 0
Jan 1 00:00:56 ocur[21]: libcetontrif: authentication_status: "Authenticated"
Jan 1 00:00:56 ocur[21]: libcetontrif: tr_operational_status: 1
Jan 1 00:00:56 ocur[21]: libcetontrif: tr_operational_status: "TR initializing"
Jan 1 00:00:56 ocur[21]: libcetontrif: max_upgrade_time: 0
Jan 1 00:00:56 ocur[21]: libcetontrif: number_of_tuners: 6
Jan 1 00:00:56 ocur[21]: libcetontrif: [/tr_status]
Jan 1 00:00:56 ocur[21]: libcetontrif: [/tr_status_rsp]
Jan 1 00:00:56 ocur[21]: libcetontrif: trif[6] Scheduling status poll because not ready. tr_operational_status 1 dowstream 0 upstream 1
Jan 1 00:01:00 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:01:00 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:01:00 ocur[21]: libcetontrif: WARNING: expected 16467 bytes 962 channels and only got 962 channels
Jan 1 00:01:00 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:01:00 ocur[21]: libcetontrif: WARNING: returning incomplete table with 962 channels
Jan 1 00:01:00 ocur[21]: libcetontrif: ERROR: trif[6] Failed to unpack channel_table_update message (len 16384)
Jan 1 00:01:00 ocur[21]: libcetontrif: WARNING: Unhandled trif apdu. (0x58)
Jan 1 00:01:15 ocur[21]: libcetontrif: trif[6] re requesting channel map
Jan 1 00:01:15 ocur[21]: libcetontrif: [channel_table_req]
Jan 1 00:01:15 ocur[21]: libcetontrif: [request_header]
Jan 1 00:01:15 ocur[21]: libcetontrif: trif_revision_code: 0x1
Jan 1 00:01:15 ocur[21]: libcetontrif: request_id: 0x6
Jan 1 00:01:15 ocur[21]: libcetontrif: [/request_header]
Jan 1 00:01:15 ocur[21]: libcetontrif: [/channel_table_req]
Jan 1 00:01:16 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:01:16 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:01:16 ocur[21]: libcetontrif: WARNING: expected 16467 bytes 962 channels and only got 962 channels
Jan 1 00:01:16 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:01:16 ocur[21]: libcetontrif: WARNING: returning incomplete table with 962 channels
Jan 1 00:01:16 ocur[21]: libcetontrif: ERROR: trif[6] Failed to unpack channel_table_update message (len 16384)
Jan 1 00:01:16 ocur[21]: libcetontrif: WARNING: Unhandled trif apdu. (0x58)
Jan 1 00:01:17 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:01:17 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:01:17 ocur[21]: libcetontrif: WARNING: expected 16467 bytes 962 channels and only got 962 channels
Jan 1 00:01:17 ocur[21]: libcetontrif: WARNING: Check failed
Jan 1 00:01:17 ocur[21]: libcetontrif: ERROR: trif[6] Failed to unpack channel_table_rsp message (len 16384)
Jan 1 00:01:17 ocur[21]: libcetontrif: WARNING: Unhandled trif apdu. (0x58)

My original suspicion was that Spectrum had introduced an error (a length error from the above messages) into the channel map that the code in the ETH-6 was sensitive to while other intelligent tuners and TIVOs were not. But with you being so close to me that would seem to rule that out, maybe, depending on the Spectrum network topology.

It's really sad that there is no one home at Ceton anymore. I was always pretty impressed with their diagnostics and customer support.

Any other thoughts you may have are sincerely appreciated.

Thanks.

DSperber

Posts: 228
Joined: Thu Jan 16, 2014 1:35 am
Location: Marina Del Rey, CA

HTPC Specs: Show details

#19

Post by DSperber » Sat Aug 31, 2019 5:29 pm

I didn't even realize that my external ETH tuner was not at the current firmware level. I had only ever had Ceton PCIe cards since I started with WMC about 9 years ago, but when I was working on my "Win7 WMC running in Win7-VM guest using VMWare Workstation Player on Win10 host" project a few months back (which, by the way, was a 100% success!!) I discovered the Ceton PCIe card was not visible to the Win7-VM. However I learned that by using the ETH version of the tuner it was possible to see it inside the Win7-VM through a "bridged network" option in VMWare which allows all regular router/LAN devices visible to the Win10 host are also visible to Win7 and programs inside Win7-VM guest. So now all i had to do was find one for sale to see if this was really true.

Luckily, at that very moment there happened to be one for sale on eBay by a guy who actually lived here in LA. So I bought it from him and drove over to his house to pick it up that very day, so as not to lose a moment in moving forward with my project. And sure enough, that was the answer! Sure enough It WAS visible to Win7-VM. So I configured WMC running in the Win7-VM to use this newly acquired ETH tuner and removed the PCIe tuner card from the machine.

So I've only been using this ETH tuner for a few months, without a problem. The Ceton Diagnostics utility didn't tell me I needed a firmware update and the guy who sold it to me said it was up to date and fine. And in fact, it works perfectly.


Now, as far as your situation... I notice that actually our "network settings" are different in what may be a very significant way. Note that my "current IP" address is 192.168.1.3, which is a DHCP-assigned address from my router (192.168.1.1). Grayed-out on the same display it shows "static IP of 192.168.200.1" and "netmask of 255.255.255.0" and "DHCP client is checked". Note that my ETH tuner is connected to my LAN router, which resulted in the DHCP assignment of an IP of 192.168.1.3. I didn't do anything to make that happen.

Interestingly, rather than just let the "current IP" address be always be assigned dynamically I like to always do an "address reservation" in my router, for whatever DHCP IP address gets assigned the first time the device is seen by the router, which in this case was 192.168.1.3. That way every device has a conceptual "static" IP address on my LAN, not that it's critical or important but just because I like to print out a sheet of all connected devices and have it be fixed. Anyway, when I tried to do the same thing for the Ceton ETH tuner (doing an address reservation for 192.168.1.3) my router complained and could not complete the address reservation. I forget the exact message but it was something to the effect that "the device could not accept the static IP assignment". I'd never seen something like that before, and ALL of my other network devices of all types have no problem being given a "reserved" static IP address. I never even knew it wasn't just 100% always possible, and 100% the function of the router to do this. I didn't realize the device itself could "reject" the DHCP assignment.

Anyway, because of this very unexpected failure to successfully do an "address reservation" of 192.168.1.3 I just didn't. Instead I just let it get assigned normally through DHCP to that address. So what you see in my picture is purely the result of DHCP, and the ETH tuner being connected to my router just like any of my other dozens of home LAN network devices.

But what I think is really significant here is that the ETH tuner is therefore simply just another network device on my LAN, which has a normal LAN IP address that appears to my 192.168.1.1 router just like any other device looks, with a normal LAN device address of the form 192.168.1.x. As to what the actual meaning of "static IP" of 192.168.200.1 is for use by the Ceton drivers and their use of the separate six ETH tuners (or 6 tuners in the PCIe card) as a "private network device". Note that if you look at the "tuner" tab for each of the six tuners, they show a "destination IP address of 192.168.200.2". So it's like the card is its own NIC (192.168.200.1) and each tuner is 192.168.200.2. But this is all internal, between the drivers and tuner/card. On the outside, externally, the ETH tuner is connected to my router as 192.168.1.3.

Now look at your pictures. You somehow show a "current IP" address of 192.168.100.101, and your "DHCP client" box is un-checked. So I guess you must have been able to manually assign that address (i.e through address reservation of some sort). But you also show a "static IP" of the same 192.168.100.101. How can that be?? I thought the "current IP" address was the "outward-looking address, to the router/LAN/NIC" and the "static IP" was the "inward-looking address, to the drivers". Seems that this cannot be possible. The drivers need to talk to the card and thus to the tuners, which is one set of IP addresses. And then the connection to the router by its own separate IP address is how communication to the card is facilitated.

I may not be expressing it quite correctly but I don't understand why/how your setup looks the way it does. Did it always look like this? And did it actually work? Is there a reason you don't have things configured as I do, with your ETH tuner connected to your router via DHCP?

User avatar
d00zah

Posts: 103
Joined: Fri Nov 07, 2014 7:20 pm
Location:

HTPC Specs: Show details

#20

Post by d00zah » Sat Aug 31, 2019 6:07 pm

DSperber wrote:
Sat Aug 31, 2019 5:29 pm
Interestingly, rather than just let the "current IP" address be always be assigned dynamically I like to always do an "address reservation" in my router, for whatever DHCP IP address gets assigned the first time the device is seen by the router, which in this case was 192.168.1.3. That way every device has a conceptual "static" IP address on my LAN, not that it's critical or important but just because I like to print out a sheet of all connected devices and have it be fixed. Anyway, when I tried to do the same thing for the Ceton ETH tuner (doing an address reservation for 192.168.1.3) my router complained and could not complete the address reservation. I forget the exact message but it was something to the effect that "the device could not accept the static IP assignment". I'd never seen something like that before, and ALL of my other network devices of all types have no problem being given a "reserved" static IP address. I never even knew it wasn't just 100% always possible, and 100% the function of the router to do this. I didn't realize the device itself could "reject" the DHCP assignment.
Most router FWs that support static assignments stipulate the IPs be outside the normal DHCP range. It appears that MAY have been your issue.

That said, it's a wise approach I've employed (with a permanent lease) on my network for years, as it's easier to recover a device already configured to get its IP via DHCP. The default '192.168.200.2' is intended, IIRC, as a fail-safe when nothing else works.

IF the network config is in question, the Ceton Diags tool has a 'Reset Network' radio button on the 'Devices' tab to set everything back to factory defaults. I'm undecided on whether it'd have any bearing on the problem, but in the absence of alternatives, WTF? Just reboot the ETH6 after the reset.

Post Reply