Comskipper consuming large amounts of RAM?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Simply running the program (launch on system boot) - after a day or so I
notice Comskipper using several hundred MB of RAM.

What is the expected output? What do you see instead?
Why so much RAM?

What version of the product are you using? On what operating system?
Comskipper v1.0.3 on EyeTV v3.1.0.

Please provide any additional information below.

Original issue reported on code.google.com by techyd...@gmail.com on 25 May 2009 at 4:33

[GoogleCodeExporter]

same issue here. I have to manually kill (force quit) comskipper after a few 
days.
using large amounts of ram ? not flushing ?

Original comment by ktu...@gmail.com on 2 Aug 2009 at 11:22

[GoogleCodeExporter]

I am seeing the same issue under 10.6.1 with v1.0.3 You can watch Activity 
Monitor for a while and watch the 
Real Memory grow before your eyes.

Original comment by nowalm...@gmail.com on 20 Sep 2009 at 5:24

[GoogleCodeExporter]

It seems to grow at about 10ish MB per hour.  

I'm running 10.6.1 SL, with etv-comskip v1.0.3.

Original comment by nerdb...@gmail.com on 21 Sep 2009 at 1:26

Attachments:

• [Screenshot 2009-09-21 at 6.20.12 AM.png](https://storage.googleapis.com/google-code-attachments/etv-comskip/issue-20/comment-3/Screenshot 2009-09-21 at 6.20.12 AM.png)
• [Screenshot 2009-09-21 at 12.53.10 AM.png](https://storage.googleapis.com/google-code-attachments/etv-comskip/issue-20/comment-3/Screenshot 2009-09-21 at 12.53.10 AM.png)

[GoogleCodeExporter]

My ComSkipper PID 266 is up to 542.9 MB real mem usage with 0.0%CPU usage. 
Virtual
Mem 3.12GB Virtual Private 548.1MB

OS 10.6.1
Etv 3.1.2
comskipper 

Original comment by evilblen...@gmail.com on 6 Nov 2009 at 1:25

[GoogleCodeExporter]

My computer has been on with EveTV running to record a few shows and ComSkipper 
is now using 3.53 gigs of 
real memory...

Original comment by alrasalt...@gmail.com on 19 Nov 2009 at 2:29

[GoogleCodeExporter]

Any progress with this bug?  As it is right now, I have to kill comskipper and 
restart it every other day due to the 
memory leak/bug (when it reaches around 1.5gb).  

Original comment by david.bl...@gmail.com on 7 Dec 2009 at 11:49

[GoogleCodeExporter]

Comskipper for Mac is a farce, its core code is 18 months old & not being 
updated,
because the development is focusing on Windows API calls that can't easily be 
ported
to Max OS X.  i think development is continuing elsewhere, when i find out more 
i'll
post again, but forget this strain of Comskipper!

Original comment by techyd...@gmail.com on 8 Dec 2009 at 12:10

[GoogleCodeExporter]

As it happens, I'm currently working on updating comskip.

"farce" is a bit strong.  Its been working just fine for me, so I've had no 
need to
update it.

As you say, comskip itself is windows-centric, so the port is non-trivial.

Patches welcome.

Original comment by jon.chri...@gmail.com on 8 Dec 2009 at 12:23

[GoogleCodeExporter]

i'm glad it works well for some :)
but it's never worked reliably for me or anyone i know whose tried it.  some
recordings get marked, some (more than 50%) don't. sometimes it skips marked
commercials on playback, most of the time it doesn't.  and it always, after a 
day or
three, consumes ridiculous amounts of ram.

i'm not blaming you or anyone, obviously this is a casual best-effort 
non-commercial
project.  but after rebuilding with Snow Leopard recently, and seeing my friend
install the new SL-compatible version of it, and experience exactly the same 
issues
above, i'm over it & wont be spending anymore time with the current 18month old 
code.

maybe it was you that i/friend-of-mine googled the other day, i can't remember 
now -
are you documenting this new update somewhere else? need testers? i'm happy to 
help.

Original comment by techyd...@gmail.com on 8 Dec 2009 at 12:45

[GoogleCodeExporter]

Comskipper works fine for me on Mac OS 10.6.2. It is reliable and has a very 
good "sense" of what content is not 
programming (for my off-air ATSC broadcast media). The comskip process 
occasionally crashes - about 5% of 
the time - but that leaves the media file unaffected. While there does seem to 
be a memory leak, I don't find it 
nearly enough of a problem to forgo using it. I use it every day.

Original comment by azstef...@gmail.com on 8 Dec 2009 at 1:40

[GoogleCodeExporter]

Thanks for the feedback, azstefano.

I'll have to look in to this memory leak.  ComSkipper is different from comskip 
itself.
In fact ComSkipper itself is just a python script which polls EyeTV to see if 
it's
playing a recording, and if so, if the current time is within a commercial 
interval.

I don't see anything in the script which should make the memory usage grow.  
Perhaps
there's a leak in python itself, or appscript?  Something which would cause a
long-running process to gradually accumulate memory.

-Jon

Original comment by jon.chri...@gmail.com on 8 Dec 2009 at 2:00

[GoogleCodeExporter]

As I said in the EyeTV forums, I have Wine+Comskip v80.025 working on my 
machine using the etv-comskip 
script. It works, but does have some annoying aspects - the biggest is that 
Wine launches X11 everytime it is 
called. I have not tried running it using wineconsole since upgrading to Snow 
Leopard, so maybe this report is 
accurate: http://bugs.winehq.org/show_bug.cgi?id=16702

I do not have ComSkipper running due to the memory leak, but since I generally 
share out my EyeTV 
recordings to a UPnP device, this is not as important to me.

I will be getting some directions on this setup on the Elgato forums on 
Thursday (my next day off from work).

Original comment by nowalm...@gmail.com on 8 Dec 2009 at 2:54

[GoogleCodeExporter]

I'd love to help debug this - but lack the proper coding kung-fu.
What would be helpful in looking at it - I would be happy to post "sample 
process"
reports from Activity Monitor or any kind of log file if you'd like.

I've got the same issue others have. With 10.6, memory slowly gets eaten up by
ComSkipper application. 

I wouldn't mind knowing how to stop it and restart it again... maybe a cron job 
every
24 hours killing and restarting it?

Let me know if you need any files that would help you debug.
Regards,
Jeff

Original comment by evilblen...@gmail.com on 8 Dec 2009 at 3:23

[GoogleCodeExporter]

There does seem to be some kind of memory leak in the AppKit and appscript 
calls, but from what I gather this 
is something scripters have lived with since the start of OS X. It seems the 
standard workaround is to do fork() 
and waitpid() and have child processes do the calls, and then expire. However 
as you say, ComSkipper is really 
doing so little, and the leak is quite slow, so simply restarting once a day is 
probably the best option.

A script to do this can be found at 
http://forums.elgato.com/viewtopic.php?f=117&t=1823

I attached a slightly modified version of it to be placed in 
/etc/periodic/daily and made executable

Original comment by dacl...@gmail.com on 14 Jan 2010 at 2:35

Attachments:

• 500.dvr

[GoogleCodeExporter]

Stupid question, where is etc located? 

Original comment by nerdb...@gmail.com on 14 Jan 2010 at 2:40

[GoogleCodeExporter]

Far better would be to create a LaunchAgent and launch it via launchd

Original comment by nowalm...@gmail.com on 14 Jan 2010 at 3:06

[GoogleCodeExporter]

I've finally figured out what what is causing this!

The version of appscript Comskipper is using is version 0.18.1.  This this 
version of
appscript itself leaks (buckets of) memory with a simple script such as:

from appscript import *
while 1:
   app("Finder").visible.get()

which is the most highly-simplified version of what ComSkipper does.

Luckly, there is now an updated version of appscript (0.21.1) which doesn't 
suffer
from this leak, and should therefore avoid the leak in ComSkipper.

Original comment by jon.chri...@gmail.com on 22 Apr 2010 at 4:30

[GoogleCodeExporter]

Original comment by jon.chri...@gmail.com on 22 Apr 2010 at 4:33

• Changed state: Fixed