[OPEN] Error in USB-UIRT action

[loomy]

I have the TV and PC power buttons on my MCE remote bound to the same toggle macros. So it is two toggling macros, both taking 4 IR signals in to represent the 2 buttons, and each macro outputs 2 IR signals.

Sometimes an IR signal doesn't get output by the usbuirt. Sometimes this happens when an error is reported in the log. Sometimes no error is reported.

A series of presses follows. The error is obvious here, but at the end I show that an error occurred again and was not reported.

Code: Select all

USB_UIRT.3F2C4FF240F1
USB-UIRT: Switch TV to video 1 and amp to cd/dvd
USB-UIRT: tv tv/video
Error in Action: "USB-UIRT: tv tv/video"
Traceback (most recent call last) (1150):
  File "C:\Program Files\EventGhost\eg\ActionClass.py", line 150, in CallWrapper
  File "C:\Program Files\EventGhost\plugins\USB-UIRT\__init__.py", line 228, in __call__
  File "C:\Program Files\EventGhost\plugins\USB-UIRT\USB_UIRT.py", line 385, in TransmitIR
UUIRTError: Error calling UUIRTTransmitIR
USB-UIRT: amp cd/dvd
Error in Action: "USB-UIRT: amp cd/dvd"
Traceback (most recent call last) (1150):
  File "C:\Program Files\EventGhost\eg\ActionClass.py", line 150, in CallWrapper
  File "C:\Program Files\EventGhost\plugins\USB-UIRT\__init__.py", line 228, in __call__
  File "C:\Program Files\EventGhost\plugins\USB-UIRT\USB_UIRT.py", line 385, in TransmitIR
UUIRTError: Error calling UUIRTTransmitIR
Disable: USB-UIRT: Switch TV to video 1 and amp to cd/dvd
Enable: USB-UIRT: Switch TV (last channel) and amp (video 1) back to defaults
Flush Events
Stop processing this event

USB_UIRT.81000000E05E
USB_UIRT.3F2C4EF250F1
USB-UIRT: Switch TV (last channel) and amp (video 1) back to defaults
USB-UIRT: tv r-tune last channel
USB-UIRT: amp tape
Disable: USB-UIRT: Switch TV (last channel) and amp (video 1) back to defaults
Enable: USB-UIRT: Switch TV to video 1 and amp to cd/dvd
Flush Events
Stop processing this event

USB_UIRT.3F2C4EF250F1
USB-UIRT: Switch TV to video 1 and amp to cd/dvd
USB-UIRT: tv tv/video
USB-UIRT: amp cd/dvd
Disable: USB-UIRT: Switch TV to video 1 and amp to cd/dvd
Enable: USB-UIRT: Switch TV (last channel) and amp (video 1) back to defaults
Flush Events
Stop processing this event

At the end of this my tv was in video mode 2, when it should only be in video mode 1. This should be impossible if the log is reporting correctly, because the second last macro should have moved the tv from video mode 1 to video mode 0. What REALLY happened is that "USB-UIRT: tv r-tune last channel" and "USB-UIRT: amp tape" never made it to the tv. The blink pattern on the usbuirt was even different.

I tested the IR signals manually and they appear to work properly. So I believe that the IR isn't sending sometimes because of EG or the usbuirt plugin. And the problem seems to occur even when the error is not reported, if that helps.

[Bitmonster]

This is very odd. The USB-UIRT never stopped working this way here and I use it daily. So actually it looks a bit like a faulty piece of hardware or bad driver installation. But before we assume this, attach your XML config file here, so I can prove this error doesn't show up here.

[loomy]

Driver or hardware problem is possible because I've had USB issues on this computer before. Right now usbuirt is plugged into a PCI usb adapter.

I've tried to duplicate the problem with the "Execute Item" button in EG. I haven't been able to yet.

Try \tv control vs computer control\power toggle\turn power on/off

Mashing that in EG doesn't seem to break it, but mashing the remote does. One thing that I find happens is that the first usbuirt command will be dropped silently, so the log looks right but the first command isnt received by the tv in this case.

[Bitmonster]

I can reproduce the error here. This seems to be a bug of the USB-UIRT driver when simultaneously receiving and transmitting IR. Will have to look if a workaround can be found.

[Bitmonster]

I have reported the problem to Jon Rhees. There is currently not much I can do from EventGhost's side to circumvent this bug.

[loomy]

I have reported the problem to Jon Rhees. There is currently not much I can do from EventGhost's side to circumvent this bug.

Thank you! I will email him to see if I can help at all.

[Bitmonster]

