Weird Tuning issue

[hdtvtodvd]

I have an odd tuning issue with my Ceton Infinitv 4 tuner USB device. I can tune any channel say 1717. When I use the guide to change the channel to say 1602 it will end up saying subscription required. If I press stop and no video is playing I can go to 1602 with no problem. Also if the channels are close together it will tune fine while playing video. Very strange and I have a ticket with Ceton, but haven't heard back in a few days...

Here is a link to a video that shows the issue.

https://www.dropbox.com/s/5pzyp9sbeo9dc ... 3%20AM.mov

Any ideas would be welcomed.

[foxwood]

Are you using a Tuning Adapter? It sounds like a delay between your Tuning Adapter requesting an SDV channel from the head end, and then getting a response and telling WMC where to find the channel.

[crawfish]

I have an odd tuning issue with my Ceton Infinitv 4 tuner USB device. I can tune any channel say 1717. When I use the guide to change the channel to say 1602 it will end up saying subscription required. If I press stop and no video is playing I can go to 1602 with no problem. Also if the channels are close together it will tune fine while playing video. Very strange and I have a ticket with Ceton, but haven't heard back in a few days...

Here is a link to a video that shows the issue.

https://www.dropbox.com/s/5pzyp9sbeo9dc ... 3%20AM.mov

Any ideas would be welcomed.

Your video is very much like the H264 bug I first encountered a couple of years ago when I got my HD Homerun Prime, but you are first Ceton user I've found to describe it. Please do the following:

1. While tuned to one of the problem-causing channels, press 411-Info on your remote to get the Media Center debug screen. Then right-arrow to the last page and see what the Video Codec is listed as.
2. Tune to one of the black screen channels. Repeat the 411-info procedure and note the codec.
3. Get Media Center back into working condition and repeat (2).

I observe the following:

1. H264
2. H264 plus stupid values like 47 Hz for Frame Rate and 86x1080 for Display Size along with the black screen.
3. MPEG2 and normal values for Frame Rate and Display Size.

For me, this only happens with H264 channels, and it's been like this a couple of years now.

Back when I was running dual monitors off a GT430, I could clear the bad state in Media Center by tuning certain MPEG2 channels like my locals, restarting ehrecvr, or rebooting. I'm now using Intel 4600 graphics for my monitor and the GT430 for my TV, and the behavior has changed. Tuning my locals no longer clears the bad state, but restarting Media Center does, and that used to not work. I had a support ticket with SiliconDust about this in the pure GT430 days, and after several back and forths and experimenting with two Media Center PCs, I finally convinced myself it was not the Prime that was at fault. (I could get WMC into the bad state on either PC but use the same tuner in the other one without problem.) They chalked it up to something non-standard about the Cox signal and Media Center reacting badly to it, sort of like another 29/59 type bug.

As for the SDV theory, according to SiliconDust, WMC has no knowledge which channels are SDV, and there is no notification from the tuner. Their position is there is nothing they can do to influence how WMC changes channels, nothing they can do to prevent it from entering the bad state or help it recover from it.

[foxwood]

As for the SDV theory, according to SiliconDust, WMC has no knowledge which channels are SDV, and there is no notification from the tuner. Their position is there is nothing they can do to influence how WMC changes channels, nothing they can do to prevent it from entering the bad state or help it recover from it.

He doesn't have an SD tuner, where the TA is plugged into the tuner, and Windows doesn't know anything about it. He has a USB connected tuner, with the TA plugged into the Windows box, and a service running on the Windows machine responsible for communicating with the TA when a new channel is required, and then communicating the response to the tuner when the TA tells the service what frequency the requested channel can be found on.

[hdtvtodvd]

I checked the codec and both channels are mpeg2 so I don't think it is an h264 issue. It does seem like a TA issue, but I can't figure out why I can tune anything perfectly if I press stop and then tune. It should work regardless of if video is playing or not...

[crawfish]

I checked the codec and both channels are mpeg2 so I don't think it is an h264 issue.

Oh well, I guess not! I've had one other solid confirmation of the H264 bug, and that was also an HD HomeRun Prime user. If any Ceton users have the problem with H264 channels, I'd be interested in hearing about it.

It does seem like a TA issue, but I can't figure out why I can tune anything perfectly if I press stop and then tune. It should work regardless of if video is playing or not...

If it is excessive TA latency as previously suggested, how does one go about testing this?

[JohnW248]

If it is excessive TA latency as previously suggested, how does one go about testing this?

