mattmartini / itivo

Automatically exported from code.google.com/p/itivo
Other
0 stars 0 forks source link

Cancel download leaves orphaned processes (mencoder, tivodecode, and curl #11

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. start downloading a show
2. cancel download
3.

What is the expected output? What do you see instead?
Download stops, but orphaned processes need to be cleaned up, and cannot
reinitialize any new downloads until process(es) are manually halted

What version of the product are you using? On what operating system?
1.21-Leopard 10.5.5

Please provide any additional information below.
Not a big issue, thought it might help to report it.

Original issue reported on code.google.com by dave.man...@gmail.com on 28 Oct 2008 at 7:14

GoogleCodeExporter commented 9 years ago
It's SUPPOSED to clean up orphaned processes via a kill and a kill -9.
  Is it always failing to kill them?  Are there any special circumstances going on?

Original comment by yoav.yer...@gmail.com on 29 Oct 2008 at 5:19

GoogleCodeExporter commented 9 years ago
It doesn't appear to be killing them. I only waited a minute or two. I can't 
think of
anything specific with my config. Now I will say, I am also having an earlier
reported bug with not getting file extensions, so maybe my config is hosed 
somehow. I
re downloaded and reinstalled. I could created a new user and see if that fixes 
things.

Original comment by dave.man...@gmail.com on 29 Oct 2008 at 7:00

GoogleCodeExporter commented 9 years ago
a bit more testing. Deleted plist file, which fixed the file extension problem.
Cancel download still not working. File continues to download unless process is
manually killed.

Original comment by dave.man...@gmail.com on 30 Oct 2008 at 12:27

GoogleCodeExporter commented 9 years ago
The code in the beta should clealy try to kill every such named process, then 
kill -9
the process.  so it REALLY shouldn't leave anything around unless it's stuck in 
I/O
(and that's the kernel refusing to let the process die -- nothing I can do 
about it).

Original comment by yoav.yer...@gmail.com on 7 Nov 2008 at 12:12