Clear QAM DC-II video question (1 Viewer)

[jonesdb]

I just setup 1.0.2. Did a complete new scan on cable (Clear QAM) and noticed that several channels didn't show up in the TV Channels section. Instead, they show up under Radio Channels. Checking the streams with VLC I see that in general these channels are not MPEG-2 streams, but unencrypted DC-II video. If I change the channels to TV instead of Radio in the database, MP responds with no audio/video.
Question: Is the incorrect catagory during scan because of DC-II vidio? If so, is there a work around to be able to use these channels normally?
Thanks for any suggestions.

 

[mizzourob]

I've got a similar problem on my HTPC too, I'm guessing that jonesdb is on satellite if he's reporting DC-II video, but I'm on cable using a HDHomerun and I get the same problem that a handfull of channels are scanned as Radio and when I try to convert them to TV, MP reports that no audio/video is found. I've posted this to the HDHomerun forum and they said that since the missing channels are found in the HDHomerun setup application, that it's an issue with MP's QAM scans. This issue has been reproducible for me using all previous versions of the HDHomerun software/firmware all the way up to the present and including the beta drivers, along with all versions of MP 1.xx.xx.xx including 1.1 alpha+svn and on Windows XP, Windows Vista, and Windows Server 2008.. I've run out of combinations to test and think there's a small bug somewhere...

Anyone else with a similar issue? Or have any suggestions?

 

[mizzourob]

tv.log file

Here is my TV.log file that documents what's going on when it tries to tune a channel that was scanned and listed as radio, then I changed it to instead be listed as TV. The name of the channel in the log file is ESPNTEST

Ignore the warning at the top of the file that says unsupported OS; this bug is the same on all windows platforms (well ok I haven't tested on Win 7 yet) it doesn't matter what the OS is.

 

[tourettes]

What kind of video stream those channels are using? TVE3 is supporting only MPEG2 and H.264 codecs and from the log seems that there is no such available in the channel

2009-08-06 02:57:00.781637 [6]: subch:0 SendPMT version:18 len:29 2
2009-08-06 02:57:00.783637 [6]: subch:0 cam flags:True
2009-08-06 02:57:00.785637 [6]: subch:0 SetMpegPidMapping
2009-08-06 02:57:00.787637 [6]: subch:0 pid:36 pcr
2009-08-06 02:57:00.789637 [6]: subch:0 pid:35 pmt
2009-08-06 02:57:00.791637 [6]: subch:0 pid:34 audio lang:eng type:AC3
2009-08-06 02:57:00.793637 [6]: subch:0 map pid:34 audio lang:eng type:AC3
2009-08-06 02:57:00.797637 [6]: subch:0 pid:36 type:80

 

[jonesdb]

I'm actually on cable as well. The video stream is actually MPEG2, but the video stream descriptor shows 0x80 (DC-II). These program streams play fine in when selected from TsReaderLite. (See the thread that I started here which contains a fairly good description of the issue.
I believe that it can be solved easily by treating the 0x80 (DC-II) stream exactly as 0x02 (MPEG2) in TvServer3. (I think this only changes TSReader, but need to check that again)

I think that several cable providers are starting to use this stream descriptor on their systems, though the stream is actually MPEG2.

If you need any other info let me know.

 

[tourettes]

At least TsWriter and TsReader would need to be patched / hacked to use that as MPEG2 video stream. I wonder why the broadcasters arent playing with specs. If they are sending MPEG2 then they should flag the stream as MPEG2.

Not sure if we want to make such hack, as it will cause LPCM audio (not supported by TsReader currently) to fail to work as it is exactly the same stream type 0x80.

 

[jonesdb]

I understand the desire not to break something else. I don't think we can say the broadcasters aren't using the specs as ISO 13818-1 simply defines stream types 0x80 to 0xFF as "user private". A quick search on the net shows me that 0x80 it is being used as both MPEG2 and PMC audio. I guess the correct question to ask is "are there other attritubtes in the transport stream which would help indicate how the particular pid is being used?"

As an aside, do you know where is 0x80 being used as LCPM (from a MP standpoint)? If 0x80 LCPM is not supported in TSReader then it sounds like it is only being supported in the TSWriter side. Is that correct?

 

[mizzourob]

jonesdb... is my problem (and log file) the same as yours? I want to make sure we're not talking about two different things in the same thread

 

[jonesdb]

I'm fairly sure it is same problem. My logs are essentially the same as yours. (Identical in the areas that count)

 

[mizzourob]

it seems like a simple fix would be to have a manual override options that re-assigns the range from 0x80 to 0xFF to be 0x02 (mpeg2). This would be disabled by default, and the option to enable it would be buried in the scan options and only be visible in the advanced TV-Server config mode