Comparing LEARNt codes to RECEIVEd codes

[rhubarb2]

I'm trying to improve USBUIRT support in MediaPortal.

It learns in two ways (which seems correct):

1) it uses UUIRTLearnIR to learn new codes to be transmitted to an STB later, and

2) it uses the normal UUIRTSetReceiveCallback with a receive call back to learn codes that are mapped to internal commands (never to be transmitted).

This is all well and good, but here's what I'm trying to do:

When Windows Media Center learns a code, the UI interaction is like this:

1. "Press button '0' and hold it"

<waits till you press and hold it>

2. "Keep holding button '0'"

<learns button '0' while you're holding it - seems to take ~ 2 secs>

3. "Release button '0'"

<ACTUALLY WAITS UNTIL YOU RELEASE IT>

4. goto 1. with next button.

I'm trying to do the same.

Now so far I have 1 and 2 working okay. I even have a progress callback that updates message 2 with ". . . " where each dot indicates 10% progress.

But I'm stuck on 3. I'm sending the user this "release" message after learning is finished, but now I want to actually wait until they really release the button.

To do this I am trying to use UUIRTSetReceiveCallback with a little callback that resets a little 200ms timer every time it gets called with the SAME code as the Learn routine returned.

This way, I just loop while testing if the timer timed out - when it does I know that that button wasn't held in the last 200ms.

Question 1: How do I compare the receive callback's string with the string learnt from the learn process, so I know its the same button just learnt that's being held?
I know from your documentation that they are not the same, that the learn code contains more info needed for transmitting, and the receive code is just long enough to be unique - but are they comparable at all?


Question 2: Even if I can do this, does my routine make sense?
I'm assuming the callback will be called more often that once every 200ms with the button code as long as the user continues to hold the button. Good assumption?

Question 3: Is there a better way to detect when the button actually gets released some time after the learn method has returned.

[jrhees]

These are good questions.

First of all, it would be a difficult task to map the learned code to the 6-byte callback code. Secondly, you may not want to do this anyway, because if the user, say, is learning a 56KHz IR stream on a standard USB-UIRT, the learn will work, but the receiver callback will never get called (because the receive callback is based on the normal long-range sensor).

I need to think about this a bit, because it really makes sense and we ought to provide a way to make this possible.

-Jon

[Guest]

Thanks for the reply.
Perhaps I can check the frequency in the progress callback, and skip the "release" wait cycle (or replace it with a timed one).

In any case I've changed my routine so that it registeres the "received" code immediately after finishing learning, and continues to wait for that one to be released.
In other words, it assumes that between the exit from the learn routine and the first call to receive, the user hasn't had time to release the button.

Another thing I'm struggling with is way to time out or cancel the learn routine.
I tried adding a time check to the learn routine so that if no progress was being made, it would set the abort flag after a certain time.
The problem is, if no progress is being made, the progress callback isnt called at all. So if the user doesnt actually send an IR signal (perhaps their remote is broken or of a strange frequency or IRDA or something) then the whole thread hangs.
Perhaps it should be called periodically irrespective of progress?

In any case, is there another way to specify a timeout for learning?

I was thinking of creating a different thread to either wait for timeout or even to listen for events on a cancel button.

thanks again for the timely reply,
rhubarb.

PS let me know how you go with a solution for the "release button" issue

PPS please, PLEASE, save me from all of this by finishing your plugin for blasting from within MCE. (If you're not working on that could you open the code for some desparate users to help out?)

[jrhees]

rhubarb2,

As far as aborting the Learn procedure -- you do not have to rely on the callback being called to set the 'Abort' flag. Remember that you have a pointer to the Abort (pbAbort) so you can set it any time from within your app.

The MCE plugin is slowly moving along. I have run into a major snag, though, in trying to get MCE to ignore the fact that it cannot find the standard MCE IR hardware.

-Jon

[rhubarb]

Sorry about all the user names- I didnt have autologin set. Rest assured I'm the same person (Good on you, btw, for making a forum that doesnt force people to register if they dont' want to)

Regarding the abort flag. This is indeed the mechanism I'm using. (In C# I pass in a "ref" to an "int")
The trick is working out WHEN to set it. As you mention in your docs, since the Learn routine blocks the thread, the abort flag needs to be set in the progress callback or in another thread. I was trying to do it in the progress callback when zero progress had been made after a certain period of time.

In other words, every time the progress callbac was entered I would compare the progress with the previously stored progress (from the last call) and if it hadn't, well, you know, progressed and a certain amount of time had passed since the last real progress, THEN I would set the abort vlaue to true.
The problem is, when I don't point my remote at the receiver and hold the button (ie no progress) then the progress callback is never called. So I can't check my timeout and set the abort flag.
Looks like the only way to add a timeout or a user-driven cancel is to use a different thread.
Given that the Learn routine simply waits for ever if it turns out that the user doesn't have a remote control pointed at the receiver, it would be nice if we could pass in a timeout value to the learn routine itself - it could then return some error flag.

[rhubarb]

re: MCE blaster support

I know what you mean about the MCE TV support needing the receiver. Even before I got my MCE or USBUIRT receivers I wanted to use MCE for timeshifting on the current channel and it simply wouldn't install that far.
I know a lot of people are frustrated by this.

I also know that for your plugin to be generally useful you need to overcome this, so that people can use USBUIRT without having to buy the MCE thing.

HOWEVER, I DO have the MCE remote in addition to USBUIRT, both plugged in, and I just can't use MCE because of the lack of support for my STB.

So if you have it working such that I need my MCE receiver there for the setup to work, but you change the channels through USBUIRT, then just that would be FANTASTICALLY USEFUL for me. It would mean I could use MCE. Yay.

I also know from the MCE and girder forums that there are others in this situation. And that there are still others that, for now (like me), wouldnt mind buying the MCE receiver in addition to USBUIRT if thats what it took to get their expensive setups to work. After all the MCE receiver is only ~$35 and it comes with a very nice remote for controlling MCE.

So please, please release whatever you have.

thanks again,
rhubarb

[jrhees]

rhubarb,

I'll see what I can do.

I'm curious what MS support says about MCE's blaster not being able to control your STB. Are they planning another release of codes or something?

-Jon

[rhubarb]

My STB is from the cable company in Portugal (TVCabo) and since there is no Portuguese MCE version (nor is there an EPG feed), I guess supporting it is a low priority.

The MCE wizard says it recognizes it when I beam 0 and channel up during the setup (If ONLY it had a real learning circuit like USBUIRT) but then fails to control it.

Surprisingly MCE DOES list the brand (OctalTV) in their list of 700+ STBs to select from, but this doesnt work either.

It could be that there is some brand choice that would work in this list of 700+, but with an average of 3 codes each, this would mean trying out over 2000 combinations.

Looking forward to whatever you can give me.
In the mean time I'm trying to do something with girder.

thanks,
rhubarb

[rhubarb]

I'd also be interested in knowing how you are discovering and using the right API in MCE to actually get the channel-change signals.

[rhubarb]

Okay, I found an open source DirectTV plugin by one Dan Glass and adapted it.
Now I have MCE changing channels through girder and USBUIRT.

My adapted plugin simply runs any executable whenever MCE issues a channel-change, with the channel number being one of the configurable command line arguments.

So I use it to send an eventstring to girder where I have a set of actions for changing channels on my STB through the USBUIRT plug in.

Works well. Finally!
Wouldn't be hard (just time consuming) to develop this into a proper plugin and cut out the girder middle man. But I don't see any way to over come the demand for the mce receiver either.