Sluggish Channel Change

[smajor]

I'm from the HD-PVR crowd, and that thing with me is fickle about decoders. I can make that device crash at will with the wrong codecs. I finally went back to the ArcSoft ones that came with the device and it's been quite stable.

With that said, what codecs are you using with your setup? Have you tried those that came with your device? What about the software that came with it or Media Portal? Same issues there? I'm not familiar with Media Portal, can you select decoders like NPVR? If so, is there a way you can determine it it is using (hopefully successfully) and use the exact same ones with NPVR?

I average about 12-20 seconds to start LiveTV and 3-4 seconds for a channel change once the HD-PVR is "spun-up" and running.

[Jaggy]

The Hauppauge remote slow thread was a totally different thing & I don't think it is in any way related. I just did a search & found the tread I was thinking of but apart from the times sub & a couple of others are getting to change channels it doesn't seem to have much else in it to help either. I think the next step is as smajor suggested followed by posting the logs after trying channel changes with NextPVR.

[LitlJay]

I'm from the HD-PVR crowd, and that thing with me is fickle about decoders. I can make that device crash at will with the wrong codecs. I finally went back to the ArcSoft ones that came with the device and it's been quite stable.

With that said, what codecs are you using with your setup? Have you tried those that came with your device? What about the software that came with it or Media Portal? Same issues there? I'm not familiar with Media Portal, can you select decoders like NPVR? If so, is there a way you can determine it it is using (hopefully successfully) and use the exact same ones with NPVR?

I average about 12-20 seconds to start LiveTV and 3-4 seconds for a channel change once the HD-PVR is "spun-up" and running.

I always used the K-Lite package with MediaPortal, and configured it to use ffdshow for nearly everything. The same seems to have worked perfectly so far with NPVR.

The reason I made the change is because I moved from analog cable to clear QAM, and Media Portal wasn't playing nice with my tuner card any more, even though it was supposed to support clear QAM and the HVR-1600 just fine.

AFAIK the codec package I am using has always worked. If anyone has used something else with an HVR-1600 and gotten good results I'll be happy to try it out.

J

[smajor]

This is only my personal experience, but I had problems with the K-Lite packages. I switched to using CCCP (Combined Community Codec Pack) and had better results. I only need the ArcSoft codecs for my HD-PVR and CCCP and I'm good to go with the default install.

[sub]

Reproduce the problem, then zip and attach the npvr.log and npvr.log and we'll see if anything stands out.

If anyone has used something else with an HVR-1600 and gotten good results I'll be happy to try it out.

It's worth pointing out that only some HVR-1600's support QAM correctly. Some of the earlier ones used slightly different hardware, and only advertised Analog/ATSC support - QAM kind of worked, but not very well. All the later devices, like HVR-1800 etc had good support for QAM.

[johnsonx42]

it really isn't relevant I'm sure to the problem, but I'm just curious: do you have an NForce3 chipset, or do you have an AthlonXP 3000+? The two don't go together. An AthlonXP 3000+ would work with an NForce or NForce2 chipset, while an NForce3 chipset would interface to an Athlon64 (which could also be a 3000+).

[LitlJay]

@Sub: I'm really glad so much muscle has showed up to my little party and is trying to help out, and especially happy that the big man has turned up. Logs to follow shortly. I am aware of certain HVR-1600 hardware versions not supporting clear QAM, as it was one of the first things I investigated when MediaPortal failed me after I converted from analog to QAM. I personally spoke with a Hauppauge rep about my problem and, while they wouldn't support MediaPortal, they did confirm that my specific hardware version does support clear QAM.

it really isn't relevant I'm sure to the problem, but I'm just curious: do you have an NForce3 chipset, or do you have an AthlonXP 3000+? The two don't go together. An AthlonXP 3000+ would work with an NForce or NForce2 chipset, while an NForce3 chipset would interface to an Athlon64 (which could also be a 3000+).

You are correct. It is an Athlon64 3000+, although I do have a dedicated torrent server that is an AthlonXP 3000+/nForce2 that I mixed it up with in my head...

[LitlJay]

OK, I dumped the logs directory so there would be less to parse through and started fresh.

You can probably see by the logs, but just to make it easy here is the sequence of events:

• Start NPVR GUI using GrnPWR on Hauppauge remote.
  
• Open the (unconfigured/unpopulated) Guide.
  
• Scroll down to a channel and start live TV from there.
  
• Live TV starts succesfully and pretty quickly.
  
• Open the Guide again on top of the live TV (get a few graphical artifacts, but nothing I am worried about because I know that this is demanding and my video card is puny)
  
• Scroll to another channel and select it to view.
  
• Get about a second of sound from the NEW channel and a frozen display of the OLD channel.
  
• A few minutes later, sound resumes as normal and video from the new channel begins to play very rapidly as if catching up from a buffer, then normal TV playback resumes once it catches up to the audio.
  
• A channel change from the Ch button on the Hauppauge remote nets a similar result as the previous channel change.
  

Oddly, both channel changes were eventually successful. The last few days I have sometimes let it sit for hours on a channel change before I gave up and killed the GUI via the right-click context menu and was able to pick up where I left off.

I have also been unable to restart live TV without a reboot after hitting the stop button on the remote during live TV playback a few times in the past. I tried to reproduce that for the logs in case it was related, but was unable to replicate that particular problem.

[ATTACHMENT NOT FOUND]

I then closed the GUI, stopped the recording service, and zipped up the entire Logs directory. It is attached above. There should be no digging required. Only what I describe is what will be logged.

Thanks!

J

[sub]

There is no obvious smoking gun in the logs, but I'm guessing its either related to the 'DScaler Mpeg2 Video Decoder' which you're using, or your audio renderer. The audio renderer should be set to 'default', is this what you have?

You could also try setting the audio decoders to disabled, except for the MPEG1 Layer II and AC3 decoders.

[LitlJay]

OK, we seem to be on to something. A few people had tossed this out in the thread already, so I'm digging into it more seriously than before.

Yes, the audio renderer is set to "default". FWIW the computer has no sound card (in the conventional sense) and the mobo's onboard sound is disabled in the BIOS. Sound is piped out digitally via the HDMI port and decoded in hardware externally. This frees up my CPU/RAM from having to do the audio decoding, unlike 99% of the computers in the world.

I tried disabling the suggested audio decoders and got no improvement.

With my current config, I have only 2 options for my MPEG2 Video decoder: the DScaler that I am currently using and ffdshow. Ffdshow nets a black screen with good sound during live tv playback, so I have been using DScaler. As an experiment I simply disabled the MPEG2 Video decoder and got the expected black screen with audio during live TV. I tried changing the channel a few times and I could hear perfect channel changes every time. To be complete, I decided to repeat the experiment using ffdshow and see how the channel changes go. Continued good channel changes in this environment are indicating to me that I need to find another codec (perhaps one in smajor's CCCP?).

Apparently my codec is too demanding for my hardware to handle. I think I'll try another, starting with the ones in CCCP.

I'm open for other suggestions, and will be reporting back with results.

Thanks so far!

J