This depends on the type of headend you're on. If its a Cisco headend with Cisco CableCARDs and the 1520 TA, then you can go to the diagnostic map and open the RF Statistics and go to page two to look at the RDC:

This is off a SD Prime that has only tuned twice today
CURRENT RDC
Freq: 15.000 MHz
Power: 38 dBmV
Delay: 638 uSec
Retrans: 0

And this is a PCIe Tuner same feed from same splitter
CURRENT RDC
Freq: 15.000 MHz
Power: 33 dBmV
Delay: 641 uSec
Retrans: 19
This was rebooted after Windows Update and obviously had some communication issues upstream, it's last channel table was downloaded after the update at
09/10@12:51:02 Rsp v032 Blks=07

I haven't see retrains this high before here and there must have been some node issue going on during a tuning request. I'll probably power cycle the TA tomorrow to clear the registers and see what happens after that. But to answer your question, a high number of Retrans with the node can result in a late return or a bad update of the mini-carousel which is the status of the local node with what's running in the neighbor hood for immediate tuning can cause a late return which will result in a subscription required. With live tv you'll see the sub req or SDV1 error, with a recording you'll normally see an error "no video" from MC and it'll roll after two tries to another tuner and usually by that time there is a response and the program records.

[crawfish]

Motorola here. I'm not seeing anything obvious like "Delay" or "Retrans" in the TA or CableCard pages served by the Prime. Fortunately I've had no problems I can attribute to SDV. Just to be clear, if the OP's problem is with SDV, it can affect any system including things like TiVo, right? And Media Center is just responding kind of poorly to a transient issue?

[darekd]

Oh well, I guess not! I've had one other solid confirmation of the H264 bug, and that was also an HD HomeRun Prime user. If any Ceton users have the problem with H264 channels, I'd be interested in hearing about it.

[/quote]

I have Ceton card with COX and I also have h264 channels problem. Several months ago cox added h264 channels. I can tune to H264 but I cannot tune back to mpeg channels. I get wired artifacts (grey screen). To fix this state, I have to go to ESPN (maybe other 720p channels work too). I use intel 4000 but I also tried G430. Both with the same results. Also tried win8 - same results. Likely H264 channels are not the one I watch.

[crawfish]

I have Ceton card with COX and I also have h264 channels problem. Several months ago cox added h264 channels. I can tune to H264 but I cannot tune back to mpeg channels. I get wired artifacts (grey screen). To fix this state, I have to go to ESPN (maybe other 720p channels work too). I use intel 4000 but I also tried G430. Both with the same results. Also tried win8 - same results. Likely H264 channels are not the one I watch.

Thanks for confirming.

[qbanb8582]

Is this something only with Cox. Has anyone been able to confirm if this happens with any other provider? I have cox and have the same issue with two HDHomerun Primes.

[crawfish]

All three confirmations of the H264 issue I've gotten have been from Cox users.

[qbanb8582]

After some messing around it appears to me the issue maybe windows media center. If I just set the channels that are MPEG4 to record it records just fine. If I watch it from recorded TV even while its recording I can tune to a channel thats MPEG2 with no issues.

Seems it maybe a bug with Media Center with live TV. But makes no sense why tuning to a non switched channel makes a difference.

[crawfish]

After some messing around it appears to me the issue maybe windows media center. If I just set the channels that are MPEG4 to record it records just fine. If I watch it from recorded TV even while its recording I can tune to a channel thats MPEG2 with no issues.

Seems it maybe a bug with Media Center with live TV. But makes no sense why tuning to a non switched channel makes a difference.

Well, yes. From my earlier post in this thread:

I had a support ticket with SiliconDust about this in the pure GT430 days, and after several back and forths and experimenting with two Media Center PCs, I finally convinced myself it was not the Prime that was at fault. (I could get WMC into the bad state on either PC but use the same tuner in the other one without problem.) They chalked it up to something non-standard about the Cox signal and Media Center reacting badly to it, sort of like another 29/59 type bug.

As for the SDV theory, according to SiliconDust, WMC has no knowledge which channels are SDV, and there is no notification from the tuner. Their position is there is nothing they can do to influence how WMC changes channels, nothing they can do to prevent it from entering the bad state or help it recover from it.

[richard1980]

They chalked it up to something non-standard about the Cox signal and Media Center reacting badly to it, sort of like another 29/59 type bug.

