Cincinnati, OH - HDTV - Page 259 - AVS Forum
Forum Jump: 
 4Likes
Reply
 
Thread Tools
post #7741 of 14413 Old 08-29-2007, 07:35 AM
AVS Special Member
 
slimm's Avatar
 
Join Date: Feb 2004
Location: Cincinnati, OH
Posts: 1,086
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by jdhughes63 View Post

Wednesday morning and ther new TW line-up. What a screw job. TNT and Discovery HD, are now subscription as well as ESPNHD 1 & 2. I have HD with TW and also pay for the extra level and have now lost the above 4 channels.

However I still get UHD, MOJO and the 2 HDNETs. But can no longer get TNTHD, Discovery HD or ESPN HD.

I noticed this also. Called TW and they said that they are in the process of "re-tooling" these channels and that they will not be subscription when they are done. I was told that it would take a couple of hours. I was also told a couple of hours when I called at 7:30 am.
slimm is online now  
Sponsored Links
Advertisement
 
post #7742 of 14413 Old 08-29-2007, 08:09 AM
 
Splicer010's Avatar
 
Join Date: Jul 2007
Posts: 7,819
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 32
The current clear QAM channel line-up (Amelia HE) as of 8-29-07 @ 10:00AM...

87-21 Music (Audio Only)
87-22 "
87-23 "
87-24 "
87-25 "
101-23 Sports On Demand MLB Extra Innings Schedule
101-791 "
104-11 Time Warner Services Preview Channel
104-779 "
105-1 WLWT
105-3 KET1 (No program audio)
105-4 KET2 " "
105-5 KET ED " "
105-6 KET ED " "
105-17 KET Logo
105-18 KET Logo
105-33 NBC WeatherPlus
109-2 WXIX
109-7 WCET HD
109-8 WCET Create
109-9 WCET World
109-28 The Tube
114-21 WKRC
114-22 The CW
114-31 WCPO
120-6 ESPN Spanish/Latin Edition
121-12 WSTR
127-11 ESPN Radio
127-12 "
127-13 "
127-14 "
127-15 "
127-16 "
127-779 "
127-780 "
127-781 "
127-782 "
127-783 "
127-784 "
128-1 Univesal HD (UHD)
129-1 NBA Pass Preview
129-769 "
131-21 Music (Audio Only)
131-22 "
131-23 "
131-24 "
131-25 "
131-26 "
131-27 "
131-28 "
131-29 "
131-30 "
131-31 "
131-32 "
131-33 "
131-34 "
131-35 "
131-36 "
131-37 "
131-38 "
131-39 "
131-40 "
Splicer010 is offline  
post #7743 of 14413 Old 08-29-2007, 09:40 AM
Member
 
jdhughes63's Avatar
 
Join Date: Sep 2006
Location: Miami Township, Clermont County
Posts: 193
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by slimm View Post

I noticed this also. Called TW and they said that they are in the process of "re-tooling" these channels and that they will not be subscription when they are done. I was told that it would take a couple of hours. I was also told a couple of hours when I called at 7:30 am.

I now have all back on except ESPN2HD. It still says it is a subscription service. They announced this change a long time ago. Seems there was plenty of time to get ready for this mornings change over.

I am now receiving the left and right edges of ESPN2HD. THe center is blocked bt a screen that says it is subscription service
jdhughes63 is offline  
post #7744 of 14413 Old 08-29-2007, 09:50 AM
AVS Special Member
 
slimm's Avatar
 
Join Date: Feb 2004
Location: Cincinnati, OH
Posts: 1,086
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by jdhughes63 View Post

I now have all back on except ESPN2HD. It still says it is a subscription service. They announced this change a long time ago. Seems there was plenty of time to get ready for this mornings change over.

Same here. I'm hoping that they're not finished yet. I'm going to be pissed if there is an extra charge for ESPN2 HD.

Just called and apparently they are still working on it.
slimm is online now  
post #7745 of 14413 Old 08-29-2007, 10:37 AM
Senior Member
 
plughplover's Avatar
 
Join Date: Jun 2004
Posts: 302
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by Nitewatchman View Post

After stewing on it today/tonight a bit when I had a few minutes, and first trying to think of it from the perspective of "ok, lets assume your receiver would "work" OK for all the active ch 84 streams between 8pm and 12am if either 1). the PMT's remained active for KET3,5,6 from ~8pm to 12am so the service location descriptors for the streams would be present ... OR #2). The service location descriptors was carried by TW in a CVCT ....

As far as I'm aware there is no "ATSC Service Location" descriptor in the PMT. The PMT does, however, contain critical information about the ESs, for example stream type and PID. I don't know if that info is actually encoded the same way in both cases, but tsreader does not report them the same way - compare "Program Map Table(s)" vs "Terrestrial Virtual Channel Table" sections in the reports for your OTA caps. But they both can provide this critical information.

Quote:


At first, all I came up with was, *IF* this is the issue(and it seems to me we have a fair amount of evidence to suggest it might be), it could be either or both that would work ...(my best WAG is both, but again that's just a guess) ....

If I may refer you to one of your own A65c quotes here it plainly indicates the answer is not only "yes", but it is 'yes' intentionally and by design.

Quote:


Now, Before going any farther, I have to say I am confused concerning whether the info reported in your TSreader HTML output files listed under TVCT section is info coming from a TVCT(if so with some info stripped out from what KET is sending in their TVCT it seems) or CVCT generated solely by cableco ...

You are asking two differant questions here:
1) The report is mislabeled; the GUI, over in the left hand pane says "CVCT"
2) I don't know if TWC is generating the CVCT by themselves, or if it is taking the TVCT and massaging it.

I'm not going to quote/respond to the bulk of your post; suffice it to say your reasoning is similar to mine.

Quote:


Again, just a wild guess, but *maybe* that's a clue that if you did have the PMT's for KET3,5+6 between 8pm~12am, perhaps it would "work" ....

HOWEVER, I think though it's *just as likely* it would work with the proper info (including service location descriptor) in ?VCT(probably CVCT as William had posted previously) as well ...

I differ with your second conclusion ("just as likely") because of the "gotcha" we chuckled about (in that same quote).

I come from a software development background, a significant portion of which has been on 'standards based' applications. With this in mind -

Suppose you are a chip designer / firmware writer.

Since no psip data of ANY type is required on cable, are you going to code/impliment a dependance on it?

Perhaps if your design allows you to easily re-use code from the OTA case, you might hook it in for the cable case, in the off chance it is there. Or perhaps you want a 'feature rich' model that will use any/all available data, so you invest the time and effort to process optional data.

Or you may simply code the cable case for the 'lowest common denominator', and completely ignore all the optional info.

Based upon observation of *my* set's behaviour, I'm pretty sure *my* set doesn't bother to look for the optional info. It doesn't remap qam channels (ignores cvct) doesn't do qam guide stuff (ignores eit/epg), etc. FCC may have mandated things for OTA, but cable is 'anything goes'. (Remember an earlier post I made about TWC channel 80? Digicipher 2 streams; MPEG audio streams. 524x480i video streams...)

