EventGhost

It will be MUCH more responsive to use the python code than to launch the executable. Kicking off a java program is going to have some lag while it shells out and runs. If you spend a couple minutes getting this working, I think you'll be happy with the result. Let me know if you try it.

~K

It should be considerably faster to use a python script, since it will be running in the same process - no startup time. Also python is a much nicer language than Java (from someone who uses both daily, but unfortunately Java considerably more ...).

<edit>Oops - didn't see there was an essentially identical response just over the next page ...</edit>

this might come in handy for anyone using this plugin:

http://www.eventghost.org/forum/viewtop ... 66&start=0

I made another minor change/ addition to the plugin.

I've added the ability to overide the port when sending. If you set the port to 0 it will use the default port (i.e. the one it's listening on)

I also put some extra strings in the text class for the translator. Originally the plugin config was using the text class but not the sender config.

When my broadcaster plugin is enabled, it sucks down 50% of my CPU. Anyone else get that experience?

No, I haven't seen that behaviour. There are a few versions of this plugin around, does it happen with all of them?

If you start a new macro tree from scratch and only add the broadcaster does it still happen?

it was an older version of the plugin

I vaguely recall that happening with an older version. Did updating it fix the problem?

is it possible to get the latest version added to the default install?

It seems to have reached a point where it is pretty stable, and works for a variety of needs.

I tested the latest version, but there is one problem:
EventGhost can not start with a command line argument -translate.
I made some minor adjustments and now it's okay.
Can you please test, whether this modified version 2.1 is functional and stable?
If it is okay, I can commit it, I mean to save this version to the SVN repository.

Note:
I have noticed two unusual practices in the plugin:
1) Lines 60 and 61 - I do not understand what it is to serve. I Comment it and my tests are okay.
2) Class Broadcast(eg.ActionWithStringParameter) was defined as subclass.
I also do not understand why that was. I changed it to a normal class and my tests are also okay.

Pako

The latest broadcaster broadcasts events like

broadcaster.eventname,payload=XX

Not very helpfull since the ,payload=xx is part of the event name and porks my installation (unless I want to add 100 volume events to trigger a volume change).

Pako: I tested your new version and it seems to work fine. The weird stuff you found was probably left over bits because a lot of people modified this plugin

Fiasco: I'm not sure what problem you are having. Can you elaborate?

maybe you need to change the payload delimiter to:

payload=

for backward compatibility?

Yeah I figured that out.

I actually have to set the the delimiter to ,payload=

But that leaves outgoing broadcasts broken as far as my control system is concerned because the older broadcaster plugin sent messages as broadcaster.event,payload=XX

hmmm. I'm not familiar with your system so again, it's not really clear to me what the problem is. If you can be a bit more specific, maybe I can help.

Based on other posts I've seen from you I imagine you'll probably come up with something on your own. The plugin has certainly changed from its original form, but I think overall it has been for the better. So hopefully we can make it work for you without too much hair pulling.

Are you trying to rebroadcast events or something?

If I can modify the plugin to accomodate your needs without breaking its current functionality, I'd be happy to give it a go.

Still figuring out what is going on.

Send part is fixed by the ,payload= delimiter.

Now say there is a volume change on my Onkyo

Broadcaster broadcasts
Command: Z1Volume
Payload: {eg.event.payload}

But what actually gets broadcast is
stereo_volume,payload=23