Comcast switch to MPEG-4 - How to change config with least impact/hassle?

[HarryH3]

No problem. Here is a sample now that the file is view-able. https://dl.dropboxusercontent.com/u/2693....Rocket.ts

Interestingly, your reg change results in a file that VLC can now open also.

[HarryH3]

Hi Sub, just wondering if the clip I posted of the "after reg change" file showed anything useful.

[sub]

Sorry, I haven't looked at it yet.

[sub]

Are you running the current release? I'm fairly sure I found the source of this a couple months ago and fixed it.

[HarryH3]

I think it's the latest. It says 3.9.2 (161119). (The version in my sig is wrong because I can't find the link to edit it.)

[sub]

Ok, I'll take a look at the file when I find some time.

[HarryH3]

Thanks sub! I'm just curious to know what is going on and why Comcast can't figure out why they're sending a busted stream. I suppose that they just don't care that much since it doesn't affect their set top boxes.

[sub]

I don't think they busted the stream. I think they've just got a long PMT (which is more than a 188 byte transport stream), and NextPVR isn't doing a good job of rewriting this type of PMT. That registry setting was disabling the rewriting, giving you the original PMT from the stream.

[HarryH3]

Hmm, OK. I wonder why they only do that on a couple of channels? All of their other channels were working fine. Odd stuff! Thanks again for taking a look.

[sub]

Usually a PMT is pretty small on most channels, but very occassionally we see one that is large. It's usually because they've got more streams (like multiple languages). In this case, they've got a video stream, two audio streams (eng/spa), and three private data streams. In itself that's not a huge number of streams, but the number of descriptors for each of those streams (data that describe the contents of the stream) can quickly push it up over 188 bytes.