That's why I said earlier, that if I do get TWC to insert the Service Location descriptor in their CVCT I suspect it will fix things for some receivers (for example splicer010?) but won't for *mine*.
plughplover is offline  
post #7746 of 14413 Old 08-29-2007, 12:56 PM
AVS Special Member
 
jim tressler's Avatar
 
Join Date: Apr 2004
Posts: 2,107
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 15
wow - i think this is the most action the board has had in years.. good deal!
jim tressler is offline  
post #7747 of 14413 Old 08-29-2007, 01:56 PM
AVS Special Member
 
jimp2244's Avatar
 
Join Date: Dec 2005
Location: Cincinnati
Posts: 1,587
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by jim tressler View Post

wow - i think this is the most action the board has had in years.. good deal!

Yes... I am starting to think we need a whole forum and not just a thread to keep all the topics straight!

Drop pay-TV. Put up an antenna. Enjoy free HDTV. Save $60-100 or more per month!
jimp2244 is offline  
post #7748 of 14413 Old 08-29-2007, 03:14 PM
Member
 
jdhughes63's Avatar
 
Join Date: Sep 2006
Location: Miami Township, Clermont County
Posts: 193
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by slimm View Post

I noticed this also. Called TW and they said that they are in the process of "re-tooling" these channels and that they will not be subscription when they are done. I was told that it would take a couple of hours. I was also told a couple of hours when I called at 7:30 am.

7:30 AM you were told 2 hours. It is now 5:30 PM and still no ESPN2-HD. In continues to come up a subscription service Looks like they weren't ready for the change over. At least they gave me back my TNT-HD and Discover-HD. Those were missing this morning.
jdhughes63 is offline  
post #7749 of 14413 Old 08-29-2007, 03:47 PM
AVS Special Member
 
slimm's Avatar
 
Join Date: Feb 2004
Location: Cincinnati, OH
Posts: 1,086
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by jimp2244 View Post

Yes... I am starting to think we need a whole forum and not just a thread to keep all the topics straight!

No, we need one for plughplover and Nitewatchman
slimm is online now  
post #7750 of 14413 Old 08-29-2007, 03:49 PM
AVS Special Member
 
slimm's Avatar
 
Join Date: Feb 2004
Location: Cincinnati, OH
Posts: 1,086
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by jdhughes63 View Post

7:30 AM you were told 2 hours. It is now 5:30 PM and still no ESPN2-HD. In continues to come up a subscription service Looks like they weren't ready for the change over. At least they gave me back my TNT-HD and Discover-HD. Those were missing this morning.

I've been calling since that time with no resolution in sight.
slimm is online now  
post #7751 of 14413 Old 08-29-2007, 04:11 PM
Senior Member
 
plughplover's Avatar
 
Join Date: Jun 2004
Posts: 302
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
tnt-hd and discovery-hd still 'conditional access' here

ie not available clear-qam
plughplover is offline  
post #7752 of 14413 Old 08-29-2007, 04:30 PM
AVS Special Member
 
slimm's Avatar
 
Join Date: Feb 2004
Location: Cincinnati, OH
Posts: 1,086
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by plughplover View Post

tnt-hd and discovery-hd still 'conditional access' here

ie not available clear-qam

Thanks for mentioning that. I hadn't noticed with all my other ramblings about TWC today.
slimm is online now  
post #7753 of 14413 Old 08-29-2007, 04:48 PM - Thread Starter
AVS Special Member
 
Nitewatchman's Avatar
 
Join Date: Dec 2001
Location: Middletown, Ohio
Posts: 6,292
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 18
It is nice to see this thread this active ... I'm probably going to be somewhat limited in time to particpate the next several weeks or more, so I probably won't have time for a lot of posts like this one, but I *do* hope some of this info is useful to plughplover in his endeavors ....

Quote:
Originally Posted by plughplover View Post

As far as I'm aware there is no "ATSC Service Location" descriptor in the PMT.

Yeah, I know, my mistake ... I edited those comments a couple of times, and supppse I should have either "seperated" my references to service location descriptor in VCT vs. stream description info in PMT, **OR*** left all references to either as something along the lines of "the info in PMT or VCT that describes the Es's" .. rather than specifiying "service location descriptor" for both which as you note in inaccurate and only "specifically" applies in VCT ...

IN any case, it seems you understood what I meant ....

Quote:


If I may refer you to one of your own A65c quotes here it plainly indicates the answer is not only "yes", but it is 'yes' intentionally and by design.

I was reffering specifically to whether or not *your* particular receiver would work with either. As I said, I expect it's both, but I think its just a guess at this point because we do not know whether your receiver is following any sort of specific "guidelines". If it *were* following the info in A65c regarding digital cable receivers (much of which we haven't discussed) I think it would more likely be designed with "autoscanning features" and CVCT info in mind ... more on that later in this post ...

In other words, keep in mind That info in the quote does NOT necessarily describe the design of your receiver. There aren't required standards for manufactuers to follow regarding this type of thing.

Also, If you read more of that A65c document, you will also see that a cableco could send TVCT (no CVCT) INSTEAD of CVCT .... But, would your receiver work with it? It should, but I have no idea whether it would or not .... Can't imagine why it wouldn't, however ... Even the required PID memory addresses are the same(the table_id memory address is not, however) ...

Quote:


You are asking two differant questions here:
1) The report is mislabeled; the GUI, over in the left hand pane says "CVCT"
2) I don't know if TWC is generating the CVCT by themselves, or if it is taking the TVCT and massaging it.

If I understand that correctly (regardless of "where" the info is coming from) then, you're saying that TW is ONLY sending a CVCT and not TVCT as well ? I know that seems like a strange question, especially in the context of the below since I know no local station is sending CVCT OTA ---- Still, just wondering if for whatever reasons it's possible TW could be sending both+ or "messing something up" if they are trying to send both ...

A couple of quotes regarding the above from ATSC A65C document :

Quote:


5.2 Requirements for Cable
The rules governing the transport of PSIP tables for cable are:
• Requirement 6: The required tables for a cable system are: the STT,either the CVCT or the TVCT, and the MGT ...

Note it says *either* the CVCT or TVCT, not both, although it doesn't say both can't be carried ...

And, perhaps I'm "reading it wrong" but there is this(bolded section in particular) curiousity which *seems* to me to indicate a broadcaster *could* send both, and, through inferrence(devices using OTA use TVCT, devices using cable use CVCT), perhaps both perhaps *could* be carried on cable :

From A65C document, section 6.3.2 "Cable virtual channel table" :

Quote:
Originally Posted by ATSC A65c document View Post

The Cable Virtual Channel Table may be present in a terrestrial broadcast multiplex when a broadcaster has coordinated consistent channel labeling/numbering with all local cable operatorscarrying that multiplex, and different channel labeling and/or numbering between cable and terrestrial broadcast is desired. When both CVCT and TVCT are present in the multiplex, receiving devices are expected to use the TVCT to navigate services received via terrestrialbroadcast and the CVCT to navigate services received via cable.

