Girder NR passthrough and GC

[Wilhelm]

Hi all,

after nearly a year and with a new version of girder (5) I wanted to try again, if the IR passthrough is now getting me somewhere.
I think I'm going crazy! Is there anybody out there who can describe how I can setup this simple thing?
Girder has nothing else to do than to relay the IR codes from NR to GC. It simply doesn't work. The passthrough option doesn't save it's setting and instantly reverts to USBUIRT.

Please if you can, a list of simple steps to set up this scenario...

Thanks

[Wilhelm]

I've just seen, that only the Pro version supports GlobalCaché. Is it possible that this is broken in the Trial version?
BTW the dialog to setup the GC is broken as well, The input fields appear somewhere on the dialog when I press the add button...

[Ron]

That is strange, are you seeing any errors in the lua console or log screen?

[Wilhelm]

Yes, certainly. Because the GC setting is not saved, every code sent by netremote produces an error message in the log, that the USBUIRT is not connected.

[Wilhelm]

Ok, here are my findings so far, and I'm not impressed:

1. I had to manually edit the registry and enter "Global Cache" into the Promixis/Girder/Plugins/NetRemoteIR/IRHandlerDevice value.

2. I had to delete the settings for the Globalcaché that I entered before for the GC plugin. (The dialog to set this plugin up is broken, as I reported before)

3. After I start Netremote, I have to press several buttons until the connection (Girder passthrough) actually works

4. If I press a button and release it too quickly, Girder seems to send the STOPIR command to GC before the GC actally has sent the 1st code, which actualy stops the transmission before it is complete so the code is never valid and the device (Amplifier, DVD-player, whatever) doesn't react.

5. I had several occasions, where the STOPIR never was sent to the Globalcache so the code was repeated indefinately. Too bad, if it's volume up. (We had that with NR before, but it never happened for years now) So Girder is to blame.

6. The Up-side is, that I am now able to connect more than one client simultaneously to the same GC and its much quicker, when it works. So that would really be an advantage if Girder passthrough would work reliably. This would even convice me to invest 20W to run a Atom-Box 24/7 and combine NR and Girder.

I am very sad, that every time I try something, I find a bunch of bugs. I am a loyal NR user for years now, but I still feel like testing beta software.
I'm a Software developer myself so I know, that it's difficult to test a new piece of software, but after years I really would love a bit of stability now and then.
Frustrated, but still hopeing

[Wilhelm]

Additional finding:
After the last client disconnect from Girder, a reconnect doesn't work. After a timout of about 1 minute, girder logs "22:46:35:796 3/30/2009 Girder IR Passthrough Not connected to Global Cache192.168.1.100" after that it works again.
My interpretation is, that Girder disconnects from GC when the last client exits and forgets to reconnect to the GC when a new client starts. There seems to be a timeout of about 1 minute, until Girder realizes, that its not connected any more and reconnects to GC.

[Rob H]

Try these replacements for plugins\treescript\GlobalCache UI.lua and plugins\ui\GlobalCache.xml

They should fix the UI issues at least.

[Wilhelm]

Thanks, I'll try.

[Wilhelm]

Sorry for the delay.
Unfortunately the IR passthrough dialog still doesn't save it's settings.

[Rob H]

I've not been able to test that since I don't have a GlobalCaché here. I'll see if I can figure out what's going on tomorrow though.