Channel change fails ~50% of the time, first digit doesn't work

[compunerd632]

I use SageTV on my computer at school so that I can record shows and watch them when I'm not busy. It worked great pretty much all of last year, just the occasional missed channel change (I have a PVR 150 and use the IR blaster on the cable box). I didn't use the computer all summer because I lived at home and we have a cable company DVR.

My current issue is that the channel changes seem to fail almost 50% of the time. The vast majority of the time the cable box misses the first digit of the channel number. I know my blaster is positioned directly over the IR sensor on the cable box, so that's not the problem. In the Hauppauge IR Blaster config I've increased the delay between digits to 800ms to avoid any problem of typing the digits too fast. The channel changes work perfectly when I use the IR blaster configuration utility to test channel numbers. I've tried everything I can think of: I downgraded Java to 1.4.2_12, downgraded sage to 5.0.1 (which is what I had at the end of last school year and worked fine). I haven't touched the Hauppauge drivers since I installed them. My recording hard drive has 64k blocks and is running in DMA mode.

The only reason I can come up with is that the Hauppauge program that does the channel changing is not getting enough cpu time. I noticed that whenever Sage changes channels, the cpu pegs for about 5 seconds. It's at 100 percent for a short time and then 80 percent whenever the show info box and time bar are overlayed on top of the video. I was thinking that maybe when the channel changes and the cpu pegs, the IR blaster doesn't enough cpu time and srews up the first digit.

My system is an AthlonXP 2500+, 512mb ram, and Radeon 8500 64mb video card. As I previously mentioned, I'm using a Hauppauge PVR 150 capture card. In Sage I'm using overlay mode, no overlay keying, and no 3d acceleration. It seems like I'm not using any "eye-candy" and my system should be plenty fast enough, why does Sage hit the cpu so hard whenever it changes channels or overlays something on top of the video?

Anyway, hopefully something in there will give someone a clue on what's going on. Thanks for your help.

[ToxMox]

In my experience the first digit being missed is when the remote itself is interfering with the IR blaster. Basically when you are pressing a button on the remote the IR that comes out of it is locking out the first code sent by the blaster. Try changing the channel via mouse and see if the problem still happens. Of course I could be wrong but it is worth a try

[perfessor101]

Everytime I reinstall or upgrade SageTV I have to change the transmit and delay times on my USB-UIRT in the SageTV\Common\RemoteCodes\USB-UIRT Transceiver folder as my CPU pegs also.

I usually set it to send 3 digits with a 250 ms transmit time with 150 ms delay and the 'OK' button after.

When I would watch the video I found it was sending the first digit then the cable box would timeout before the IR helper app sent the second and third digits which the cable box would ignore.

Bobby

[jbarr]

compunerd632, what kind of cable box are you using?

[compunerd632]

Thanks for the tips guys, unfortunately none of them have worked reliably so far. I know it's not interference from the Hauppauge remote because it fails to change the channel on scheduled recordings as well, when no one is even in the room. I haven't tried the electrical tape idea yet, but I don't think that's going to help very much, this really seems like a software issue. The cable box we have is a General Instruments DCT1124/1151/ABCDGI/R2.

I was wondering, is there any way to tell Sage to delay when it sends the command to change the channel on the cable box? If the cpu usage is the problem, then delaying the channel change would help I think.

I'm looking forward to jds23's experiments because it really seems like the cpu should not be pegging when it changes the channel. And it's definitely Sage causing the cpu usage because the cpu is hardly used when I operate the blaster outside of Sage. Also, the Sage support for the Hauppauge blaster is built-in, I just tell it to use the Hauppauge blaster in the source setup. The Hauppauge tool is used to set the remote code set, but everything works when testing from that application.

Again, thanks for the suggestions guys.

[ke6guj]

My guess about that cpu pegging issue isn't a IRblaster issue, but actually a Sage issue updating the wiz.bin.

On my system, whenever there is something happening to update the wiz.bin, such as when a recording starts or finishes, The CPU will use all available cycles for ~5 seconds, but the system is still usable. So, at the top of the hour, when Sage is starting a new recording, it enters that info into wiz.bin at the same time it is trying to IRblast the channel change. I had an IRblaster hooked up for about a week until I got an HD box with firewire, and had a couple missed channel changes. Could it have been a CPU issue, I dunno, I didn't mess with with very much and just ugraded to a firewire-equipped cable box.

I upgraded to the firewire-equiped box for the channel changes, and hoped I could do some firewire recording possilby. Luckily, on my cable system there is no 5C at all right now, so I can record everything I subscribe to. And no missed channel changes or STB UI info recorded in my shows as well.

[AngelofDeth]

I had similar issues when using the beta blaster, but I never figured it out.. just switched to serial tuning. But, the CPU pegging is normal. I fugured maybe was due to closing/opening a new file, and probably also it is writing to wiz.bin...

[compunerd632]

I just wanted to report back that I've found a solution (I think). Only time will tell how effective it is.

I did some searching and found that General Instruments cable boxes have a tendency to miss the first digit - this even happens to Tivo users. From what I've read, as long as you send it something and then wait a few seconds, it will receive the channel just fine. It's like the box needs to be awoken before it will properly read the channel.

So my solution was to use the EXETuner plugin and write a script that will change the channel once, wait 3 seconds, and then change the channel again. The first channel change, successful or not, will wake the box up so that the second one will work just fine. If anyone else might need to try this solution, here's the script I wrote:

Dim shell, args
set shell = CreateObject("WScript.Shell")
set args = WScript.Arguments

shell.Run """C:\Program Files\Frey Technologies\Tuner\IRBControl.exe"" " & args(0), 1,True
WScript.sleep(3000)
shell.Run """C:\Program Files\Frey Technologies\Tuner\IRBControl.exe"" " & args(0), 1

This script is written in VBScript (because windows sucks and there's no way to hide the command window if you just write a batch file). To run it you use the command:

wscript scriptname.vbs channelnumber

The other thing you need to use this script is the IRBControl program, which sends a channel change through the Hauppauge IR Blaster. This can be downloaded at http://www.disco-nt.co.uk/download/.

Again, thanks for all the help guys.