S3 started tuning locals on cable as they should. Did we get a TIVO fix or was it the

[JimPa]

Since last October when I received my S3, it would not tune the local HD stations over cable as you would expect. I would often get a gray screen. Forget about programming a future recording. A workaround was to tune them OTA which worked fine.

I know that one of the locals got a new PSIP generator at about the same time that the local HD stations would start tuning correctly. The motorola DVR that I kept, never got had this tuning problem.

Just curious. Did Tivo do something to help in the tuning area or is it more likely the station that replaced the PSIP generator had something going on that confused the tuner and now that its been replaced, its no longer doing so.

[vstone]

I don't believe that cable systems pass the PSIP information from the broadcaster, but others here believe that some cable systems do. Cable plants have a rough equivalent in the PSIP information that they send. Both types of PSIP tables are defined (I think in the ATSC spec). My position is that many, probably most, cable systems do not have the cable PSIP table set up correctly. S3's without cable cards show local channels as (for instance) "707", "95-8" (ie cable frequency and subchannel) , or (as in my case) channel "0."

The Motorola gets its tuning information/channel ID from a different data stream.

My guess is that your cable company fixed its PSIP data table.

I have communicated with two different local cable plants (in different locations) representing two different cable companies about their setup. They choose not to respond.

[JimPa]

Thanks vstone.

[keenanSR]

Originally Posted by vstone

I don't believe that cable systems pass the PSIP information from the broadcaster, but others here believe that some cable systems do.

If the broadcaster sends PSIP data to the cable company in their signal, then the cable company is required to send it on to the subscriber. If the broadcaster does not send the PSIP info, then the cable company is not required create or add in the station's PSIP data.

[JimPa]

keenanSR and others,

I'm pretty sure that this cable company gets their signal over the air (not by some dedicated cable hookup from the broadcaster).

Since the PSIP signal is imbedded in the OTA transmission, is it then likely that the change out in the PSIP generator corrected the earlier problem of the S3 having difficulty tuning the cable version of the channel? The OTA reception of these same channels on the S3 seemed fine.

[keenanSR]

Originally Posted by JimPa

keenanSR and others,

I'm pretty sure that this cable company gets their signal over the air (not by some dedicated cable hookup from the broadcaster).

Since the PSIP signal is imbedded in the OTA transmission, is it then likely that the change out in the PSIP generator corrected the earlier problem of the S3 having difficulty tuning the cable version of the channel? The OTA reception of these same channels on the S3 seemed fine.

If we're talking about one station, and the OTA version had good PSIP data, then either the cableco fixed a problem they were having, or the signal is actually fed by hardline with a separate encoder which the station fixed, or corrected, the PSIP function.

The Motorola DVR ignores the PSIP data whether it's there or not as the channels are re-mapped per the cablecos channel lineup numbering scheme. Using a CableCARD does the same thing on the S3. If only one station replaced it's PSIP generator, yet you had problems with PSIP data from all local HD stations tuning clear-QAM HD locals on the S3, then the cableco must have fixed a PSIP problem at their end and the station that changed out the decoder must have been a coincidence. IOW, one station changing a piece of equipment would not have any effect on the rest of the stations in the market, unless, it was causing some sort of interference with those other stations, but that's not likely as you say the OTA signals had proper PSIP data all along.

I'm not sure if that helps answer your question or not, I'm a little unsure if you're talking about one station or many stations having the problem.

[sfhub]

Originally Posted by JimPa

Since the PSIP signal is imbedded in the OTA transmission, is it then likely that the change out in the PSIP generator corrected the earlier problem of the S3 having difficulty tuning the cable version of the channel? The OTA reception of these same channels on the S3 seemed fine.

To be clear though I don't think your S3 had any problem "tuning" the station right? It was the mapping of the channel to the expected channel # that you had problems with? The way the broadcasts work is there is an actual RF channel which you should be able to always use to tune the channel, then there is a "virtual" channel mapping that makes it easier for you to remember.

[vstone]

Does anybody have any reason to believe that the S3 looks for any OTA PSIP data in a signal received over a cable company coax (other than wishing/hoping that it does)?

[JimPa]

