Channel executable not being called properly?

[PatM]

I set up eventghost to change channels and it works great from inside EG and from a command prompt. The command goes like th

"C:\Program Files\EventGhost\EventGhost.exe" -e channel 1 252

From the command prompt I have to quote the path part thanks to the oh-so-brilliant space in the path name supplied by MS.

I have the same path part in NextPVR as the executable in in arguments I have

-e 1 {channel}

The 1 is for tuner 1 and I can use 2-3 (don't have a third tuner yet though).

As I said, from a command prompt it all works perfectly but NPVR doesn't appear to actually execute the command. EG shows when it's received any input and nothing at all shows up in the log window for EG. NRecord.log shows the exact path and arguments as I use in the command promt but without the quotes.

I was thinking perhaps it was the space in the pathname but I can't manually add quotes to the path.

Any ideas if I'm doing the arguments wrong or perhaps the space in the path is really the problem?

[sub]

The app is calling it correctly:

2012-04-23 09:06:23.414 [INFO][14] Running blaster: C:\Program Files\EventGhost\EventGhost.exe -e channel 1 252

It doesn't need the quotes with the API I'm using.

It'll be something to do with how the recording service is running as a service under a different user account, like EventGhost.exe is trying to use the clipboard (WM_COPYDATA) to pass the info to it's main process, but doesnt manage it to see it, so nothing happens.

[johnsonx42]

google for "cmd as system user", then go ahead and get a command prompt running as system. from that command prompt you can try your eventghost command running the same way as NRecord runs it.

if you're not able to get eventghost to work that way, you can try changing NRecord to run as a regular admin user from the Services control panel.

you can also try googling for "eventghost as service" - it seems some have been successful at getting an instance of eventghost running as a service and/or as local system.

[PatM]

Ok, I changed it so that NRecord runs as the same account that is always logged on and running Eventghost - which is an administrator account.

I still get no messages to eventghost but I did notice that NPVR actually ends up creating eventghost processes. Like it's actually starting a new copy of eventghost instead of just getting a message to it. Or perhaps those are fireonce processes that are stuck because they can't talk to eventghost?

Either way that sounds like I should be talking to the EG people as NPVR does appear to do what it's supposed to do.

[sub]

Ok, I changed it so that NRecord runs as the same account that is always logged on and running Eventghost - which is an administrator account.

This may not be enough - if it's trying to use one of the common tricks like WM_COPYDATA (ie clipboard) to transfer data to it's main program, then it's in a different desktop session (desktop vs service) which doesn't share a clipboard.

I still get no messages to eventghost but I did notice that NPVR actually ends up creating eventghost processes. Like it's actually starting a new copy of eventghost instead of just getting a message to it. Or perhaps those are fireonce processes that are stuck because they can't talk to eventghost?

You're telling it to run new copy of eventghost.exe with specified parameters, which is exactly what it does. This is how lots of programs are designed to work though, ie one instance runs as the main process, then any subsequent runs just connect to the main process, pass some commands over, then exit. The main process then acts on those commands. In your case it sounds like this "pass some commands over" part is failing, probably because of the service vs desktop separation. The EventGhost guys are bound to have come across this before, and will almost certainly have some fix for you.

[PatM]

I got a reply on the EG forums. They said to use a netreceiver plugin. I tried it on a laptop just to see how it works (turns out you MUST use a password - leaving blank results in MD5 errors) and it seems ok. I'll try it out on the server tonight.

Seems like a very usable solution as the service can send TCP data without need of clipboards etc (from my vague recollections of past programming I did).

[sub]

Yep - sounds like that would do the job.

[PatM]

I added the net receiver last week and it works perfectly. The only gotcha's are:

1) You must add a password in ther receive, leaving it blank results in MD5 errors when you send a message (so you must supply password with the message obviously)
2) Extra data (the IP) is added to the FRONT of the message so you have to accomodate that.