WiiLi.org

[CurriedLambda]

I keep getting IOExceptions inside of the WiiRemote.run() method once a controller has been disconnected.

I understand that we aren't supposed to read from a disconnected controller but it seems that a few pending events are being sent to the combinedInputReceived handler before the actual disconnected method is called.

I tried to solve the problem by checking isConnected inside the combinedInputReceived handler, but isConnected always returns true (since I guess the controller was connected at the time of the event?)

Am I just being a clueless noobie here? What's the graceful way to handle disconnection events?

Thanks for any help,
Jacob

[CurriedLambda]

This is the part of combinedInputReceived that seems to be causing problems, the acceleration and buttons don't seem to be a problem, just IREvent.

method (WRIREvent ir){

IRLight[] lights = ir.getIRLights();

my = (lights[0].getY()+lights[1].getY())/2;

ir.getSource().setIRSensorEnabled(true, WRIREvent.BASIC);

}

[CurriedLambda]

ir.getSource().setIRSensorEnabled(true, WRIREvent.BASIC);

Should I not be using this method inside of a combinedInputReceived handler?

[Cha0s]

You should not be calling it every time an IR event is received, which it seems as if you are doing. Enabling the IR sensor is a lengthy process (well, it takes a second or two, but that's a long time when you're receiving 100 reports per second), so basically, what's happening is that a lot of data backs up, since no data can be processed while something is happening in the listener. Before the next event can be processed, the IR sensor has to be re-enabled (because you called that method).

There is absolutely no reason to re-enable the IR every time, though. Once IR is on, it's on. You don't have to keep turning it on.

I do note in the documentation that you should spawn new threads if you plan on doing anything particularly time consuming in a listener thread, so do keep this in mind.

P.S. The reason you're getting the exceptions, I suspect, is that the output stream and input stream both want to close, but the input stream still has pending data. The output stream is closed first and hence, when you try to tell the remote to enable IR, it complains because the output stream is closed.
_________________
Cha0s

[CurriedLambda]

Thanks for the explanation, we'll stop using that method.

I think we put it in there because the IRSensor seemed to be timing out/shutting off so we want a heartbeat kind of function to keep it alive.

Is there any way to be sure that the a controller is safe to use (i.e. that the input and output streams are in open and ready for action?) It doesn't seem that isConnected can guarantee that.

Thanks!
Jacob

[Cha0s]

Well, isConnected guarantees that to a point. isConnected says that a disconnect has not been completed, though one may be in progress. In normal circumstances, isConnected should work fine, since any Exceptions thrown will start the disconnection process. However, when listeners perform time-intensive tasks in their event handler methods, events start to back up, and the disconnect process is halted until they complete, causing the problem. Basically, as long as your listeners behave, you shouldn't have any problems, though I'll look into a more robust disconnect method in the future.
_________________
Cha0s

[CurriedLambda]

Thanks for the quick reply, I know you're busy!