Originally Posted by sfhub

To be clear though I don't think your S3 had any problem "tuning" the station right? It was the mapping of the channel to the expected channel # that you had problems with? The way the broadcasts work is there is an actual RF channel which you should be able to always use to tune the channel, then there is a "virtual" channel mapping that makes it easier for you to remember.

I'm not sure if it was the S3 or something the cable company was doing.

Here's more detail that might help. The locals that I was having a problem tuning went something like this. I could enter 201 on the remote and get a gray screen. Then up channel to 206 which would come in, then down channel and 201 and it would come in. If I then entered 211, I'd get a gray screen. I could up channel to 216 and get the channel, then down channel and get 211. If I then entered 201, I'd once again get a gray screen. As you can see, this gets to be a mess as to who or what was responsible for the problem. In any event, its all working correctly now.

[Saxion]

Originally Posted by vstone

Does anybody have any reason to believe that the S3 looks for any OTA PSIP data in a signal received over a cable company coax (other than wishing/hoping that it does)?

Absolutely, yes it does. Prior to early Feb, my local cable company didn't send any PSIP data and all digital locals were mapped to QAM frequencies. After early Feb, all locals got remapped to OTA channel numbers (and also got some other OTA PSIP data, like station call letters, occasional real-time programming descriptions, etc). There is no other path for this data other than PSIP over cable (I don't own CableCards and don't have an antenna hooked up). FYI, a secondary (non-TiVo) tuner behaved the same way, remapping all digital locals received over cable to OTA channel numbers on the same date.

[sfhub]

Originally Posted by vstone

Does anybody have any reason to believe that the S3 looks for any OTA PSIP data in a signal received over a cable company coax (other than wishing/hoping that it does)?

It is the cable equivalent of OTA PSIP data, and yes, TiVo definitely looks for it (as does every TV I have which has a QAM tuner). TiVo looked for it with the original software on my S3, way before the 8.1 update.

[sfhub]

Originally Posted by JimPa

I'm not sure if it was the S3 or something the cable company was doing.

Here's more detail that might help. The locals that I was having a problem tuning went something like this. I could enter 201 on the remote and get a gray screen. Then up channel to 206 which would come in, then down channel and 201 and it would come in. If I then entered 211, I'd get a gray screen. I could up channel to 216 and get the channel, then down channel and get 211. If I then entered 201, I'd once again get a gray screen. As you can see, this gets to be a mess as to who or what was responsible for the problem. In any event, its all working correctly now.

So basically what seems to have been happening before is that TiVo could not handle PSIP mappings that mapped to a pure channel # like 206 properly.

OTA PSIP maps to #.subchannel like 7.1, 7.2, etc. I know TiVo handled that fine even with the old software.

Some cable companies use PSIP to map the channel #s to cable channels #s. When you tuned to such a channel # by pressing the channel # on the remote it did not work, but it did work if you ch+/- to that channel. Probably some broken logic in TiVo that didn't realize there could be a virtual channel mapping in those cases. The software probably tuned to the main channel (which is normally an analog channel), then looked from subchannels that might be virtually mapped. In this case, the main channel was the virtually mapped channel.

BTW 206 and 211 are not "real" RF channels. The real broadcast for those channels will be on something like 108.x, 84.x, etc. The virtual mapping will map that to 206, 211, etc. to match the cable broadcast channel #s and make it easier to remember.

[sfhub]

Originally Posted by vstone

S3's without cable cards show local channels as (for instance) "707", "95-8" (ie cable frequency and subchannel) , or (as in my case) channel "0."

In my experience if you see channel "0" it usually is a symptom of the PSIP being present but malformed in some way.

[mikeyts]

Originally Posted by vstone

I don't believe that cable systems pass the PSIP information from the broadcaster, but others here believe that some cable systems do. Cable plants have a rough equivalent in the PSIP information that they send. Both types of PSIP tables are defined (I think in the ATSC spec). My position is that many, probably most, cable systems do not have the cable PSIP table set up correctly. S3's without cable cards show local channels as (for instance) "707", "95-8" (ie cable frequency and subchannel) , or (as in my case) channel "0."

