Ceton tuner w/ Comcast -MP won't display some channels WMC does (2 Viewers)

[milhouse]

The channels added were just channels I delete from the listing. I don't need to see shopping channels, movie channels I don't subscribe to, etc. So they just get added in each time I scan, then I delete them again. So not a problem.

But to your specific question, no, these channels have never worked. I just got the Ceton card (replacing a Collossus + STB), and haven't been able to get all channels working reliably. Took a while just tot get the tuning adapter working, but I think the cablecard and TA are now working correctly.

I have now deleted all channels and done a clean re-scan from scratch. I seem to still have the same issue. Out of about 57 channels on the Ceton, 23 will tune through Test Timeshifting, and the rest can't find PMT infomation. The Ceton log shows the PMT PID info, so it's available through the tuner.

The ones that fail show this:

[2014-06-27 17:16:37,669] [Log  ] [37  ] [DEBUG] - WaitForPMT: Waiting for PMT 0
[2014-06-27 17:16:57,670] [Log  ] [37  ] [DEBUG] - WaitForPMT: Timed out waiting for PMT after 20.001144 seconds. Increase the PMT timeout value?

This is what I see for channels that work:

[2014-06-27 17:14:25,949] [Log  ] [15  ] [DEBUG] - WaitForPMT: Waiting for PMT 59
[2014-06-27 17:14:25,950] [Log  ] [37  ] [DEBUG] - DRI CC: device 20 state variable LastChange for service schemas-upnp-org:device:MediaServer:1.schemas-upnp-org:service:AVTransport:1 changed to <Event xmlns="urn:schemas-upnp-org:metadata-1-0/RCS/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:schemas-upnp-org:metadata-1-0/RCS/http://www.upnp.org/schemas/av/rcs-event-v1-20060531.xsd"><InstanceID val="0"><TransportState val="PLAYING"/></InstanceID></Event>
[2014-06-27 17:14:26,234] [Log  ] [41  ] [INFO ] - subch:0 OnPMTReceived() pmt:59 ran:True dynamic:False
[2014-06-27 17:14:26,235] [Log  ] [15  ] [DEBUG] - WaitForPMT: Found PMT after 0.2860164 seconds.

Any other thoughts?

Thanks-
Milhouse

 

[mm1352000]

The channels added were just channels I delete from the listing. I don't need to see shopping channels, movie channels I don't subscribe to, etc. So they just get added in each time I scan, then I delete them again. So not a problem.

As an alternative you could untick the channels so they don't show in the guide.

But to your specific question, no, these channels have never worked. I just got the Ceton card (replacing a Collossus + STB), and haven't been able to get all channels working reliably. Took a while just tot get the tuning adapter working, but I think the cablecard and TA are now working correctly.

Okay.

I have now deleted all channels and done a clean re-scan from scratch.

Log files would be appreciated.

I seem to still have the same issue. Out of about 57 channels on the Ceton, 23 will tune through Test Timeshifting, and the rest can't find PMT infomation. The Ceton log shows the PMT PID info, so it's available through the tuner.
The ones that fail show this:
...
Any other thoughts?

No more that what I said previously:

My suspicion is that one of the key tuning parameters - the program number (AKA service ID) - has changed for some channels, and the symptoms you're seeing are the result.

PMT errors can be a little deceptive. In fact TV Server needs to have the right program number and PMT PID in order for the channel to work. I have no way to know whether the program number TV Server found in the scan is correct because I have no idea what the correct program number should be. Usually that should be a no-brainer... but with a TA (SDV) involved it is much more complex. If the Ceton log files show these sorts of details then I suggest you post them as well. In short, the more information you can provide, the better.

 

[jonesdb]

You shouldn't have to rescan each tuner... unless there is something peculiar to Ceton drivers/hardware/firmware that requires it.