Well, obviously if a receiver is being used that's receiving via cable when both the TVCT+CVCT is present in the "multiplex", they have to be talking about a signal sent via cable rather than OTA ...

Guess it's a moot issue since I know there are no stations in this area sending CVCT in their OTA MUX, just wondering given the apparent "mislabling" of the TSreader VCT info if TW could be sending "both", perhaps, possibly in an "incorrect" manner ...

Quote:


I differ with your second conclusion ("just as likely") because of the "gotcha" we chuckled about (in that same quote).

I would point out earlier in your post you said "yes" it would "work with both" ....

I would submit that it *should work* fine with either method (such as w/o or with PSIP) ... Because if it doesn't you're probably likely to run into some problems one way or another even *if* everything is done properly by the Cableco+broadcaster, given(as you mention) all the "different stuff" you're going to be getting via "clear QAM" cable ...

Farther below, In the CONTEXT of Digital TV signals of broadcasters carried on cable, I'll go a little more into why I said it seems to me "just as likely" your receiver's designers would want it to 'work' with CVCT, such as perhaps with the service location descriptors, including providing additional on this from the A65c document ....

Quote:


Since no psip data of ANY type is required on cable

Who said that? From ATSC A65C document , section "7. THE TRANSITION TO PSIP ON CABLE IN THE UNITED STATES OF AMERICA ...." :

Quote:
Originally Posted by ATSC A65C docuemnt View Post

Federal regulations adopted by the FCC (47 CFR §76.640) require cable operators to include A/65 PSIP data including virtual channel tables and event information to describe services carried in-the-clear, when such PSIP data is made available to them from the content provider. This same section of the FCC rules states that System Information carried out-of-band must include a textual channel name for each channel carrying a scrambled service.

What does that "mean" exactly? Well, for one thing as it turns out it does *not* apply to cable systems with less than 750MHZ bandwidth (does TW Cincy have less than 750MHZ bandwidth ???) ...

what exactly does FCC 47 CFR $76.640 Say? See it here in Black and white :

http://www.hallikainen.com/FccRules/2007/76/640/ ...

And here's the "PSIP relevant" portions of that section (I removed the "non-PSIP relevant" info from it)

Quote:
Originally Posted by PSIP relavent sections from 47CFR $76.640 View Post

(a) The requirements of this section shall apply to digital cable systems. For purposes of this section, digital cable systems shall be defined as a cable system with one or more channels utilizing QAM modulation for transporting programs and services from its headend to receiving devices. Cable systems that only pass through 8 VSB broadcast signals shall not be considered digital cable systems.

(1) Digital cable systems with an activated channel capacity of 750 MHz or greater shall comply with the following technical standards and requirements:

(iv) For each digital transport stream that includes one or more services carried in-the-clear, such transport stream shall include virtual channel data in-band in the form of ATSC A/65B: “ATSC Standard: Program and System
Information Protocol for Terrestrial Broadcast and Cable (Revision B)” (incorporated by reference, see Sec. 76.602), when available from the content provider. With respect to in-band transport:

(A) The data shall, at minimum, describe services carried within the transport stream carrying the PSIP data itself;

(B) PSIP data describing a twelve-hour time period shall be carried for each service in the transport stream. This twelve-hour period corresponds to delivery of the following event information tables: EIT–0, –1, –2 and –3;

(C) The format of event information data format shall conform to ATSC A/65B: “ATSC Standard: Program and System Information Protocol for Terrestrial Broadcast and Cable (Revision B)” (incorporated by reference, see Sec. 76.602);

(D) Each channel shall be identified by a one- or two-part channel number and a textual channel name; and

(E) The total bandwidth for PSIP data may be limited by the cable system to 80 kbps for a 27 Mbits multiplex and 115 kbps for a 38.8 Mbits multiplex.

(v) When service information tables are transmitted out-of-band for scrambled services:

(A) The data shall, at minimum, describe services carried within the transport stream carrying the PSIP data itself;

(B) A virtual channel table shall be provided via the extended channel interface from the POD module. Tables to be included shall conform to ANSI/SCTE 65 2002 (formerly DVS 234): “Service Information Delivered
Out-of-Band for Digital Cable Television” (incorporated by reference, see Sec. 76.602).

(C) Event information data when present shall conform to ANSI/SCTE 65 2002(formerly DVS 234): “Service Information Delivered Out-of-Band for Digital Cable Television” (incorporated by reference, see Sec. 76.602) (profiles 4 or higher).

(D) Each channel shall be identified by a one-or two-part channel number and a textual channel name; and

(E) The channel number identified with out-of-band signaling information data should match the channel identified with in-band PSIP data for all unscrambled in-the-clear services.

What also may be interesting is some of what it says elsewhere in A65C regarding cable's "requirements" to carry PSIP info ... *do* keep in mind that there is a lot more detailed info on Cable carriage of PSIP in the document than I can quote here as it would be *way too long*! As if this already isn't! Which is one reason why I would suggest you download+examine the entire document for yourself, in this case, including but not limited to for instance page 141~148 "ANNEX G: AN OVERVIEW OF PSIP FOR CABLE (INFORMATIVE)"

So,below I'm just posting one what I'll generally call two of the "summary" sections of some interest here :

Quote:
Originally Posted by A65C document View Post

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 of the other PSIP tables included in this Transport Stream except for the System TimeTable (STT).
• The Rating Region Table (RRT) defining the TV parental guideline system (rating information) referenced by any content advisory descriptor carried within the Transport
Stream, except the RRT corresponding to rating_region 0x01 (US + possessions).
• The System Time Table (STT), defining the current date and time of day.

.........................................................

5.2 Requirements for Cable
The rules governing the transport of PSIP tables for cable are:
• Requirement 6: The required tables for a cable system are: the STT,either the CVCT or the TVCT, and the MGT. For any region that makes use of the capability to change the RRT, that RRT shall be included in the TS if any content_advisory_descriptor in use refers to that region. An RRT defining the rating system for a given region shall be included in the TS if any content_advisory_descriptor in use refers to that region, unless that region has explicit standards that define the rating system and the meaning of the values in the content_advisory_descriptor.
• Requirement 7: The PSIP tables shall describe all of the digital channels multiplexed in the Transport Stream. For convenience, the tables may optionally include information
about analog channels as well as other digital channels available in different Transport Streams.

And there's also this From Annex G (info on PSIP via cable):

Quote:
Originally Posted by A65C document View Post


2. OVERVIEW
PSIP was designed, as much as possible, to be independent of the physical system used to deliver the MPEG-2 multiplex. Therefore, the System Time Table, Master Guide Table, Virtual Channel Table (VCT), and Event Information Tables and Extended Text Tables are generally applicable equally as well to cable as to terrestrial broadcast delivery methods. The differences can be summarized as follows:
• For cable, the Cable Virtual Channel Table (CVCT) provides the VCT function, while the Terrestrial Virtual Channel Table (TVCT) applies for terrestrial broadcast. The cable VCT includes two parameters not applicable to the terrestrial broadcast case, and the semantics of several parameters in the table are slightly different for cable as compared to the terrestrial broadcast case. The specifics are discussed in Section 3 of this Annex.
• While the standard requires delivery of the first four EITs (EIT-0-3) in the case of terrestrial broadcast, no such requirement exists for the cable. Inter-industry agreements and FCC regulations, however, have established certain practices with regard to the carriage of PSIP data when provided to the cable operator by the program provider,including terrestrial broadcast. Section 7 describes these regulations and agreements.