The Motorola gets its tuning information/channel ID from a different data stream.

My guess is that your cable company fixed its PSIP data table.

I have communicated with two different local cable plants (in different locations) representing two different cable companies about their setup. They choose not to respond.

FCC regulations require that cable service providers retransmit PSIP for all over-the-air channels that they rebroadcast (see Code of Federal Regulations Title 47, §76.640(b)(1)(iv)). Of course, the over-the-air channels often have non-existent or faulty PSIP.

[sfhub]

Originally Posted by mikeyts

Of course, the over-the-air channels often have non-existent or faulty PSIP.

On the other hand, FCC requiring something to happen should not be construed as it actually happening in a particular case. In my experience some of the breakdown can also happen at the head-end (as opposed to OTA channels having broken PSIP to start with), most likely due to misconfiguration. In my area, all the head-ends around were getting all the PSIP info passed through, but my head-end only passed the PSIP for half the channels.

I think enforcement of passing PSIP is lax at the moment and it can take a while to navigate through the bureaucracy to find someone who knows what you are talking about and still longer for that person to find the right person to fix it.

[mikeyts]

I'm not saying that the cable providers follow all of the FCC regulations--they follow the ones that they want to or have to, until someone complains to the FCC. Most of the time the FCC will eventually make them kowtow to the regulations as written.

In the beginning of the plug-and-play cable-over-DTV era, many cable providers were rebroadcasting over-the-air DTV with encryption and requiring that people lease boxes and subscribe to extended basic to receive them. This is an FCC reg violation--providers must position any rebroadcast of a local free-to-air station in the core basic tier and nothing in the core basic tier may be encrypted. People complained and the FCC forced their providers to unencrypt their local DTV rebroadcasts and to provide them with core basic service, so people with clear QAM tuners could receive them without leasing equipment. Even with that, I'm sure that there are still providers out there forcing their subs to subscribe to expanded basic and lease a digital box to receive over-the-air DTV, where none of the subs is savvy enough to complain about it.

[sfhub]

I was mainly pointing an alternate explanation for PSIP problems that didn't involve the broadcaster. I think you took it the wrong way.

Originally Posted by mikeyts

This is an FCC reg violation--providers must position any rebroadcast of a local free-to-air station in the core basic tier and nothing in the core basic tier may be encrypted. People complained and the FCC forced their providers to unencrypt their local DTV rebroadcasts and to provide them with core basic service, so people with clear QAM tuners could receive them without leasing equipment.

Did they update the FCC regs? My understanding of the (earlier?) rule was that the rule specified either the analog or the digital would satisfy must-carry, but they weren't requiring both. I believe further it was under the broadcasters control whether they wanted their broadcast to be must-carry or not and this is somewhat related to CBS's stance during negotiations for whether MSOs should pay for the right to carry CBS-HD content. It also is related to the issue of whether MSOs are forced to carry all the subchannels or just the main channel.

Anyway, if you could point to the specific FCC requirement that the digital station falls under must-carry irrespective of whether analog is satisfying must-carry, I would appreciate it, because I haven't been staying up to date on this issue.

[dt_dc]

Originally Posted by sfhub

Did they update the FCC regs?

mikeyts was talking about encryption.

Encryption and must-carry are two seperate (though somewhat related) issues.

Your unterstanding of must-carry is correct ... mikeyts' comments about encryption are correct. Although, I guess to clarify ... you could append "If a cable company carries a local OTA channel then" in front of his comments.

[sfhub]

Originally Posted by dt_dc

Your unterstanding of must-carry is correct ... mikeyts' comments about encryption are correct. Although, I guess to clarify ... you could append "If a cable company carries a local OTA channel then" in front of his comments.

Must-carry implies basic tier. Basic tier implies no box. No box implies no encryption. Therefore must-carry implies no encryption. Yes they are separate issues, but one does imply the other.

My understanding of the justification for some MSOs encrypting HD locals was that the FCC regs specified either analog or digital could be used to satisfy must-carry/basic-tier, and thus since they already broadcast the analog version in basic tier, unencrypted, the digital channel had no restrictions and would not be required to be in basic-tier(unencrypted). Comcast took the other interpretation that HD locals were considered basic-tier.