You are quite correct. I have misinterpreted the scan reports I was seeing. My cable channels have all been mapped to all 6 Ceton tuners right from the beginning.. My SDT/VCT timeout is set to 90 seconds. My error would have been in interpreting the changes+new channels reported when I did a re-scan on a second tuner immediately after scanning a single tuner. Most, but not all of the time the two reports are identical. (Sometimes it reports more or fewer new channels, but the total channels between new and changed remains constant.)
The problem appears to be that 'new' channels aren't really 'new' all the time. I did a lot of channel clean-up/deletion today and did a rescan. The report was 75 'new' channels (500+ updates). When I dug into the 'new' channels I found only 3 channels that were actually new. The other 72 new channels had the same name (programing) as previous to the new scan, but the 'Service ID' was the only thing that had actually changed most of the time. In the past, when mapped to the tuners I couldn't identify the old from the new as I had a mix of channels with and without group assignments. This time everything that had been previously mapped had a group assignment already so the difference was easy to see as the 'new' channels didn't have a group assignment.
I don't know what the algorithm for determining 'new' vs 'update' looks like, but in my case 96% of what was marked as new in the re-scan was really just updated....a pain, as then I needed to manually delete each of the old channels and re-assign the 'new' channels to their proper groups along with updating the guide stuff.
I hope my experience and explanation helps someone else with similar issues. I think I can safely say that all of my problems were related to adding new channels that were really just updates, hence ending up trying to tune with old data that was useless when tuning.
The whole thing with the authorization flag popping seems to have been a red herring.
On another note, I'm using Win8 and wonder if anyone has experience using the Win8 beta drivers for the Ceton tuner. I've considered updating, but still a little gun shy at this point.

 

[milhouse]

OK, to get nice clean logs, I deleted all channels, stopped the service, cleared all logs, and started the service. I then did a scan on one Ceton CC card, and went to the Channels tab and did Test Timeshifting of 5 channels. I let that test the first few channels so you could see a couple of successes (A&E HD, Bravo HD) and some failures (ABC Family HD, AMC HD, Animal Planet HD) for comparison. These are channels 795, 749, 732, 862, and 765 in the Ceton log.

The ceton log for some terrible reason counts up from Jan 1 midnight, so might not be terribly easy to match up the logs. But I kept them short.

Let me know if you need more verbose logs, and thanks for the patience, mm. I appreciate all your support!

Milhouse

 

[mm1352000]

@jonesdb
Sounds like you're sorted then?

My error would have been in interpreting the changes+new channels reported when I did a re-scan on a second tuner immediately after scanning a single tuner.
...
I don't know what the algorithm for determining 'new' vs 'update' looks like, but in my case 96% of what was marked as new in the re-scan was really just updated....a pain, as then I needed to manually delete each of the old channels and re-assign the 'new' channels to their proper groups along with updating the guide stuff.

Right, understood... and thank you for the detail - I appreciate it.
Indeed, the algorithm (which is the same as used for ATSC over the air and clear QAM cable) uses the combination of TSID + source ID + service ID to locate channels which are already present. If the service ID changes then the channel will be identified as new. The information you've provided has helped me to see that CableCARD could actually be handled differently because the source ID by itself is enough to identify a channel (ie. we could treat service ID changes for CableCARD as updates). Implementing that change is easier said than done though I'm afraid, but consider it to be on my TODO list.

 

[jonesdb]

The channels added were just channels I delete from the listing. I don't need to see shopping channels, movie channels I don't subscribe to, etc. So they just get added in each time I scan, then I delete them again. So not a problem.

As an alternative you could untick the channels so they don't show in the guide.

But to your specific question, no, these channels have never worked. I just got the Ceton card (replacing a Collossus + STB), and haven't been able to get all channels working reliably. Took a while just tot get the tuning adapter working, but I think the cablecard and TA are now working correctly.

Okay.

I have now deleted all channels and done a clean re-scan from scratch.

Log files would be appreciated.

I seem to still have the same issue. Out of about 57 channels on the Ceton, 23 will tune through Test Timeshifting, and the rest can't find PMT infomation. The Ceton log shows the PMT PID info, so it's available through the tuner.
The ones that fail show this:
...
Any other thoughts?

No more that what I said previously:

My suspicion is that one of the key tuning parameters - the program number (AKA service ID) - has changed for some channels, and the symptoms you're seeing are the result.

PMT errors can be a little deceptive. In fact TV Server needs to have the right program number and PMT PID in order for the channel to work. I have no way to know whether the program number TV Server found in the scan is correct because I have no idea what the correct program number should be. Usually that should be a no-brainer... but with a TA (SDV) involved it is much more complex. If the Ceton log files show these sorts of details then I suggest you post them as well. In short, the more information you can provide, the better.

Both the Ceton device webpage and the Ceton log show both program number and pid. Need help finding them let me know.[DOUBLEPOST=1404009750][/DOUBLEPOST]

@jonesdb
Sounds like you're sorted then?

My error would have been in interpreting the changes+new channels reported when I did a re-scan on a second tuner immediately after scanning a single tuner.
...
I don't know what the algorithm for determining 'new' vs 'update' looks like, but in my case 96% of what was marked as new in the re-scan was really just updated....a pain, as then I needed to manually delete each of the old channels and re-assign the 'new' channels to their proper groups along with updating the guide stuff.

