comskip has encountered an error

[dennit]

I've been trying comskip, and wonder if anyone has seen this:

Comskip works for all the dvr-ms files I've created from my HVR-1600 off qam-256 cable, with one exception. All of the files recorded from one channel - a 480i channel - crash comskip with the Windows error message that Comskip.exe has encountered an error and needs to close. Oddly, this is a channel that has no commercials, but so far, every recording causes the crash. The popup crash window is annoying. The crash happens on a manual run too, and it always crashes in the log after creating this line:

AC3 sound at 48 khz
and after creating an empty .txt file

If run in debug, I see some video in the window, then the crash occurs.

If I can't fix this, is there a way to just tell GBPVR not to run for this one channel?
GBPVR v1.2.13
comskip79_140
Thanks!

[sub]

I'm sure erik will be able to find a fix for you, but you'll probably need to supply him a sample file. To make sure he is aware of it, try posting the question on his comskip forums here: http://www.kaashoek.com/comskip/index.php

[erik]

Would be nice if you could provide me with a 50 to 100MByte recording that causes Comskip to crash
Will PM you for the upload details

[dennit]

Would be nice if you could provide me with a 50 to 100MByte recording that causes Comskip to crash
Will PM you for the upload details

Wow, you guys are fast. I've got the upload details (thanks erik) and I'll PM when I send something.

I found the postprocessing.bat file with per channel customization, so I can resolve this as far as my own needs, by just stopping processing for the one channel. I'm testing that now, along with new version 141. (As a new user, there's a lot to absorb for GBPVR with all the options and great plugins)

Just to be clear, I was running the default postprocessing.bat file in my GBPVR dir. If I understand it correctly, I didn't have to do this, and if I hadn't, it would have processed anyway? I've modified postprocessing to skip the offending channel.

(I've been playing with the comskip GUI - it's cool the way it finds various criteria to identify the commercials)

I'm happy to forward this, but let me play a bit until I'm sure I know what's happening, then if it still looks like an issue for comskip, I'll cut a piece that shows the error and upload it.

[erik]

Just to be clear, I was running the default postprocessing.bat file in my GBPVR dir. If I understand it correctly, I didn't have to do this, and if I hadn't, it would have processed anyway?

Indeed, without the postprocessing,ab gbpvr will run comskip on all recordings (when enabled). With postprocessing.bat you can make per channel customizations or add other processing.

[dennit]

Indeed, without the postprocessing,ab gbpvr will run comskip on all recordings (when enabled). With postprocessing.bat you can make per channel customizations or add other processing.

Thanks.

I've got a 160 MB snippet that crashes. I'm trying to up it now, but it's slow - not sure if it's me or the net. A smaller snippet doesn't finish processing, but also doesn't crash in the same way - I tried a 6 minute 106MB snippet and a 3 minute.

[erik]

I may need more time to find the problem then it takes you to do the upload

[erik]

And indeed, thanks for the upload, its a memory corruption bug, will take some time to find and solve, wish me luck

[dennit]

And indeed, thanks for the upload, its a memory corruption bug, will take some time to find and solve, wish me luck

It seems odd to me that all the recordings from this one channel and only this one are causing a crash. Clearly you are more familiar with what goes on with comskip than I am, but at the surface level, you wouldn't think the data streams from different channels would be all that different.

Good luck, and if it turns out to be an interesting bug, tell us the story after you track it down and squash it!

BTW, it was me that was slow - turned out I had something crashed, but running in the background eating all my bandwidth.

[erik]

Specific for this stream is the initial assumption that the audio is MPEG2, later there is a switch to AC3 decoding.
I assume its in the automatic audio detection that things are going wrong.
It takes way to long before the switch to AC3 is made.
No need to look at other channels as the audio muxing is often channel specific.