To clarify something, there is nothing "non-standard" about 29/59 content, nor does WMC "react badly" to 29/59 content. It has been standard practice for many years (since before WMC even existed) to mix interlaced frames and progressive frames in the same MPEG sequence, and WMC reacts exactly as it should when it encounters mixed-frame content. Whatever problems result from WMC encountering mixed frames are due to either mis-encoded frames, a poor GPU, poor GPU drivers, or poor GPU settings.

So by saying the issue discussed here is "sort of like another 29/59 type bug", you are saying the issue is not actually with WMC, but with something other than WMC. So is that the case, or do you think there is truly a problem with WMC?

[erkotz]

They chalked it up to something non-standard about the Cox signal and Media Center reacting badly to it, sort of like another 29/59 type bug.

To clarify something, there is nothing "non-standard" about 29/59 content, nor does WMC "react badly" to 29/59 content. It has been standard practice for many years (since before WMC even existed) to mix interlaced frames and progressive frames in the same MPEG sequence, and WMC reacts exactly as it should when it encounters mixed-frame content. Whatever problems result from WMC encountering mixed frames are due to either mis-encoded frames, a poor GPU, poor GPU drivers, or poor GPU settings.

So by saying the issue discussed here is "sort of like another 29/59 type bug", you are saying the issue is not actually with WMC, but with something other than WMC. So is that the case, or do you think there is truly a problem with WMC?

The root cause of this issue is that WMC resets the video pipeline every time the frame rate changes. It is perfectly legal for the rate to change continuously within MPEG, which is where this problem happens.

[crawfish]

The root cause of this issue is that WMC resets the video pipeline every time the frame rate changes. It is perfectly legal for the rate to change continuously within MPEG, which is where this problem happens.

Yep.

http://support.microsoft.com/kb/2658140
"This occurs due to Windows Media Center resetting the video pipeline when a frame rate change occurs."

[richard1980]

The root cause of this issue is that WMC resets the video pipeline every time the frame rate changes.

"This occurs due to Windows Media Center resetting the video pipeline when a frame rate change occurs."

The wording in that KB is not consistent with the original Microsoft statements posted on the old TGB (by the people that knew actually knew the answer). Specifically:

...this causes a hiccup as the underlying Windows video processing pipeline has to respond. Specifically the GPU deinterlace implementation needs to reset/recover and that can take a few frames.

Note that it's not the video pipeline that gets reset, but the GPU deinterlace implementation, which is exactly what WMC should do when it encounters a change in the progressive_frame flag (otherwise, WMC would always process all frames the same way, even though they can (and do) legitimately change). Ergo, WMC isn't doing anything wrong.

But that still doesn't answer my question. With the 29/59 issue, WMC is doing things correctly, and the stuttering, flickering, and blanking symptoms are attributed to the GPU, not WMC. Is the issue discussed in this thread similar? In other words, is this another case of a hardware/signal problem being attributed to WMC? Or is it truly a WMC issue?

[erkotz]

The root cause of this issue is that WMC resets the video pipeline every time the frame rate changes.

"This occurs due to Windows Media Center resetting the video pipeline when a frame rate change occurs."

The wording in that KB is not consistent with the original Microsoft statements posted on the old TGB (by the people that knew actually knew the answer). Specifically:

...this causes a hiccup as the underlying Windows video processing pipeline has to respond. Specifically the GPU deinterlace implementation needs to reset/recover and that can take a few frames.

Note that it's not the video pipeline that gets reset, but the GPU deinterlace implementation, which is exactly what WMC should do when it encounters a change in the progressive_frame flag (otherwise, WMC would always process all frames the same way, even though they can (and do) legitimately change). Ergo, WMC isn't doing anything wrong.

But that still doesn't answer my question. With the 29/59 issue, WMC is doing things correctly, and the stuttering, flickering, and blanking symptoms are attributed to the GPU, not WMC. Is the issue discussed in this thread similar? In other words, is this another case of a hardware/signal problem being attributed to WMC? Or is it truly a WMC issue?

I'm going from 4-ish year old memories, but I believe both statements are correct. The problem is WMC resetting the pipeline takes a decently long amount of time, hence the stuttering.

[richard1980]

You can see for yourself that the pipeline is not being reset by using MFTrace to create a trace log for ehShell.exe while playing 29/59 content. When you examine the log, you'll see that the only thing that happens during a change in the progressive_frame flag is the input and output parameters are changed, but the pipeline isn't reset. If you want to see what a pipeline reset looks like, perform another trace, but this time play live TV and switch channels a few times. When you examine the log, you'll clearly see the pipeline being reset each time the channel is changed.