Right, understood... and thank you for the detail - I appreciate it.
Indeed, the algorithm (which is the same as used for ATSC over the air and clear QAM cable) uses the combination of TSID + source ID + service ID to locate channels which are already present. If the service ID changes then the channel will be identified as new. The information you've provided has helped me to see that CableCARD could actually be handled differently because the source ID by itself is enough to identify a channel (ie. we could treat service ID changes for CableCARD as updates). Implementing that change is easier said than done though I'm afraid, but consider it to be on my TODO list.

I think I'm good...at least for the time being. Anything I can do to help, let me know. I'm an old time analog/RF IC designer that can find my way around most hardware or PC and even can deal with a little code though it has been a long time since I looked at MP. Thanks for you help

 

[mm1352000]

@milhouse
Thanks for the log files - they're perfect.
It looks like my guess about the cause of the problem was correct. During the scan the CableCARD is giving TV Server the wrong program number for the channels that aren't working. Taking AMC HD as an example...

The information we get from the CableCARD in the scan:
[2014-06-28 20:59:13,734] [Log ] [24 ] [DEBUG] - S-VCT: source ID = 0x401e, virtual channel number = 862
[2014-06-28 20:59:18,694] [Log ] [24 ] [DEBUG] - S-VCT: virtual channel number = 862, application virtual channel = False, bitstream select = 0, path select = 0, transport type = Mpeg2, channel type = Normal, source ID = 0x401e
[2014-06-28 20:59:18,694] [Log ] [24 ] [DEBUG] - S-VCT: CDS reference = 158, program number = 0x102, MMS reference = 4
[2014-06-28 21:00:39,970] [Log ] [24 ] [DEBUG] - NTT: source name, source ID = 0x401e, name = AMC HD, application type = False

Note the program number - 0x102 (hexadecimal notation) = 258.

When we tune:
[2014-06-28 21:03:53,902] [Log ] [4 ] [INFO ] - atsc:Tune:ATSC:tv:Cable AMC HD Freq:997250 ONID:16414 TSID:0 SID:258 PMT:0x0 FTA:False LCN:158 phys:158 maj:862 min:0 mod:Mod256Qam

Again, note the program number (SID) matches what we found in the scan.

Finally, the Ceton tuning log:
Jan 6 08:23:47 ocur[21]: ocur: [0] Resolved channel 862 -> freq 639000, prog 459, modulation 16

...and there is the problem - 459 does not match the 258 that we got in the scan, and so the tune attempt will fail with the PMT error.

I can say with absolute confidence that we're retrieving and storing the information the CableCARD gives us correctly. I suspect the fact that TV Server's program number does not match the Ceton logs is due to a combination of the use of SDV (switched digital video) and Comcast not keeping the VCT (virtual channel table) for CableCARDs up to date. It's a case of garbage in garbage out.

I honestly can't think of anything that we can do to solve or even workaround this problem in code. Without a correct program number from the CableCARD we simply can't tune properly.

You can workaround this problem by manually correcting the program number for each of your non-working channels. I know it would be painful and I wish I could offer a better solution but at this point I've got nothing.

In the meantime I can try to contact Ceton and ask if they have any ideas but don't hold out much hope. To that end it would be helpful to know your zip code (Ceton may know about issues with Comcast in your area). I would also suggest you raise a support ticket with Ceton. Please feel free to refer them to me if they have technical questions.

Regards,
mm

 

[jonesdb]

Jan 6 08:23:47 ocur[21]: ocur: [0] Resolved channel 862 -> freq 639000, prog 459, modulation 16

I note that the time stamp on the Ceton log is January, not June.

 

[mm1352000]

Yep, as milhouse said (and I have also observed in other testing):

The ceton log for some terrible reason counts up from Jan 1 midnight, so might not be terribly easy to match up the logs. But I kept them short.

 

[milhouse]

Thanks for the analysis, mm! I'll see about manually fixing them with the info in the logs.

My cable provider in Charter, and my zip code is 55388.

Thanks again. Hopefully the program number isn't apt to change much once I've updated then...
Milhouse


Edit: Just an FYI, I used the Ceton diagnostic web page to tune to each non-working channel, looked at the program number there. Then I updated the channel tuning details (I think it was the SID field) in MP. All channels now work! Some are a little slower than others, probably where the tuning adapter has to send the channel request. Thanks a ton!