One way to workaround this bug is setting the "Wait of IR inactivity before transmission" to a value like 200ms for at least the first transmit action in every macro. This way the transmit action will wait till you release the button on the remote before sending out the IR code. This might also be desired if your equipment is in the same line of sight as the MCE remote because otherwise the IR transmission of the MCE remote and the USB-UIRT might overlap and disturb each other.

[loomy]

One way to workaround this bug is setting the "Wait of IR inactivity before transmission" to a value like 200ms for at least the first transmit action in every macro. This way the transmit action will wait till you release the button on the remote before sending out the IR code. This might also be desired if your equipment is in the same line of sight as the MCE remote because otherwise the IR transmission of the MCE remote and the USB-UIRT might overlap and disturb each other.

I did that and still get the Error in Action: "USB-UIRT: amp cd/dvd", so I'm not sure that delay helps the plugin to not break

[Bitmonster]

F**k. I tried it a hundred times and the error didn't show up, while with a setting of 0ms I can reproduce the error nearly every tenth execution.

[loomy]

F**k. I tried it a hundred times and the error didn't show up, while with a setting of 0ms I can reproduce the error nearly every tenth execution.

Based on this I'm trying to troubleshoot it more accurately. I think we may be talking about different things at times. My two problems were: 1) red error reported, no command sent. 2) no error reported, no command sent.


Summary: adding a delay to the IR execution is a workaround that avoids the problems. But the problems are still present. And they seem to be isolated to the use of the MCE remote with EventGhost and the USB-UIRT plugin.

I created two macros: A) one that sends one IR command, and B) one that sends two IR commands to two different devices. I press/click these slowly to make sure a signal isnt sent before the device is ready to accept. So this is non-mash testing.

For A: (red errors)
4 repeat and 0 delay on the IR means almost guaranteed red error.
1 repeat and 0 delay on the IR means almost guaranteed red error.
1 repeat and high delay (100-200+ms) means usually no red error. (mashing here can generate a red error)
Executing these manually on the computer means no red error (ever).

So the error seems to be related to the mce remote we're using. It feels like the button being in a certain state at a certain time causes the error.

For B: (never any red errors) (The states of these two devices should remain synced, otherwise one of the commands was lost.)
4 repeat and 0 delay results in no red errors, but sometimes the first command is lost.
1 repeat and 0 delay results in no red errors, but USUALLY the first command is lost.
1 repeat and 200ms delay results in no red errors, and the first command is only lost when you mash the remote the right way.
Executing the last macro manually NEVER results in a lost command.


So there are two different problems happening here. Whether they are because of the same bug, I don't know. I hope I didn't miss anything in those tests that would contradict the results. You can try to disprove what I just did to prove it is right

[Bitmonster]

This is very odd. But you are right that this problem has to do with the right timing and that might be the reason why we see this happening on one machine, but maybe not on another. My tests also show that the MCE remote is much more prone to trigger this error than any other remote.

But actually it wonders me, that a higher wait timeout doesn't circumvent the error. My observations are that this error only gets triggered if receiving and transmitting are simultaneous. Do you have any stray events showing up from the USB-UIRT if you don't use the MCE remote?

[loomy]

Do you have any stray events showing up from the USB-UIRT if you don't use the MCE remote?

I don't know what you mean by this, but there was #2 here: http://www.eventghost.org/forum/viewtopic.php?f=2&t=575

[loomy]

More information for the record. I believe the usb-uirt plugin is a bit broken.

This takes "up" from the mce remote into usb-uirt, and then sends an ir command out with usb-uirt:

(Simple test macro)
(Event) USB_UIRT.432689F040F1
(Event) USB_UIRT.432688F050F1
(Action) USB_UIRT.TransmitIR

Holding down the up button will hold the eventghost icon in the red and the macro sequence will stall at "USB_UIRT.TransmitIR" in the log, with no action sent, until you let go of the button. Doing that will make the icon go yellow, then the ir transmit will complete, then the icon will go green and the macro is done.

Doing this same thing with a slight different results in the sequence stall happening when the icon is yellow. Let go of the up button until the icon goes yellow, and press and hold it again before the transmission is sent. It will halt at yellow with the outcome being the same as in the first case above.

Doing as in the second case, only now pressing rapidly before the signal is sent, will keep the transmission paused AND queue up a long list of input->transmissions which are sent when the button is let go permanently.

Holding the button down and then pressing a button on another remote will trigger the yellow icon. Letting go of the up button while holding down the other remote button will keep the queue stalled. Letting go will release the transmission queue which was received during the stall, just as above.

The stall/pause takes place AFTER the event and the macro are shown in the log, AND after "(Action) USB_UIRT.TransmitIR" is shown in the log, even though the action was never sent. So Eventghost is sending the action to the log prematurely.

I believe the usbuirt plugin/interface/device is broken such that the output is not allowed to proceed until any and all input has ceased.