PDA

View Full Version : Bug in G6 remote mode?



rickerdo
May 12th, 2015, 09:20 PM
I've been beating my head against the wall trying to figure out why I cannot get my custom device ID to register. Then I found that if I change the device ID of an existing device, the same problem exists.

On a hunch, I changed the winlirc device ID and copied that modified set of files to the Windows install of G6. Then I started the Windows install in an inproc mode, enable the modified winlirc plugin, disabled it and shut down G6 on Windows. When I reconnected to the RPi remotely from the same Windows G6 install, the new winlirc device ID was now present. It seems like G6 remote is actually looking locally for device IDs instead of on the remote machine. Is this a bug?

How to repeat the issue:
1. Install G6 on Raspberry Pi (latest wheezy version with all updates)
2. sed -i 's/706/102555/' /opt/girder/lua/winlirc/*
3. /etc/init.d/girder restart
4. Connect to Pi from Windows using G6 remote
5. Enable logging on Windows G6
6. Enable winlirc plugin and try to configure it
7. Close Windows G6 remote and check Windows G6 log file. "19:33:57:579 | PluginManager::loadDevice / could not find device 102555" will appear.

To fix:
1. Copy the modified winlirc files to the Windows G6 install
2. Launch an inproc instance of G6 on Windows
3. Enable winlirc on Windows install of G6 (inproc). Note that the ID should be 102555 if done correctly
4. Exit local inproc G6 on Windows
5. Reconnect to RPi G6 using Windows G6 remote. Now the new winlirc ID is found and winlirc can be configured on the remote RPi.

Ron
May 12th, 2015, 10:05 PM
The plugin MUST be available on both the front-end and the back-end with the same id. So if you Windows copy doesn't have 102555 it won't work. I suggest for plugin development to work in-proc. That way you don't have to keep two sets of files in sync all the time. ( or figure out a way to sync up the files, smb share maybe ).

rickerdo
May 12th, 2015, 10:21 PM
The plugin MUST be available on both the front-end and the back-end with the same id. So if you Windows copy doesn't have 102555 it won't work. I suggest for plugin development to work in-proc. That way you don't have to keep two sets of files in sync all the time. ( or figure out a way to sync up the files, smb share maybe ).

WOW! Is that by design? It almost defeats the purpose of a client server design if the same plugins have to reside on both the client and server. Is there no way around this? Can I make this a feature request?

Ron
May 13th, 2015, 07:22 AM
Absolutely by design. That's why the plugin system is split into front-end code ( the Javascript files ) and the Back-end Code ( the Lua files ). Definitely doesn't defeat the purpose, it minimizes traffic required between the front-end and backend.

rickerdo
May 13th, 2015, 10:03 AM
Absolutely by design. That's why the plugin system is split into front-end code ( the Javascript files ) and the Back-end Code ( the Lua files ). Definitely doesn't defeat the purpose, it minimizes traffic required between the front-end and backend.

I understand where you're coming from. Are you open to a suggestion though? Could the "client side" make a request for all enabled plugins to download necessary JS and ui files upon startup of a client G6 and cache them locally? Maybe even add a "sync" button in the plugin settings somewhere? As you know, this how web server <-> browser interaction occurs and that's rather quick. I think we're only talking about a few KB to a few MB at most, right?

Personally, I think this would be a nice feature for anyone running a headless server, like a Rasp Pi.

Ron
May 13th, 2015, 01:50 PM
I like the idea. It would require a field in the .plugin file describing all the files that are to be included in a 'sync'. I'll have to think about how to go about doing this nicely...

rickerdo
May 13th, 2015, 02:41 PM
If you decide to move forward with the idea, I would be happy to help beta test from a user's standpoint.