------------------------------------

Quote:


Perhaps if your design allows you to easily re-use code from the OTA case, you might hook it in for the cable case, in the off chance it is there. Or perhaps you want a 'feature rich' model that will use any/all available data, so you invest the time and effort to process optional data.

See below Also From Annex G of ATSC A65c document :

Quote:
Originally Posted by A65c document View Post

5. USING PSIP ON CABLE
PSIP data carried on cable in-band is analogous to PSIP included in the terrestrial digital broadcast multiplex: a receiver can discover the structure of digital services carried on that multiplex by collecting the current VCT from it. A cable-ready digital TV can visit each digital signal on the cable, in sequence, and record from each a portion of the full cable VCT. This is exactly the same process a terrestrial digital broadcast receiver performs to build the terrestrial channel map.

NOTE: Farther below I'll also quote some other sections of A65C you should be very interested in for various reasons, Including "receiver design" implications ... Although AGAIN, I would really recommend you download the entire document and examine it carefully, yourself .. Maybe that way at least I won't have to include such long quotes in my posts either

Quote:


Based upon observation of *my* set's behaviour, I'm pretty sure *my* set doesn't bother to look for the optional info. It doesn't remap qam channels (ignores cvct) doesn't do qam guide stuff (ignores eit/epg), etc.

Probably. However, it seems possible to me that Maybe it isn't. Maybe If it can't get everything it needs from CVCT (presumably service location descriptors) perhaps it's also possible that it may be going into "non-PSIP mode" *JUST* because of that ....

If so, I suggest it's possible you may not quite be seeing the "true behavior" of your set in this regard, at all ... The way I read it, Especially Given that PSIP seems "integral" to how receivers(receiving Digital TV broadcast from Broadcasters via OTA OR cable) are "supposed" to work as is described in A65C document(including in various quotes I provide from it in this post) ... And yet, there is some, but you do not find a WHOLE lot of info in the ATSC specs about receivers(used with cable or OTA) channel tuning/program selection "implementations" regarding the MPEG2 PSI info (such as from PMT/PAT) ....

Let's consider for a moment that bbrodreck's vizio set seems to be mapping to the VCT major/minor channel numbers just fine ... And, let's consider for a moment that if I recall correctly, he was having problems with KET4 *UNTIL* the service_ID (service name as Tsreader calls it) began showing up in your TSreader output files in the VCT section, but of course the service location descriptors are still not there ...

Soo, *HIS* receiver may not need the service location descriptors to properly process CVCT and remap to the Virtual channel numbers(and instead need the service ID info), but your's *might* need it ... I agree that's a long shot, as why wouldn't the VC #'s and maybe service ID be enough like on Bbrodreck's set .... but I do try to look at all the possibilities ...

Quote:


FCC may have mandated things for OTA, but cable is 'anything goes'. (Remember an earlier post I made about TWC channel 80? Digicipher 2 streams; MPEG audio streams. 524x480i video streams...)

It may be "anything goes" in practice at this time, but as far as the "rules" go for digital cable carriage of digital broadcast signals on it's not ... Regarding PSIP, it's required for cable systems 750MHZ bandwidth or greater .... See the info I provided farther above on FCC regulations for PSIP via cable ... IS TW Cincy required to carry PSIP regarding DTV signals from broadcasters? If it's equal to or greater than 750MHZ capacity they are ....

As already discussed, just to restate it --- I do agree with you that it seems quite likely your receiver would, or at least should "work" if the Es "stream descriptions" for KET3,5,6 were in PMT between 8pm~12am ...

It is really confusing info in the ATSC documents at times ... But, If I am "decipering" it correctly, it seems to be saying *if* the cableco is not carrying the ES stream descriptor info in CVCT, then that info *HAS* to be present in PMT .. BUT, the way I'm reading it(see the PSIP cable specific quotes from ATSC A65c document I provide farther below) It would be the cableco that would be responsible for that(if it's not already there in PMT), And of course William's comments on the matter also seem to indicate it is NOT KET who is *required* to make it that way if it is necessary ...

Quote:


That's why I said earlier, that if I do get TWC to insert the Service Location descriptor in their CVCT I suspect it will fix things for some receivers (for example splicer010?) but won't for *mine*.

But again, earlier in your post you also said it would work with the BOTH(or either) the service location descriptor in CVCT, OR the stream "description info" in PMT .... LOL .... Don't worry, I was doing the same thing when "developing" my last post on this, which perhaps might be best described as "going around in circles chasing my tail" .....and that is probably why some of it may have not seemed very "clear" .... Easy to do with this sort of thing ...

--------------------------------

Some other interesting quotes from ATSC A65C (and A65B) documents and some thoughts ...

Along with some comments Here are some more quotes from ATSC A65C and ATSC A65B documents, which I think are very relevant to "reciever design" issues and channel/program selection issues. Do keep in mind currently the FCC rules for PSIP for OTA AND cable specify A65B - an earlier version of the standard ... FCC is deciding whether to update the requirements to A65c in their currently ongoing 3rd DTV review(they probably will and there is not a lot of differences in the two )-- They are "mostly" the same, HOWEVER, I did just find one "interesting" difference in the A65b+A65c documents ......

Regarding "service location" descriptor Lets look at this part of it from the section 6 "remultiplexing issues" from annex G of ATSC A65 and A65B especially closely ....

Quote:
Originally Posted by from ATSC A65c document View Post

• The service_location_descriptors present in incoming Terrestrial Virtual Channel Tables may not be deleted, but in order to identify all the services in the Cable Virtual Channel Table for a new transport stream, they may need to be modified (if they are no longer accurate because of PID changes). The business and regulatory processes related to PID changes and this modification are outside the scope of this Standard.

