Perplexing (but serious) problems with MCE remote

[jaysoma]

I am trying to get my MCE remote to work, but have come across several problems. I have a Hauppauge 350 card, and am using a digital converter box as an external tuner.

The first and most annoying problem I have is, GBPVR is not sending anything to the IR blaster that came with my MCE remote. I have the Channel Changer set to MCE Blaster. I know the blaster is working because I can send signals to it using HIP. Why would GBPVR not be able to use the IR Blaster, even after I specify the channel changer to use it?

I have my Source set as "Fixed-channel, External-tuner". And the fixed channel is set at 3. Now the strange thing is, I get a signal only when I set the GBPVR channel to 3. When I push channel up or down, I get no video/audio. It's almost as though GBPVR is using the Internal Tuner to change its internal channel when I push the channel up or down on my MCE remote.

Please help!!!

[sub]

The first and most annoying problem I have is, GBPVR is not sending anything to the IR blaster that came with my MCE remote. I have the Channel Changer set to MCE Blaster. I know the blaster is working because I can send signals to it using HIP. Why would GBPVR not be able to use the IR Blaster, even after I specify the channel changer to use it?

Just use HIP. The MCE Blaster plugin is in use by a few people, but I generally point people towards HIP instead. HIP appeared a few days after the release which included MCE Blaster support, and does a much better job at it, so I havnt bothered spending any time improving or testing the built in plugin since then. It's author has got much more time they can focus on this one aspect than I have.

I have my Source set as "Fixed-channel, External-tuner". And the fixed channel is set at 3. Now the strange thing is, I get a signal only when I set the GBPVR channel to 3. When I push channel up or down, I get no video/audio. It's almost as though GBPVR is using the Internal Tuner to change its internal channel when I push the channel up or down on my MCE remote.

Can you reproduce this problem, then zip and attach the logs?

[pBS]

have you tried MceIrPlay.exe and MceIrRec.exe? supposedly you can record and playback learned remote codes from command-line with these,so just call a batch file as an .exe changer program and 'learn' digits for your box,saving each digit to a file...[preferrably the digit# as name] then call MceIrPlay.exe with each digit with a for loop....eg. MceIrPlay.exe 1 MceIrPlay.exe 4 MceIrPlay.exe 5 for changing to channel 145...
just got my MCE remote so still playing with things and don't have it on my regular gbpvr box yet..[still using pvr150 ir] but will have to when i get a new dish box..just seemed like a simple option if others fail...
the files come with the 'alternate driver' but work with either driver..
[also needs to have the MCEir.dll from that driver kit]

- MceIrRec.exe : allows you to record IR into a file
syntax: MCEIRREC -o C:\TEST.IRK
- MceIrPlay : to send a previously recorded file through IR blaster #1
syntax: MCEIRPLAY -i C:\TEST.IRK -b 1

abiity to send to either ir blaster!

even has api details in readme..

[pBS]

i just made a nice little parser so i could split the numbers into sigle digits and it works great
uploading zip that works with MCE blasters that lets you learn ANY remotes commands and blast them thru either or both blasters..
and sample learn.batch file that will help you learn the commands [only 10 digits]
copy everything into a dir,
in GBPVR config, select mceblast.exe as .exe blaster, as parameters type
{channel}
run the learn-digits.bat batch file,
Enjoy!

[contains all needed files ]

UPDATE: [after only 10 mins..lol]
modified to wait for previous digit to finish so no delay needed
[as fast as it can..]
it's all you need to blast with the MCE blaster

[jaysoma]

Sub, I will recreate the problem and send you the logs. Tell me, is there a way to reset the logs? I will set the logging level to DEBUG to get as much info as possible. So if I use HIP to change the channel on my STB, how would I navigate to a channel from the Guide? How would GBPVR communicate to HIP that the channel needs to be changed on the STB?

Thank you for your reply PBS. Sounds like what you're doing is exactly what HIP does. Is there any difference?

[sub]

So if I use HIP to change the channel on my STB, how would I navigate to a channel from the Guide? How would GBPVR communicate to HIP that the channel needs to be changed on the STB?

I dont use HIP, so I'm not that familiar with it, but there is a write up on the wiki (http://www.gbpvr.com/pmwiki). From the GB-PVR side of things, you configure you capture source to use the ".exe channel changer" and point it at HipSend.exe. When GB-PVR needs to channel channels, it'll run HipSend.exe passing the appropriate channel number.

[jaysoma]

Sub, I recreated the problem. Turned log level to INFO. Started GBPVR in channel 3, then when I changed the channel to 4 and 5, it seems to be changing it internally, even if it is set to use external tuner, so I end up losing picture and sound when I change the channel. Please see attached logs and advise. Thank you.

[sub]

This was a known bug in the version you're using. Upgrade to the current v0.97.9 release.

6/18/2006 11:26:42 PM.398 VERBOSE [2] getValue: /settings/Version : GB-PVR v0.96.12

[jaysoma]

Thank you Sub. Downloading the new version fixed the problem.

[pwborders]

Just wanted to add my $0.02 worth. Once I finally got a good set of recorded ir codes from my remote the internal MCE IR Blaster support in 0.97.07 is working great for me. The biggest problem was getting reliable recordings of all the buttons needed. Using the MCEIRPlay.exe and MCEIRRec.exe I was able to get good recordings after a few dozen tries. Then I copied them to the directory under bgpvr and set it to use them and everything works great.

I think the main issue people are having with the internal MCE IR Blaster support is bad recording, not the actual sending part. I know how it is not to want to spend alot of time on a part that is not that important but I think if the initial recording part could be made a little more bullet proof things would work great for everyone.

The problem is that the recording function will exit with a good recording status for anything, even when it makes a 0 byte file for output. That means people think the recordings are good and the playback is bad but it is exactly the opposite. This same thing happens with the MCRIRRec.exe program, it says good recording (or whatever positive) even when it didn't get anything useful.

If I was going to change the internal recording procedure I think I would make it ask the user to press the key and say it was recorded as it does now but stop after one key to test it. Next I would do the simplest test to see if the data captured was at least 20+ bytes or so, I don't think any modern STB is going to get away with much less than that and all the bad codes I generated were less than that. Then tell the user that I am going to send to key to the STB. I would then send the key once, using both blasters for now during testing, and ask if the user saw the red leds on the blasters flash and if the STB displayed the channel. That way maybe a good recording could be assured as well as placement of the ir blaster. Say if the red led flashed but no change occured you could prompt to retry after the user repositions the ir blaster itself. If the blaster red led didn't flash at all the user would be prompted to rerecord the signal and the test process would restart. Upon thinking more this could even be an external program that is called during config to help the user record the codes.

I don't have anything against HIP or other such programs but I find that with windows OS machines the more you add the less stable they get. Also I beleive that HIP is currently having issues with suspend. Rickulous (?) who developed the HIP guid in the WIKI recently posted that he is only half using HIP because of some issues with it. Since the output part of the internal blaster support seems to work great I think if the input part could be brushed up things would be perfect.