I was asking for the specific regulation that says that if digital OTA is retransmitted on cable, it must be unencrypted. When I followed this topic 2 years ago, I don't believe there was anything that said that. I think it would be useful for somebody to use to point out to their MSO that they shouldn't be encrypting digital local if they are experiencing this.

[dt_dc]

Originally Posted by sfhub

I was asking for the specific regulation that says that if digital OTA is retransmitted on cable, it must be unencrypted.

47CFR76.901
http://a257.g.akamaitech.net/7/257/2...7cfr76.901.htm

Basic service. The basic service tier shall, at a minimum, include all signals of domestic television broadcast stations provided to any subscriber

47CFR76.5
http://a257.g.akamaitech.net/7/257/2.../47cfr76.5.htm

(b) Television station; television broadcast station. Any television broadcast station operating on a channel regularly assigned to its community by Sec. 73.606 or Sec. 73.622 of this chapter

47CFR73.622
http://a257.g.akamaitech.net/7/257/2...7cfr73.622.htm

Sec. 73.622 Digital television table of allotments.

(all digital OTA stations can be found here)

47CFR76.630
http://a257.g.akamaitech.net/7/257/2...7cfr76.630.htm

Cable system operators shall not scramble or otherwise encrypt signals carried on the basic service tier.

All domestic television broadcast stations must be carried on the basic tier. This includes stations operating under Sec. 73.622 (digital stations). And the basic tier must be unencrypted.

[sfhub]

Thank you for taking the time to put together the references.

[dt_dc]

There are (of course) some grey areas / regulations subject to interpretation ...

For example, do the 'basic tier' rules apply to cable companies that have petetioned for (and been found) "subject to effective competition"?

The NCTA has also floated some suggestions / ideas in various proceedings that would effectively allow them to encrypt the digital locals (if they passed).

For example ... one of the latest ...

http://hd.broadcastnewsroom.com/arti....jsp?id=115035

He (NCTA head McSlarrow) did say he would be open to a bill getting rid of the so-called must-buy requirement that cable subcribers have to at least buy the basic tier, where broadcasters must be carried by law.

http://www.tvtechnology.com/pages/s.0015/t.3183.html

He (NCTA head McSlarrow) said that retransmission consent had often been mischaracterized as a "free-market issue."

"You start first with spectrum and a platform that was provided for free for broadcasters. Then you say, the content is provided on an exclusive basis, with network nonduplication and syndex rules," he said. "Then the law says, there's a choice between simply asking for carriage or retransmission consent. It's a heads I win, tails you lose, regime. When they walk into a negotiation... their carriage is by law guaranteed on the basic tier, and consumers have to buy the basic tier before they buy any other tier. So when it's referred to as a free market negotiation, they're forgetting about this regulatory regime that's already in place."

McSlarrow ... in a roundabout way ... is saying that they should be allowed to encrypt OTA stations and offer them on something other than the 'basic tier'.

[vstone]

My point was that some folk were (and maybe are) saying that cable companies must pass the OTA PSIP data. I really don't know much about this, but it appears to me that the PSIP table data in in the frequency's data stream, but not necessarily part of the channel(s)'s data stream within the frequency's data stream. Anyway, since the cable company is supposed to stream its own PSIP table data, I would imagine that the S3 looks for the cable PSIP data and would normally have no need to look at the OTA PSIP data, if it were there. The OTA PSIP table would tell it about channel 7-1, which is normally not the way to tune to a digital cable channel (although one person here reported that was what he was getting on his S3 hooked to cable).

I agree that channel "0" is the result of an improperly populated PSIP table. I saw it at home and reported it to the local cable company.

I reported my findings here:
http://www.tivocommunity.com/tivo-vb...d.php?t=337457

I'm still fighting the cable company at my vacation home in Myrtle Beach. I had 5 of 7 channels, then lost all of them a month ago. They keep wanting to blame my clear QAM TV, although a local store has been having to rescan their TV sets in the store and at their homes twice a week for about a month.

[sfhub]

Originally Posted by vstone