Well, OK, so maybe it's specifying just that they can't be deleted from TVCT(which doesn't matter a whit if you're not getting TVCT and only getting the cableco's CVCT) ... but gee, it also says elsewhere it's not required to be carried by cable in CVCT ... what to make of that, I dunno ..

NOW --- BUT, What does it say in this same section in ATSC A65B document(the current required standard) ?

Quote:
Originally Posted by ATSC A65B document View Post

The service_location_descriptors present in incoming Terrestrial Virtual Channel Tables may be deleted, and if so should be reconstructed to identify all the services in the Cable Virtual Channel Table for a new transport stream. [/b]

Among other things, I think you might also gain a bit of understanding of the "issues" a software engineer on a team designing a receiver/set would need to be thinking about from some of the following quotes from the A65C document(again,A65b is "mostly" the same") .....

From section 5.1 of annex G "Terrsetrial Virual Channel Maps on Cable" -- most of this quote isn't applicable to your(and most digital cable) situation(8VSB via small cable systems/etc) -- But I think the part in bold should be regarding receiver design issues ..

Quote:
Originally Posted by ATSC A65c document View Post

5.1 Terrestrial Virtual Channel Maps on Cable
If a cable operator chooses to deploy digital cable boxes in a cable network, to properly support the cable terminals, that network will need to conform to the transmission and transport standards defined through the Society of Cable Telecommunications Engineers (SCTE). In some instances, however, a small cable operator may offer a cable service in which no cable boxes are required. That operator may wish to implement a low-cost headend where off-air terrestrial broadcasts are simply received and placed onto the cable, as is done with a community antenna scheme such as SMATV. In some cases, signals may be shifted in frequency before being placed on the cable (such as to move a UHF frequency down to the VHF range). In cases such as these, a receiver may encounter a Terrestrial Virtual Channel Table when it processes an 8-VSB signal Stream from the 75 Ω cable port on the receiver. Although the TS on such 8-VSB may not strictly conform to SCTE standards for digital cable, cable-ready receivers should nonetheless be designed to handle the case where a Terrestrial VCT is found where a Cable VCT is expected.

From Annex G, sections 5.2 "use of the Cable VCT" (CVCT), 5.3 "Service Location on Cable", and section 6. "remultiplexing issues" (I included all of these as there's some pertinent info in one section that relates to another -- such as how cable is supposed to handle TSID+the issues involved with remultiplexing) -- Note there is just WAY too much stuff of interest in here to bold the interesting parts, so I won't try that this time :

Quote:
Originally Posted by A65C document View Post


5.2 Use of the Cable VCT
Cable signals are transmitted in accordance with established frequency plans, so initially discovering the location of each digital or analog carrier is straightforward. PSIP data typically describes services carried on the same Transport Stream as the PSIP data itself (although it may describe other services on another TS). The channel_TSID value for these services is required to match the TSID value found in the PAT of the Transport Stream of the indicated service. Whenever PSIP data references a service carried on a different digital Transport Stream orreferences an NTSC analog service, the channel_TSID should be used to positively identify the target TS or analog service. The recommended approach involves use of a digital signal’s Transport Stream ID (TSID) and an analog NTSC signal’s Transmission Signal ID (analogTSID). The FCC has rules for the use of both the TSID and the analog TSID by each broadcast station operator in the US. Each station has two unique TSID values, one for analog and one for digital transmission. The digital TSID is defined by the MPEG-2 Systems specification, ISO/IEC 13818-1. Transport of the analog TSID is defined in CEA-608-C; it is simply a 16-bit signal identifier that is carried in an Extended Data Service (XDS) packet.

Upon initial setup by an installer or consumer, a receiver should perform an automatic scanof all frequencies where analog or digital signals may be found.23 The frequencies used for the scan correspond to standard frequency plans for off-air broadcast or cable, as appropriate. When a signal is found at a given frequency, the receiver should take note of the analog or digital TSID. Although not all analog signals are required to include TSIDs, all digital transport streams are required to carry the a TSID. The TSID for each TS referenced by a CVCT needs to be unique on that cable system for PSIP-based tuning to be effective. When asked to acquire a specific service, the receiver should use the frequency upon which it was last found and verify the TSID.

The data in the modulation field may be in error unless the cable system modifies it. The SCTE has standardized two modulation modes for cable television transmission of digital
television. The terrestrial broadcast PSIP shall indicate ATSC 8-VSB modulation for over-the air transmission of digital television. Any receiver that does not have access to an out-of-band data stream indicating the modulation modes of the various carriers on the network will need to be designed to acquire any of the modes that may be present. In the US, 64-QAM, 256-QAM, or 8-VSB modulation may be encountered.

23 It is strongly recommended that such a scan is done also when the receiver is in the “off” state to refresh VCT and program guide data.

5.3 Service Location on Cable
The service_location_descriptor() indicates the stream types, PID and language code for each member of the collection of program elements that comprise a virtual channel. As mentioned, one of the differences between the terrestrial and cable is that the service_location_descriptor() is not required in the Cable VCT, even though its use is mandatory for the Terrestrial VCT. The difference arises from the fact that cable operators may re-multiplex digital Transport Steams that are available to them, adding, deleting or moving services to create cable Transport Streams, and some services
may not have the information needed to facilitate creation of the service_location_descriptor(). Some cable system equipment does not have the capability to format the information into the service_location_descriptor() when the information is available. A motivation for re-multiplexing is that the data rate for information on cable is typically higher than that available from terrestrial broadcast transmissions, and a cable operator may wish to construct multiplexes that make fulluse of the channel capacity.

Therefore, when there is no service_location_descriptor(), the receiver or set-top box needs to learn the structure of each service via the TS_program_map_section() which contains essentially the same information as the service_location_descriptor(). ATSC (and SCTE) Standards require the presence and correct construction of the TS_program_map_section().

A typical cable receiver or set-top box may implement a scheme where the last-used PID values for audio and video streams are stored with each VCT record in the device’s memory. Initial acquisition of a virtual channel may be slower by as much as 400 milliseconds (the maximum interval between repetitions of the TS_program_map_section()) since the TS_program_map_section() will need to be processed to learn the PID values, but this delay can be avoided on subsequent acquisitions by making use of the stored values. In any case, one step in the acquisition process should always be to check the current TS_program_map_section() to verify that the PID values have not changed since the last acquisition of the service. If they have changed, the new values replace the old.

6. RE-MULTIPLEXING ISSUES
As mentioned, a cable operator may take incoming digital Transport Streams from various sources (terrestrial broadcast, satellite, or locally generated), add or delete services or elementary streams, and then re-combine them into output Transport Streams. If the incoming Transport Streams carry PSIP data, care must be taken to properly process this data in the re-multiplexer.

Specifically, the re-multiplexer needs to account for any MPEG or PSIP fields or variables that are scoped to be unique within the Transport Stream. Such fields include PID values, MPEG program_numbers, source_id tags that are in the range 0x0001 through 0x0FFF and event_id fields.

Other PSI and PSIP-related tasks that need to be performed include:
• Construct an output Virtual Channel Table represents the virtual channels that will be included in the resulting Transport Stream.
• Combine EIT and ETT data from the various sources and remove data for any deleted services. (Rules for deleting services are beyond the scope of this standard.)
• Construct the output Rating Region Table to include all regions that the cable operator is either required to support or chooses to support.
• Rebuild the Master Guide Table to represent the resulting PSIP tables.
• The service_location_descriptors present in incoming Terrestrial Virtual Channel Tables may not be deleted, but in order to identify all the services in the Cable Virtual Channel Table for a new transport stream, they may need to be modified (if they are no longer accurate because of PID changes). The business and regulatory processes related to PID changes and this modification are outside the scope of this Standard.
• Edit the MPEG-2 Program Map Table to accurately reflect the Transport Stream PID values for all elementary streams in each service.

The special case of remultiplexing without adding or dropping content in the source transport stream does not require PSIP modification, as long as other services being added during theremultiplexing do not have conflicting PID values and use TS_program_map_section()s that do notconflict with the source streams containing PSIP data. This mode may be particularly attractive when 64 QAM is used, as only the PAT would need to be updated by the multiplexer combining the elements.

A typical cable receiver or set-top box may implement a scheme where the last-used PID values for audio and video streams are stored with each VCT record in the device’s memory. Initial acquisition of a virtual channel may be slower by as much as 400 milliseconds (the maximum interval between repetitions of the TS_program_map_section()) since the TS_program_map_section() will need to be processed to learn the PID values, but this delay can be avoided on subsequent acquisitions by making use of the stored values. In any case, one step in the acquisition process should always be to check the current TS_program_map_section() to verify that the PID values have not changed since the last acquisition of the service. If they have changed, the new values replace the old.

And there is from the "core descriptors" section of the A65c document concerning the Service location descriptor (a couple of especially "interesting" parts I've bolded) ... I'm not sure what they mean by saying it shall not be present for any active channel, as in their semantics, "channel" would not seem to refer to "program service" (such as is often referred to here as a "subchannel") ...

Also note that it doesn't *say* the broadcaster is required to provide "for cable" "the info in the service location descriptior" in PMT, it only says "for cable" The info in the service location descriptior is carried in the PMT (you'll have to download the document to see the "syntax defined in Ref. [8] ...

Quote:
Originally Posted by a65b ATSC document View Post

6.9.5 Service Location Descriptor
This descriptor specifies the stream types, PID and language code for each elementary stream. An instance of this descriptor shall appear in the TVCT for each active channel. A service_location_descriptor() shall not be present for any inactive channel. When present, the service_location_descriptor() must be valid for the current event in the corresponding virtual channel.

Note that for cable, the information in the service_location_descriptor() is carried in the PMT with the syntax defined by Ref. [8].

The service_location_descriptor() shall indicate the same Elementary Stream data as the corresponding portion of the Program Map Table currently being transmitted. At minimum, the Service Location Descriptor shall include the video elementary stream (if one is present in the service), and all audio streams present in the service.

Also, there's this interesting tidbit, also from the "core descriptors" section. Again what do they mean by "inactive channel" -- Perhaps they are referring to program services(subchannels), or minor channel number ... : ....

Quote:
Originally Posted by a65c ATSC document View Post

6.9.9 Descriptors for Inactive Channels
The service_location_descriptor() shall not be present for inactive channels. Any other descriptors, if present, shall provide valid information about the inactive channel. The
extended_channel_name_descriptor(), for example, can be used to provide the long-form channel name of the inactive channel.

And this, if I haven't quoted it before, from The "tuning and table access section" - the same section my quote from this document came from in earlier posts of mine ...

Quote:
Originally Posted by a65c document View Post

The PMT should always be processed and monitored for changes because, in some instances, the structure of a service may exceed the capability of the service_location_descriptor() to describe it. One example is a service that includes multiple audio tracks for the same language (see Section 6.9.8). In this case, the TS_program_map_section() carries the textual name for each of the tracks to help in user selection.


Jeff
Nitewatchman is offline  
post #7754 of 14413 Old 08-29-2007, 04:55 PM - Thread Starter
AVS Special Member
 
Nitewatchman's Avatar
 
Join Date: Dec 2001
Location: Middletown, Ohio
Posts: 6,292
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 18
Quote:
Originally Posted by slimm View Post

No, we need one for plughplover and Nitewatchman

That's why I suggested at one point earlier we might want to take our "detailed" discussions to PM or email ... But, don't want to leave anyone "out" that wants to read about it, and Plughplover's "has the ball" on this one so I think that should be up to him concerning how he handles it ...

Obviously though, if someone responds to one of my posts here+I feel compelled to respond to it/it requires a response, the place to do that is here ...

Jeff
Nitewatchman is offline  
post #7755 of 14413 Old 08-29-2007, 05:09 PM
 
Splicer010's Avatar
 
Join Date: Jul 2007
Posts: 7,819
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 32
Damn Jeff...How long did it take you to write/quote all of that???

As for the bandwidth TW has when we rebuilt the system some 8-9 years ago it was all balanced out to 750MHz...Since that time, if at all, it would only be increased since the system was built to 860MHz specs...
Splicer010 is offline  
post #7756 of 14413 Old 08-29-2007, 05:33 PM - Thread Starter
AVS Special Member
 
Nitewatchman's Avatar
 
Join Date: Dec 2001
Location: Middletown, Ohio
Posts: 6,292
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 18
^ Not long to write it or quote it, but in between "actual work duties" ALL DAY LONG to THINK about it ...

So, sounds like TW cincy is required to send PSIP for broadcasters signals as is specified/detailed in the code of federal regulations/FCC regulations as I quoted in that "long post" (and in ATSC a65b specs for cable carriage of PSIP) ... 750MHZ capacity or more on the cable system then it's required ...

Edit : A correction -- Actually the rules say PSIP has to be carried if the cable system's *activated* channel capacity is 750MHZ OR greater ....

Jeff
Nitewatchman is offline  
post #7757 of 14413 Old 08-29-2007, 05:46 PM
 
Splicer010's Avatar
 
Join Date: Jul 2007
Posts: 7,819
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 32
Quote:


Edit : A correction -- Actually the rules say PSIP has to be carried if the cable system's *activated* channel capacity is 750MHZ OR greater ....

...and it is... Balancing out to 750MHz IS activating channel capacity at 750MHz...
Splicer010 is offline  
post #7758 of 14413 Old 08-29-2007, 06:18 PM - Thread Starter
AVS Special Member
 
Nitewatchman's Avatar
 
Join Date: Dec 2001
Location: Middletown, Ohio
Posts: 6,292
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 18
To sum up that recent long post into something short for those that aren't interested in the details :

In the context of carriage of digital broadcast stations' signals on cable :

IT IS *JUST AS IMPORTANT* for receiver and software designers to properly implement PSIP support for QAM/digital cable for their digital cable reception products(inlcuding for "in the clear" reception, and especially for consumer owned/operated "digital cable ready" receivers) as it is for the MPEG2 PSI information, AND as it is for 8VSB/OTA ATSC receivers ...

IT IS ALSO just as important for cable companies to pass through the PSIP (and MPEG2 PSI) information properly(and/or modify it properly as necessary), REGARDLESS of whether or not they are required to pass through that PSIP info ... Just as it is important for them to remultiplex the broadcasters DTV streams properly ...

Jeff
Nitewatchman is offline  
post #7759 of 14413 Old 08-29-2007, 06:39 PM
 
Splicer010's Avatar
 
Join Date: Jul 2007
Posts: 7,819
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 32
I have been experimenting the last few evenings and I have been getting repeated results so thought I would post now...

As long as I have my LG LST3510a tuned to channel 105-6 (which is KET4 as everyonne calls it) KET ED before 8PM, at 8PM when KET switches to their HD feed, I get 105-33 NBC WeatherPlus video but no audio...Now when I either manually or just using the channel up/down button on the remote, change channels, (staying in the 105 channel realm) and return to 105-6, I get both video and audio. Then when scanning the other KET channels (105-3 & 105-4) I aso get the video and audio on those channels as well!

Now here it starts to get interesting...Remaining on 105-1 (WLWT) after the KET4 switch to HD, I get both video and audio for WLWT untill WLWT switches to the national NBC feed at which time the video changes to...you guessed it...the WeatherPlus video (105-33) but no audio! Now when I manually input 105-1 (essentially reacquiring or refreshing the channel) I get both video and audio from the NBC feed...

Now when I scan back to 105-6 (KET 4 which is now KET HD) I get the video only no audio on any of the remaining KET channels...

Once I leave the 105 channel realm (IE...I input 109-7 WCET) I will get the channel I input as I normally would but cannot return to the 105 channel realm. I mean I can return but I get the 'NO SIGNAL' message on screen and have no video or audio on any of the 105 channels...

So somehow somewhere someting is getting missed or mixed up. I still think it is my receiver, however I also feel it is on the transmission end...Ultimately I believe it is on TW part and feel that if they (TW) would simply move KET to its on channel realm while leaving the WLWT/NBC transmission on the 105 Realm, the problems would instantly cease. Because it is some sort of collision that is happening with all the embedded info that just wont jive together within the same channel realm...The reason it doesn't happen with WXIX (109-2) and WCET (109-7) is most likely due to (as was pointed out by Nightwatchman) the fact that KET is a state run PBS station VS. WCET which is a privately run PBS station.

So IF TW would be so kind as to notify any schools in Ohio that they serve that may (or may not) use KET for classes (wouldn't affect KY schools since TWcinci isn't running any of those systems) and would test the channel change I am quite confident the problem would be eliminated. That would be the simplist legal method to put this issue to rest.
Splicer010 is offline  
post #7760 of 14413 Old 08-29-2007, 06:53 PM
AVS Special Member
 
William Smith's Avatar
 
Join Date: Dec 2000
Location: Lexington,Kentucky,USA
Posts: 1,168
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 11
I believe that WCET is feeding TW via fiber not from their digital transmitter directly.
William Smith is offline  
post #7761 of 14413 Old 08-29-2007, 07:00 PM - Thread Starter
AVS Special Member
 
Nitewatchman's Avatar
 
Join Date: Dec 2001
Location: Middletown, Ohio
Posts: 6,292
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 18
Quote:
Originally Posted by Splicer010 View Post

So somehow somewhere someting is getting missed or mixed up. I still think it is my receiver, however I also feel it is on the transmission end...

Ultimately I believe it is on TW part ...

From what we know so far, I suspect you are correct on all of the above ....

Quote:


and feel that if they (TW) would simply move KET to its on channel realm
while leaving the WLWT/NBC transmission on the 105 Realm, the problems would instantly cease.

The problem with that is with QAM256 (what TW is using), they can fit ~38.8 Mb/s in each 6MHZ channel ... BUT broadcast digital stations can only fit 19.38Mb/s in a 8VSB ATSC channel .... so, if TW gave KET a "spot of it's own" they'd be wasting ~19 Mb/s of capacity (or 3MHZ to put it another way) ... If they used(if they could do this and all receivers would be OK with it) QAM64 for KET, then only ~19mb/s would "fit" in a 6MHZ channel, but they'd still be "wasting" 19Mb/s, as they could be using QAM 256 and multiplexing TWO transport streams from TWO digital broadcast stations ...

Quote:


Because it is some sort of collision that is happening with all the embedded info that just wont jive together within the same channel realm...The reason it doesn't happen with WXIX (109-2) and WCET (109-7) is most likely due to (as was pointed out by Nightwatchman) the fact that KET is a state run PBS station VS. WCET which is a privately run PBS station.

Well, I think the problem involves KET dropping/adding streams for KET3,5+6 between 8pm~12am, evidenced by noone is reporting the issue with any other TW channels carrying broadcasdt DTV signals(which don't have services that drop or are added at certian times of day) .... that's not to say it's that KET is doing something "wrong" because they aren't as far as i know or can tell .... And That has nothing to do with who "owns" KET or WCET ... In fact, there were problems like this at one time with WCET when WCET was adding/dropping streams(but in a little different way than KET does) as well ... But, they aren't doing that now ...

My point regarding KET being "state owned" mostly involved their KET5/6 KY Gov't coverage. Although how they are funded, and what their "mission" is could also relate to what they do on their other program services ...

Not to say "non-state owned" PBS Member stations might not do something like that as well ... In fact, WPTD-DT Dayton and several other ohio PBS stations carry "the Ohio channel" and they do indeed have Ohio St gov't coverage on it at times (I thought WCET carried it to, but only available via cable -- don't know if that's still the case or not) ....

Jeff
Nitewatchman is offline  
post #7762 of 14413 Old 08-29-2007, 07:04 PM - Thread Starter
AVS Special Member
 
Nitewatchman's Avatar
 
Join Date: Dec 2001
Location: Middletown, Ohio
Posts: 6,292
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 18
Quote:


I believe that WCET is feeding TW via fiber not from their digital transmitter directly.

That's what's been reported here from TW sources ...

Do note WCET doesn't add/remove program services at different times of day however, at least not OTA ... They did at one time, but not for the last couple of years or so ... OTA whenever their transmitter is on air it is (and has been for the last 2 years or so If I recall correctly - edit/except it was create instead of world, and at one time it was 2 SD +1 HD, one of them was PBS Kids I don't remember what the other one was) :

48.1 - PBS HD channel (they do upconvert SD from PBS's NPS from 6pm~7:30pm However)

48.2 - CET World .

Jeff
Nitewatchman is offline  
post #7763 of 14413 Old 08-29-2007, 07:31 PM
 
Splicer010's Avatar
 
Join Date: Jul 2007
Posts: 7,819
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 32
Quote:


they could be using QAM 256 and multiplexing TWO transport streams from TWO digital broadcast stations

Which from what I can gather is the whole problem...Nothing has to be "wasted". There is ample material that could be moved around to use that "wasted" bandwidth. But I doubt seriously that they are concerned with "wasting bandwidth" due to the simple fact they are already "wasting bandwidth" (at least in my system) With 12 channels (127 channel realm) of ESPN Radio...all channels areof the same feed...Also look at channel 121 in my system (channel lineup post 7744). only 1 station in that realm. KET could be moved to that channel realm very easily.

Quote:


I believe that WCET is feeding TW via fiber not from their digital transmitter directly.

That would be because TW fiber is literally right in front of the WCET studio downtown. However you have a valid point. I wonder if TW were to receive WCET via OTA the same as KET is received if the same problems would exist using the equipment they are using...
Splicer010 is offline  
post #7764 of 14413 Old 08-29-2007, 08:03 PM - Thread Starter
AVS Special Member
 
Nitewatchman's Avatar
 
Join Date: Dec 2001
Location: Middletown, Ohio
Posts: 6,292
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 18
Quote:
Originally Posted by Splicer010 View Post

Which from what I can gather is the whole problem...Nothing has to be "wasted". There is ample material that could be moved around to use that "wasted" bandwidth. But I doubt seriously that they are concerned with "wasting bandwidth" due to the simple fact they are already "wasting bandwidth" (at least in my system) With 12 channels (127 channel realm) of ESPN Radio...all channels areof the same feed...Also look at channel 121 in my system (channel lineup post 7744). only 1 station in that realm. KET could be moved to that channel realm very easily.

But, even if they *were* to put KET on it's own QAM channel, judging by the detailed info Plughplover has posted regarding how his receiver has been effected, and our previous dissucion regarding the seemingly "sequential" processing of the PMT PID info from PAT's (similar to what we observed with TSreader as we posted) in his case at least He'd likely still have problems with KET4, in "HD mode" ...

Or in otherwords, his receiver(and maybe yours too but perhaps in a different way it seems) would still probably "hang" looking for the info for/in KET3 PMT before it could get to the KET4 info and process it properly/decode it ...

It would however "fix" the problem for WLWT-DT streams ...

edit: Oh -- Still don't understand your "nothing has to be wasted" comment... in order not to "waste" the bandwidth, they have to multiplex "other stuff" with KET on any 6MHZ QAM256 channel, as KET is only/will only use 19.39Mb/s at most(no more as long as it's being received by TW OTA), and the bandwidth of a 6MHZ channel with QAM256 is 38.8Mb/s ...

So, they are multiplexing WLWT-DT's streams with KET's ... If you replace WLWT-DT's streams with something else, it's the same issue involving any issues involved with re-multiplexing KET's streams with "something else" ...

Quote:


That would be because TW fiber is literally right in front of the WCET studio downtown. However you have a valid point. I wonder if TW were to receive WCET via OTA the same as KET is received if the same problems would exist using the equipment they are using...

Plughplover reported in an earlier post that at one time TW had reports from LG set owners of problems with WCET-DT similar to current reports regarding KET(WCVN-DT locally).

As I've mentioned in at least 2 or 3 posts in the past week or so, I suspect that may have been because at one time WCET was adding/removing program services at certian times of the day.(it was 4 channel SD during the day, 1 HD+2 SD at night).

They did do that differently than KET does, as they removed the VCT+(I think the PAT info as well) on those streams when they were "removed", such that receivers(OTA at least) which relied on "channel scanning" solely for channel tuning "memory" functions would have to rescan every day and every night to be able to decode all of WCET-DT's services (or "subhchannels").

I'm not posistive but from what I can remember was shown at the time in the channel info on their website, I believe they were doing that via cable as well as OTA, I don't know if at that time they were sending the feed to the cableco via fiber or OTA ( I think it was fiber however) ...

Jeff
Nitewatchman is offline  
post #7765 of 14413 Old 08-29-2007, 08:42 PM
Senior Member
 
CincySaint's Avatar
 
Join Date: Mar 2004
Location: Loveland, Ohio
Posts: 286
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by slimm View Post

I've been calling since that time with no resolution in sight.

In re: ESPN2HD not available to those who should have it

For anyone in the cable industry...

How hard can it be to configure a channel to be part of a tier? I mean isn't this stuff computerized. Isn't it a matter of adding it to something existing?

If I were in sales or marketing at TWC Cincy, I'd be livid since all these subs are expecting ESPN2HD because it was marketed. As a customer, I'm not happy.
CincySaint is offline  
post #7766 of 14413 Old 08-29-2007, 09:01 PM
Senior Member
 
plughplover's Avatar
 
Join Date: Jun 2004
Posts: 302
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Nitewatchman, your grasp of and familiarity with 'the specs' never ceases to amaze me.

And yes, I had already downloaded a number of them (though I missed that A65b vs A65c bit - thanks). Also thanks for the CFR pointer...

I'm going to read that post a few more times, but I see your (main) point; perhaps twc's cvct really IS the problem / solution...

And you've given me more 'armament' for when I talk to them - thanks!

Oh and splicer010 - thanks for the detailed testing report; except for some of the audio problems, the behaviour you describe is quite similar to my set.

BTW, got calls from both Paul B. and Jack U. this evening. Nothing much to report though. I'm still pushing for a sit-down with Mike B.
plughplover is offline  
post #7767 of 14413 Old 08-29-2007, 09:06 PM
Member
 
chrisirmo's Avatar
 
Join Date: Mar 2005
Location: Milford, OH
Posts: 103
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by CincySaint View Post

In re: ESPN2HD not available to those who should have it

For anyone in the cable industry...

How hard can it be to configure a channel to be part of a tier? I mean isn't this stuff computerized. Isn't it a matter of adding it to something existing?

If I were in sales or marketing at TWC Cincy, I'd be livid since all these subs are expecting ESPN2HD because it was marketed. As a customer, I'm not happy.

I'll agree that it's ridiculous that TWC Cincy can't even launch a channel properly... and they've had four months longer than the rest of the divisions that launched it when the contract was signed. I called in and the absolutely clueless girl finally had me reboot my DVR and she "reinitialized" it. That got ESPN2HD to show up.

I also dropped the HD tier because I don't get $6.95 worth of value from Mojo, UHD, HDNet and HDNet Movies. I had to explain to their CSR that I could still get ESPNHD and ESPN2HD without the HD Tier. It's amazing to me that TWC has any customers with the amazing level of cluelessness amongst their CSRs.

I'm waiting to see how the new channels on D* look before I make the switch.
chrisirmo is offline  
post #7768 of 14413 Old 08-29-2007, 09:19 PM
Senior Member
 
CincySaint's Avatar
 
Join Date: Mar 2004
Location: Loveland, Ohio
Posts: 286
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by chrisirmo View Post

I'll agree that it's ridiculous that TWC Cincy can't even launch a channel properly... and they've had four months longer than the rest of the divisions that launched it when the contract was signed. I called in and the absolutely clueless girl finally had me reboot my DVR and she "reinitialized" it. That got ESPN2HD to show up.

Thanks.

I tried a hard re-boot alone but it still shows ESPN2HD as a subscription channel. I guess I'll have to call in tomorrow night when I have time.
CincySaint is offline  
post #7769 of 14413 Old 08-29-2007, 10:06 PM
Senior Member
 
cokebear's Avatar
 
Join Date: Oct 2004
Location: Middletown/ I-75,SR122 interchange.
Posts: 228
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 10
I'm now doing a full rescan on my set for TWC I have lost TNTHD and never havebeen able to find DiscHD even when I tuned to 105-30 which was 10 channels below TNTHD. My tuner is QAM.

Shawn
GT - CokeBear
cokebear is offline  
post #7770 of 14413 Old 08-29-2007, 10:13 PM
Advanced Member
 
Sea Ray's Avatar
 
Join Date: Sep 2003
Location: Cincinnati, OH
Posts: 592
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 10
I was wondering if a re-boot would do it. I spent about 30 mins on hold only to be told in a 30 sec conversation that ESPN2 would be fixed in the morning and it doesn't need a re-boot or an initialization from them. I would have liked to have seen the Yankees/Red Sox in HD but oh well. We'll see how it is tomorrow. I'm sure she had no idea whether it'd be fixed tomorrow.
Sea Ray is offline  
Reply Local HDTV Info and Reception

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off