Launch applications from Recording Service

[majstang]

Since Recording Service is runned as a Windows Service application, launching applications which have a userinterface or messageboxes of any kind from Recording Service will fail. This is because normally service applications and ordinary desktop application runs in different users sessions. Microsoft have introduced some kind of limited permission for service applications to launch desktop applications into the service session. If for example trying to launch the DVBViewer application from a RS process task will fail...nothing happens.

These scripts makes it possible. The senderscript creates a named pipe and DVBViewer is launched through this pipe. This senderscript is launched from a RS process task. In the desktop users session (where your applications normally are loaded) there is a receiver script. This receiverscript has to be autostarted with Windows and be open before running the RS process task. When sender- and receiverscript connects the command starting DVBViewer will be tunneled through from the service users session to the desktop users session and be launched as an ordinary desktop application. The sender script can apart from launching which ever application you wanna launch, also be used sending non-forceful shutdown commands from RS and in doing so circumvent the fact Recording Service are using forceful shutdown. You will loose all different kinds of unsaved data if RS forces the shutdown after for example a recording finishes.

 

Scripts are as usual written in Autohotkey. It is tested and works on Windows 7. The complexity of this script required help from one of the gurus at the Autohotkey forum, namley HotKeyIt. Many thanks! I hope it can be useful for any DVBViewer/RS user out there. For me it will come in handy when developing my Intelligent Hibernation script further

 

Receiverscript

 

- Copy the code and paste it into an emty notepad sheet.

- Change the path to what path you choose for the Receiverscript.exe on the last line in the script.

- Name the file to Receiverscript.ahk

- Save and compile the .ahk file to an exe.

- Make a shortcut and drag it to the autostart folder on the start-menu

- Start it manually if you dont wanna restart Windows at this point.

- Have in mind this script MUST be started before running the senderscript from RS.

 

#NoTrayIcon
While !DllCall("WaitNamedPipe","Str","\\.\pipe\Receiverscript","UInt",0xffffffff)
Sleep, 100
Run % """" A_AhkPath """ \\.\pipe\Receiverscript"
Sleep, 500
Run, Receiverscript.exe, D:\ScriptsForWindows7 ;Change to your own path for this receiverscript

Senderscript

 

- Copy the code and paste it into an emty notepad sheet.

- Change the path to your own DVBViewer.exe in the script.

- Name it Senderscript.ahk, save and compile it to an exe.

- Rightclick RS systray icon and choose Configure.

- Create a new task and tie the task to the Senderscript.exe.

- Bring up RS Webinterface-->Tasks and execute the task you just created...and DVBViewer should start.

 

Sleep 4000 ;Just wait a little before creating pipe
#NoEnv
ptr := A_PtrSize ? "Ptr" : "UInt"
char_size := A_IsUnicode ? 2 : 1

Script=Run, DVBViewer.exe, D:\Program Files\DVBViewer ;This is the line where you insert your command to be executed from RS. Change the path to your own.
;If you wanna execute a non forceful shutdown for examle do it like the line below.
;Script=Shutdown, 1

; To prevent "collision", pipe_name could be something mostly "unique", like:
;   pipe_name := A_TickCount
pipe_name := "Receiverscript"

; Before reading the file, AutoHotkey calls GetFileAttributes(). This causes
; the pipe to close, so we must create a second pipe for the actual file contents.
; Open them both before starting AutoHotkey, or the second attempt to open the
; "file" will be very likely to fail. The first created instance of the pipe
; seems to reliably be "opened" first. Otherwise, WriteFile would fail.
pipe_ga := CreateNamedPipe(pipe_name, 2)
pipe    := CreateNamedPipe(pipe_name, 2)
if (pipe=-1 or pipe_ga=-1) {
   MsgBox CreateNamedPipe failed.
   ExitApp
}

; Wait for AutoHotkey to connect to pipe_ga via GetFileAttributes().
DllCall("ConnectNamedPipe", ptr, pipe_ga, ptr, 0)
; This pipe is not needed, so close it now. (The pipe instance will not be fully
; destroyed until AutoHotkey also closes its handle.)
DllCall("CloseHandle", ptr, pipe_ga)
; Wait for AutoHotkey to connect to open the "file".
DllCall("ConnectNamedPipe", ptr, pipe, ptr, 0)

; Standard AHK needs a UTF-8 BOM to work via pipe.  If we're running on
; Unicode AHK_L, 'Script' contains a UTF-16 string so add that BOM instead:
Script := (A_IsUnicode ? chr(0xfeff) : chr(239) chr(187) chr(191)) . Script

char_size := (A_IsUnicode ? 2:1)
if !DllCall("WriteFile", ptr, pipe, "str", Script, "uint", (StrLen(Script)+1)*char_size, "uint*", 0, ptr, 0)
   MsgBox WriteFile failed: `%ErrorLevel`%/`%A_LastError`%

DllCall("CloseHandle", ptr, pipe)


CreateNamedPipe(Name, OpenMode=3, PipeMode=0, MaxInstances=255) {
   global ptr
   return DllCall("CreateNamedPipe","str","\\.\pipe\" Name,"uint",OpenMode
       ,"uint",PipeMode,"uint",MaxInstances,"uint",0,"uint",0,"uint",0,ptr,0,ptr)
}

Edited February 21, 2011 by majstang

[majstang]

Sorry, guys! I'd made a codemisstake in this posted version. That is why most of you, who may have tried it, didnt get the script to work. I have now corrected it a tested the script on Win7 32-bit and it works.

[Palle Villesen]

Sorry, guys! I'd made a codemisstake in this posted version. That is why most of you, who may have tried it, didnt get the script to work. I have now corrected it a tested the script on Win7 32-bit and it works.

 