My point was that some folk were (and maybe are) saying that cable companies must pass the OTA PSIP data. I really don't know much about this, but it appears to me that the PSIP table data in in the frequency's data stream, but not necessarily part of the channel(s)'s data stream within the frequency's data stream. Anyway, since the cable company is supposed to stream its own PSIP table data, I would imagine that the S3 looks for the cable PSIP data and would normally have no need to look at the OTA PSIP data, if it were there. The OTA PSIP table would tell it about channel 7-1, which is normally not the way to tune to a digital cable channel (although one person here reported that was what he was getting on his S3 hooked to cable).

I believe the real OTA PSIP data is lost when they strip the streams from OTA and reassemble for the QAM retransmission. As such I don't think the the requirement is to send OTA PSIP in its original form. Rather it is to cause to be propogated the data in the original OTA PSIP onto the cable PSIP equivalent. This has the same effect and I and many others have connected just the cable RF to the wall and tuned channel 9.1, 7.1 etc.

On these same systems, when you install a CableCARD, it completely overrides the PSIP mappings and will use the downloaded channel list from the cable company which uses numbers like 709, 707, etc.

It may take a little time for someone to dig up the reference regarding the PSIP retransmission.

[hornblowercat]

Originally Posted by sfhub

I believe the real OTA PSIP data is lost when they strip the streams from OTA and reassemble for the QAM retransmission.

What evidence to do you have that this occurs? My understanding that broadcast of local HD is no changed at all.

[sfhub]

Originally Posted by hornblowercat

What evidence to do you have that this occurs? My understanding that broadcast of local HD is no changed at all.

The discussion is here:
http://www.avsforum.com/avs-vb/showt...&&#post7063663

