Comskip Support Forum

what would make the detection be so dramatic from 80_42 and 81_31 can I compile something for you to look at. I would like to take advantage of the 8 treads in the 81 chain release which does not work on the 80 chain.

Thanks

The big changes between 0.80.42 and 0.81.31 are

from 0.80 to .081 I changed all demuxers and decoders. Big change but detection quality should be the same.
because of this chage Live TV porocessing was lost, but .wtv was added as a supported format.
But also avi and mp3 and many many more formats where added.

From 0.81.23 to 0.81.24 I changed the way the timeline is internally handled.
Initialially I got it wrong (it was a big changed) but in 0.81.31 it seems to mostly be right.
There are still some problems with content from a mixed 29.94 fps and 25 fps origin and some AC3 formats causing loss of audio decoding. But missing frames and changes in fps during a show should no longer be a problem when using any of the time based output formats such as .edl.

I'm interrested in recordings Comskip can not decode

BUild 0.81.34 contains test code for Live TV support.
Give it a try if you are still interrested and feedback the results.

hey erik

I just wanted to let you know that the current version comskip81_049_donators with Elgato EyeTV and hauppauge hdpvr is working with h264 and livetv detection!

I upgraded Wine to the newest version and since I am using Mountain Lion I upgraded XQuartz and set the following in the comskip.ini

volume_slip=160
livetv=1

Thanks for the hard work!

- Jeff

Hi Jeff and Eric,

Jeff's report prompted me to try live detection again. (I last tried shortly before the olympics and I don't remember the details, but I ended up giving up since I wasn't sure it even should have been working.) My setup is like Jeff's except I've got EyeTV brand tuners, which are MPEG-2 rather than H.264. Also using 0.81.049.

Anyway, this might be academic since live detection is in fact working as long as I use livetv=1, but I thought I'd throw this out for confirmation.

With livetv=0, detection occurs but I end up with no .edl file and the following log entries (from the MarkCommercials app):

Sat Nov 17 15:32:25 2012 - Return code is: 26368, 0x6700
Sat Nov 17 15:32:25 2012 - Error code is: 103, 0x67
Sat Nov 17 15:32:25 2012 - Error: unknown error code from comskip: 103, assuming it worked.
Sat Nov 17 15:32:25 2012 - Error: accessing 00000000165849d4.edl

What I figure is happening is that as soon as EyeTV finishes recording, the folder containing the recording gets renamed with .eyetv from .eyetvsched. The process that calls comskip changes directory there when starting, but I'm guessing comskip is getting lost. Is that what error code 103 might mean?

With livetv=1, since the .edl file is built while recording, even though I still get the error 103, all is well and commercials are marked.

This was not a problem with the old v 0.80 live detection, I don't believe, and EyeTV has always done the rename dance, which confuses me. Maybe it's added delay at the end.

Anyway, the error can be ignored but I do wonder if I could potentially be losing a final .edl entry that's not being written.

Jeff, could you do me a favor and check your logs for the 103 error and/or turn off livetv and see if marking fails?

Cheers

Error 103 means comskip was not able to write an output file.
The time between the finishing of the recording and the writing of the final output file has indeed increased.

OK, cool. Thanks. I can live with it but just in case there might be a workaround, here's how MarkCommercials calls com skip (from the logs):

Sun Nov 18 21:00:18 2012 - Changing directory to /Volumes/iB/EyeTV Archive/The Good Wife - Here Comes the Judge.eyetvsched
…
Sun Nov 18 21:00:18 2012 - Running: "/opt/local/bin/wine" "/Library/Application Support/ETVComskip/comskip/comskip.exe" --ini="/Library/Application Support/ETVComskip/comskip/comskip.ini" "000000001659f452.mpg" > /Users/me/Library/Logs/ETVComskip/374994002_comskip.log 2>&1 --verbose=10

So it appears to just be targeting the current working directory, which again, get's renamed before comskip has finished.

Cheers

One more question if I may. Most of the time live detection looks like this:

Wakeup after sleep [retries= 14, time= 0, size=3166]
1:00:28 - 110488 frames in 3604.91 sec(30.65 fps), 1.23 sec(27.64 fps), 0%
Sleep while reading [retries= 15, time= 0, size=1036]
Sleep while reading [retries= 14, time= 1, size=1036]
Wakeup after sleep [retries= 13, time= 0, size=3164]
1:00:30 - 110535 frames in 3607.20 sec(30.64 fps), 2.30 sec(20.43 fps), 0%
Sleep while reading [retries= 15, time= 0, size=1034]
Wakeup after sleep [retries= 14, time= 0, size=3165]
1:00:31 - 110590 frames in 3608.53 sec(30.65 fps), 1.32 sec(41.67 fps), 0%
Sleep while reading [retries= 15, time= 1, size=1035]

Is this optimal or possibly doing too much thrashing? Just wondering if playing with the new standoff parameters to sleep longer makes sense?

cpu load to generate these messages is about zero.
don't bother
I will remove them in one of the next builds anyway.