Comskip crashing while processing live recordings

[btracy]

Single recordings still crash for me as expected so now to just capture one and the file size (hopefully I can stop the recording quickly as well).

@htpcthor My understanding of the Wait Time parameter was how long to wait after a file stops being updated. The hover over help says, "Amount of time to wait for a file to stop being written to". If it really does wait for x amount of time to start work then that would be excellent. I hadn't found way to make the delay otherwise (but I have not looked all that hard either).

[htpcthor]

I think I have found a solution for now. I put a sleep command at the top of the 'Find Commercials In DVRMS' profile and set it for 5 minutes. The last 4 shows have worked correctly.

[btracy]

Nice find. I will set that up after I try to get the size of the file on crash.

[joesc1]

I'm still having crashes several times a day, even after I set DirMon to ignore files smaller than 100MB and to wait 5 minutes between runs.

[htpcthor]

I haven't had any crashes since I put the 5 minute delay in 3 days ago (18 successful scans). Before that 3 out of 4 would crash. So the delay definitely worked for me.

[erik]

The 5 minutes will depend on the type of recording.
Example: HD recordings may need less waiting time then SD recordings.
Try 10 minutes

[btracy]

Ok I finally got a chance to sit and watch a crash. It was right around the two minute mark and the size of the file on crash was 283,115,520 bytes. I probably stopped the recording 3 seconds after the crash. I tried running comskip on this same file multiple times but it won't crash (as expected really since it is no longer live tv).

I will implement the 5 minute delay and see how that goes for me.

[haggis663]

I am also only getting Comskip frequently (but not always i.e. 75%) crashing while analysing live TV (it works on purely recorded)
The event log has the following error:
Faulting application name: comskip.exe, version: 0.0.0.0, time stamp:
0x4fb8bf71
Faulting module name: comskip.exe, version: 0.0.0.0, time stamp:
0x4fb8bf71
Exception code: 0xc0000005
Fault offset: 0x000dbbf5
Faulting process id: 0xe7c8
Faulting application start time: 0x01cd5dc538eb38fe Faulting application path: C:\Program Files (x86)\DVRMSToolbox\Applications\comskip.exe
Faulting module path: C:\Program Files
(x86)\DVRMSToolbox\Applications\comskip.exe
Report Id: a1c771d4-c9b8-11e1-a1f4-002522bf8d04

The log ends suddenly while scanning:
Output: 0 - start: 1820 end: 2084
start: 1818, end: 2069, len: 10.04s
start: 1818, end: 2069, len: 10s
Output: 0 - start: 1820 end: 2084
start: 1818, end: 2069, len: 10.04s
start: 1818, end: 2069, len: 10s
Output: 0 - start: 1820 end: 2084

[btracy]

That looks like the same crash as I see. Delaying the start of the scan by 5 minutes or so should prevent it for now.

[haggis663]

Delaying by 5 minutes doesn't seem to solve all the crashes for me.

[erik]

Also set
thread_count=1
in your ini file

[haggis663]

With both the startup delay & the thread count, I am still getting occasional crashes.

I have traced this down to only occur if I have multiple recordings occuring at the same time. (If there is only one recording, then comskip seems to be now stable).

I can only assume that having multiple comskips going on at the same time interfere with each other (shared memory?).

I hope this helps.

[btracy]

Although I have multiple recordings going on at once (for example 3 tonight) I have not seen a crash since setting a 5 minute delay and having the thread count at 1. I could previously reproduce a crash with just one recording at a time when starting the scan with no delay. The error is an access violation though and it was easier to reproduce crashes when more than one comskip was running at a time. Have you tried a longer delay (say 10 minutes) just for a sanity check to see if the crashes still occur? If so, your issue sounds a bit different than my own.

[Deihmos]

It looks like it also crashes for me. No skips were processed. I don't see anything in the ini about thread_count. I think I am better off disabling live_tv.

[btracy]

The thread_count value has a default of 2 and isn't in the default .ini file so you would have to add it. The crash isn't limited to having the live_tv value set (for me at least). The live_tv value just allows the .xml file to be written during scanning instead of at the very end. In my tests, it crashed with live_tv set to both 0 and 1 if processing starts early in the recording cycle. You may be better off going back to not scanning at all until the recording has stopped or implement a 5 minute delay before start.