Thanks, that was very helpful. It looks like the PSIP streams are regenerated on QAM. The clue is that the modulation mode has been changed from 8VSB to "SCTE_mode_2" (QAM). So this means that there is some kind of device doing the regeneration and it probably needs to be programmed properly (which I'm guessing is why it worked before, but not now).

Ron

If you look at the TSReader dump of the QAM broadcast of ABC/KGO you will see the following info, which has references specific to the QAM broadcast, thus could not be the same PSIP that was sent OTA.

Terrestrial Virtual Channel Table
Channel 1
Service Name: KGO HD
TSID: 4121 (0x1019) 
Channel Number: 7.1
Carrier Frequency: 624000000
Modulation Mode: SCTE_mode_2
Source ID: 5

--------------------------------------------------------------------------------
Channel 7
Service Name: KGO SD
TSID: 4121 (0x1019) 
Channel Number: 7.2
Carrier Frequency: 624000000
Modulation Mode: SCTE_mode_2
Source ID: 11

The TSReader dump is here:
http://www.avsforum.com/avs-vb/showt...&&#post7062082

[sfhub]

Originally Posted by vstone

My point was that some folk were (and maybe are) saying that cable companies must pass the OTA PSIP data.

You referenced this document in this post:
http://www.atsc.org/standards/a_65cr1_with_amend_1.pdf
http://www.tivocommunity.com/tivo-vb...&&#post4873051

1.1 Application
This document describes tables that shall be applicable to terrestrial (over-the-air) and cable
signals. Some PSIP tables apply to terrestrial broadcast, some apply to cable, and others apply to
both.

...

1.1.2 Cable
The following PSIP data shall be included in all ATSC-compliant Transport Streams to be
transmitted via cable:
• The Cable Virtual Channel Table (CVCT) defining, at a minimum, the virtual channel
structure for the collection of MPEG-2 programs embedded in the Transport Stream in
which the CVCT is carried.
• The Master Guide Table (MGT) defining the type, packet identifiers, and versions for all

Here is reference to the mandate:
http://www.atsc.org/news_information...sletter_17.pdf

The United States Federal Communications Commission
(FCC) incorporated the entire ATSC Program and
System Information Protocol for Broadcast and Cable
(A/65B) into its rules without making any changes
or taking any exceptions.

Here is reference to the effective date:
http://www.atsc.org/news_information...PMCP_11_04.htm

“Standardization of PMCP could not have come at a better time” said ATSC President Mark Richer. “The FCC mandate for full implementation of the ATSC PSIP standard (Program and System Information Protocol for Terrestrial Broadcast and Cable), comes into effect in February 1, 2005. PMCP will provide the capability for broadcasters and manufacturers to interconnect systems that process PSIP and DTV metadata to help meet that obligation. “

[sfhub]

Originally Posted by vstone

Anyway, since the cable company is supposed to stream its own PSIP table data, I would imagine that the S3 looks for the cable PSIP data and would normally have no need to look at the OTA PSIP data, if it were there. The OTA PSIP table would tell it about channel 7-1, which is normally not the way to tune to a digital cable channel (although one person here reported that was what he was getting on his S3 hooked to cable).

I'm starting to realize where your confusion arises. I think you are under the impression that major.minor-style channel #s imply the data is from OTA PSIP while major-style channel #s imply the data is from Cable PSIP. So in your mind, if TiVo is connected to only cable coax and TiVo says 7-1, then that must be from the OTA PSIP.

Actually Cable's equivalent PSIP has the ability to support both major *and* major.minor style numbering. PSIP on Cable can have some channels using 7.1, 7.2, 7.3 channel while other channels use 550, 551, 552, etc. OTA PSIP only supports the major.minor style numbering.

As I mentioned in my previous post, it is not possible (or practical) to broadcast the OTA PSIP completely unchanged on the QAM cable broadcast because at the minimum the modulation mode must be changed from ATSC/8VSB to SCTE_mode_2/QAM256. There are also other data items that need to change to reflect the rebroadcast on QAM systems. All this requires software to regenerate the OTA PSIP information as Cable equivalent PSIP info.

Thus when people say FCC requires cable to carry OTA PSIP, what they really mean is FCC requires cable companies to take the relevant OTA PSIP information (like the virtual channel mapping) and regenerate it on the QAM broadcast using Cable equivalent PSIP.

Also keep in mind 7.1 on a cable system is quite different than 87.1.

7.1 is mapped using Cable equivalent PSIP. 87.1 indicates there is no Cable equivalent PSIP info for virtual channel mapping and 87 is the actual RF frequency, while .1, .2, .3 is a numbering that is generated by the receiving device and depending on what algorithm it uses to count, can vary from device to device.

[vstone]

Actually, there have been some here who interpreted the 7.1 as a sign that on their cable system was passing the OTA PSIP table. I was not among them. Before I got the cablecards, my S3 and others here showed several channel "0"s. Some got the expected (to me) channel 707, etc. and at least one (probably you) got 7.1, etc.

I am one of those who don't want Tivo to spend the time creating a system to map clear QAM frequencies because I believe that if the cable systems are set up properly, this isn't required. I have sent email to someone at Tivo at the request of someone of this forum saying that they should just go out and collect some info on poorly set up systems and inform the cable companies and/or FCC. That would be a lot cheaper for them them writing, debugging, and beta testing the code.

I went out and bought the current Samsung digital receiver box just to test the two different cable systems I was involved with. Even with the results that I reported to them, neither of the two cable systems did anything beyond discussing it. On one I had the S3 with cablecards, so it really didn't affect me. On the other, it appears that the Myrtle Beach TWC cable plant is being manipulated from Columbia and screwing up every clear QAM tuner in the area, including many in a Audio-Video store. I know only enough to be dangerous, but the cable companies have done such a poor job of training their techs that sometimes I am teaching them. Some techs in Myrtle Beach don't know anything about SDV, even though I got a tech supervisor to admit to using it yesterday (by mistake, I believe, since whenever I asked the question directly they avoided it.).

[ClarkHodder]

The 8.1.1 software update killed my CableCards. After 4 Comcast service calls (I bought the service warranty) I finally called Tivo and they said, "Yeah, we know that upgrade messed up some Cable Cards. We are working on a fix. Call back every two weeks."

So now I am in the land of QAM for some unknown duration. When I looked around at my channels I was surprised to find that almost all of the major HD broadcasts are available even with no CableCards. And they are mapped to their correct numbers, e.g. 4-1. Oh, joy! But the Tivo guide will not work for those channels - what is up with that? If the guide worked I would quickly back off the cable service to the most basic level and throw away the cursed cable cards.