Ok, will give it another try, thanks for the effort!

[subvertbeats]

Hey majstang

 

Tell me a little bit more about some scenarios where this might be useful?

 

Thanks,

 

B

[majstang]

Hi subvertbeats!

 

It is essential for example if running my "automated commercial remover" script as an after recording task. I'm not abled to hide every userinterface part of the ACR script (for example when videoredo edits the recording a trayicon is visible) and if executed from RS without this "launch apps from RS script" it will stall and hang forever. Sadly I'm still struggeling with the ACR script and will not be abled to finish it sometime soon, being busy at work.

 

The main reason for the launch apps from RS script was simply to get my interceptshutdown script for Win7 to work, which was not possible cuz RS turned a non-forceful shutdown command into a forceful one which is not interceptable (this is a bug still remaining).

 

Other scenarios is hard to come up with since most folks start thier apps with eventghost and such, but it is always nice not having these restrictions that the case were before. I'm sure resourceful peoples on this forum will come up with great ideas how to get use of this script. If for example getting a pre-recording-task for RS will increase its possibilities of use for sure.

Edited January 26, 2011 by majstang

[Palle Villesen]

Tell me a little bit more about some scenarios where this might be useful?

 

I'm having a .bat script that checks for a lock file - then either goes into standby or keeps the computer alive. I'm setting my lockfile by calling the bat with parameters, like "script.bat keep_alive" or "script.bat reboot_if_unlocked" and so on... This is done from xbmc.

 

When finishing a recording, I would like to computer to 1. go to standby if it is unlocked or 2. just finish recording if it is locked (maybe handbrake is running, utorrent is getting a tv show or whatever).

 

Basically, it is nice to code a loooong intelligent shutdown script, that checks for playback, lockfiles and whatnot instead of just shutting down. Otherwise I have to decide when scheduling a recording i I want the computer to suddenly go on standby (while we were watching a movie through xbmc) - or not (and then it stays on for the rest of the night).

 

The problem is that I can not call the bat script from recording service using windows 7, because a service is not allowed to do that (non-tech explanation). That's why I need this script, so I can set it and forget it.

 

I hope the scenario above answers your question.

[subvertbeats]

Thanks guys

 

So majstang - this code is used inside the Intelligent Standby / Intelligent Hibernate script that you wrote?

 

I'll have to think harder about scenarios for post record, but you're right pre-record scenarios are easier to think of.

Is pre-record tasks something you know is on the way, or just on your wish-list?

 

Palle - have you checked the intelligent hibernate script from majstang? Works great, but I guess due to the code structure (using a set of nested if then clauses - one per blocking app) its not ideal for having a list of many apps that you want to block the shutdown/standby/hibernate.

 

I think this could be easily changed though to simply have the list of processes in an array and a function to check if any are active, and avoid the need for an external lockfile.

Having it self contained in a single script seems the simpler solution - is there something Im missing about why you'd need such a lockfile?

 

Sorry, dont mean to hijack the thread by going OT.

[majstang]

So majstang - this code is used inside the Intelligent Standby / Intelligent Hibernate script that you wrote?

 

I'll have to think harder about scenarios for post record, but you're right pre-record scenarios are easier to think of.

Is pre-record tasks something you know is on the way, or just on your wish-list?

Well, launch apps from RS script is integrated ONLY into the intelligent hibernationscript if using the "Adapted Windows 7 Intelligent Hibernation and Interception package" in post 26 in the another intelligent hibernationscript topic. The intelligent hibernationscript you are using does not use this launch apps from RS script (to keep it as simple as possible to setup). The difference is the second one (your intelligent hibernationscript) is loaded in the service session only and the first in the desktop user session which allows launching what ever apps (with unserinterface) you wanna launch and in the same time have the hibernation functionality. So my own intelligent hibernationscript version will include the ARC script, first taking care of removing the commercials from the recordings and then taking care of the powermanagement. This is the only way, cuz there is no possibility to use two after recording tasks on the same recordingtimer in RS.

 

Im not aware if pre-record tasks is on the way. I posted a suggestion about it some time ago, but unfortunately no response from the developer so far. It may very well be we will never see such a task, cuz if squeezing in a timeconsuming task (or several with script) between for example the wake-up and when the recording engine start, could have bad implications upon synchronization. Im not sure RS is equiped to deal with this or solvable with good programming. This does not hinder me from taking all the opportunities I can to promote the idea though

 

Sorry, dont mean to hijack the thread by going OT.

No worries, having folks venting their ideas in here is the fun part

Edited January 27, 2011 by majstang

[dbraner]

Have you tried to enable the option "may interact with the desktop" in the windows properties for recording service? Maybe this solves your problem starting an application which interacts with the desktop.

[majstang]

Have you tried to enable the option "may interact with the desktop" in the windows properties for recording service? Maybe this solves your problem starting an application which interacts with the desktop.

@dbraner, have you tried this? When doing so several problems presents itself.

1. Before any application can be runned you have to press on a msgbox button to "show message" (quite easy to press this button by script).

2. All applications (for example running DVBViewer) will be executed into some kind of special Interactive Services mode without Aero (Win7). Not really runned in real desktop mode in other words and no access to other desktop applications from here.

3. After 1 minute of inactivity in Interactive Services mode (no mouse movement) user will be logged out from windows.

4. When application is finished or closed you have to press an another msgbox button to return to real desktop.

5. You still cant send messages from RS to Windows API (standby, hibernation and shutdown excluded of cuz)(RS still forces the shutdown though).

 

In conclution this option is not especially smooth in my opinion. I still prefer "Launch applications from Recording Service" script, cuz it avoids all this hassle the "may interact with the desktop" option brings.

Edited February 13, 2011 by majstang