Killing an orphan process when the plugin has died

[ubu]

My plugin creates a process to run an external program (VLC) that transcodes a network stream to disk. Normally, if the user exits from the plugin (or from the playback of the transcoded file), I kill the process to stop the recording. However, if GB-PVR terminates abnormally (or the user simply closes the GB-PVR window), the process continues as an orphan (or should that be "zombie" - I'm never sure of the difference) and, since the stream continues to be received, the process will continue transcoding it until the disk is full. Not good. :eek:

I can't seem to find any way in C# of forcing a child process to die when its parent dies. Nor can I find a Win32 solution (at least not an obvious one from random googling). I can set some arbitrary time limit in the VLC transcode command that would ensure that it doesn't continue infinitely but it seems like an ugly solution (Pretty annoying to be watching a video stream and have it suddenly stop because it hit the time limit).

Is there an elegant solution?

[fooman1]

Use a destructor: ~ClassName { ...code to terminate process;... }
OR when creating the process, I'm pretty sure there is an argument to have it terminate when its parent exits.

[dark_half]

UBU I dont know if this is a simple answer but I was attempting to use vlc (see here)to capture HD via firewire and everything appears to work the first time I start timeshift tv from GBPVR. However I can not figure out how to stop vlc. Do you have any advice keeping in mind I am no programmer?

[ubu]

Use a destructor: ~ClassName { ...code to terminate process;... }

I tried using a destructor for my plugin class ( ~UbuStreamPluginTask() ) but it doesn't seem to get called if you simply close the GB-PVR window. I guess when GB-PVR is gone, so is the C# garbage collector. So much for .Net's integration with Windows.

OR when creating the process, I'm pretty sure there is an argument to have it terminate when its parent exits.

Well, that's sort of why I'm asking the question. You'd think there would be such an argument (or property or method) available for the Process or ProcessInfo classes, but I can't find anything - either in the MS docs or by googling it. A deafening silence prevails on the whole subject. So I'm wondering if there's some other way (Win32 solution, if neccesary, even).

[ubu]

Use a destructor: ~ClassName { ...code to terminate process;... }

I tried using a destructor for my plugin class ( ~UbuStreamPluginTask() ) but it doesn't seem to get called if you simply close the GB-PVR window. I guess when GB-PVR is gone, so is the C# garbage collector.

I owe you an apology. :o

Killing the process in the plugin's destructor does work fine for two of the cases I'm trying to handle. If the user simply closes the GB-PVR window, the destructor does get called immediately. If an exception throws the user out of the plugin back to the GB-PVR main menu, the destructor isn't called immediately but, if the user then exits from GB-PVR, the destructor is called then.

However one case is not solved. If the GB-PVR process is killed (like from the task manager) the destructor is not invoked so an orphan process remains. The only solution for this I can think of is to write a small daemon program that would monitor for these orphans and kill them if GB-PVR is no longer running.

[bgowland]

The only solution for this I can think of is to write a small daemon program that would monitor for these orphans and kill them if GB-PVR is no longer running.

If you're going to write something like this (a System Service I assume) then why not put the VLC/transcoding functionality into the service and just have the plugin as a UI / front end?

You could control the service from the plugin through a TCPChannel (or similar) and poll it regularly with 'keep alive' commands. If the service doesn't receive one of those after a certain timeout period it could do a cleanup then sit back and listen for the next valid command.

Just a thought.

Cheers,
Brian

[whurlston]

This is probably not the MS endorsed way of doing things but...

I wrote a program that launches a VLC process for each of the two tuners on a HDHomeRun that I have. Whenever it launches VLC it writes a temp text file with it's ProcessID:

Code:

StreamWriter w = txtFilename.CreateText();
w.WriteLine(procVLC.Id.ToString());
w.Close();

When I need to kill VLC it parses the text file to get the ProcessID and then Iterates through all running processes till it finds it:

Code:

foreach (Process p in Process.GetProcesses())
{
     if (p.Id.ToString() == procIDfromTmpFile)
       {
          p.Kill();
        }
  }

The same concept can be used to kill any running processes. Just check "p.MainWindowTitle" for "VLC Media Player" (or whaterver you are looking for) and kill it.

I think you can use p.MainModule to get the filename (vlc.exe) but I'm not sure on that as I haven't tried it.

[ubu]

I wrote a program that launches a VLC process for each of the two tuners on a HDHomeRun that I have. Whenever it launches VLC it writes a temp text file with it's ProcessID:

When I need to kill VLC it parses the text file to get the ProcessID and then Iterates through all running processes till it finds it:

I'm not having a problem saving the pid and then killing the process from my code. The problem is, who kills the process when gb-pvr (and my plugin) have been killed.

[ubu]

If you're going to write something like this (a System Service I assume) then why not put the VLC/transcoding functionality into the service and just have the plugin as a UI / front end?

You could control the service from the plugin through a TCPChannel (or similar) and poll it regularly with 'keep alive' commands. If the service doesn't receive one of those after a certain timeout period it could do a cleanup then sit back and listen for the next valid command.

Just a thought.

Cheers,
Brian

Thanks, Brian. I waited until I'd tried this before responding to you. Your proposed approach is just what the doctor ordered. Seems like it totally solves my problem.

I'd never used a Windows service before but it turned out to be fairly easy to put together. I played around with using .Net Remoting to communicate with the service but, in the end, it seemed like overkill and I used a simple TCP Channel, as you suggested. The service manages everything to do with running the VLC transcoding/recording process and responds to TCP commands "start", "stop", "info" and "continue" (the ""start" call includes a delimited set of strings to pass in the start parameters and control info; "continue" is the "stay alive" call).

The only downside seems to be having to distribute "yet another" component and having to install the service at the same time the plugin is installed. On the other hand, the service will be generic enough to be reusable by other plugins

Now I'm worrying about "What if someone kills both GB-PVR and the VLC recording service?"

Excellent "thought". Cheers!

[zehd]

I have the same trouble with ZProcess which spawns ffmpeg.exe trying to transcode on the fly for viewing files on the MVP...

What I did was:

ZProcess is called by GB-PVR.

It spawns ffmpeg.exe

It also spawns a watcher program (hunter.exe) that checks the PID of GB-PVR and the ffmpeg.exe window to see if they are both up and running.

If I kill GBPVR in Task Manager, Hunter sees it disappear and kills the ffmpeg.exe then exits...

If I kill ZProcess in Task Manager, Hunter sees it disappear and kills the ffmpeg.exe then exits...

If ffmpeg.exe crashes (an error or something) Hunter just exits.

If I exit the transcode process in GB-PVR, (graceful exit) GB-PVR kills ZProcess, and hunter takes care of ffmpeg.exe and itself.

It's not as classy as a real programmer might do, but it's been quite stable.