Comskip tuning

No. I was specifically referring to how responsive the developers are to responding to reported bugs and other types of things of a technical nature. While Channels' documentation is quite spartan, the developers more frequently than not answer questions. Also, feature requests that would languish with other DVR packages, I have seen quite a bit more activity from these developers.

Of course, you are welcome to your own opinions and observations. I also believe that you should only use/purchase software based upon what it does now, rather than an promised or expected future feature. So, evaluate for what you can do now, and then make your decision; but remember to keep your expectations confined to current features, if that's the case.

No.

But thanks for your opinion.

As I said, you're welcome to your opinion. But paying for something that may never exist seems a bit foolhardy.

For proof in a like circumstance, you only have to look to SiliconDust's nearly 5-year overdue promise to deliver the DRM Copy-Once CableCARD recording that was promised with their DVR Kickstarter that still has yet to materialize.

You would not be happy in the TESLA CAR Group and the FSD "Future Option" :slight_smile:

I copied one of the CDVR comskip.ini files from the LOG directory into the program data directory, and modified the thread count to 4. I started the CDVR software, and because I can't determine a way to do a quick timed recording, I waited until a few minutes before the hour and set (3) shows to record to the end of the hour.

The shows recorded, and when the first show started commercial detection, comskip.exe processor usage hovered right around 86% (on a quad core system without hyperthreading). It processed in just seconds. When the second and third show started their comskip process, consecutively, the process usage never went above 5%.

Is there a way to resolve this?

Strange. I've never tried more than 3 on my non-hyperthreading quad-cores.
I get about 50% cpu usage on my quad-core running with thread_count=2.

Maybe try with 3 instead.

According to the docs that come with comskip...
thread_count=2 (1-16)
;Number of threads used when decoding the video
;;Increasing the thread count speeds up the processing on CPU's with more cores then the current thread count. Setting the number to higher then the amount of cores makes processing slower. Setting the thread_count to 1 disables multi-threaded decoding, useful in case comskip crashes when decoding the video.

I'll give it a shot.

Wasn't there also some kind of a "play nice" setting that further slowed comskip so that other processes weren't affected? I'm not sure what all we can include in our manually created comskip.ini file that won't be overridden by whatever CDVR forces.

When you create an override comskip.ini in your data directory, it has to be the complete ini file as it overrides ChDVR's default ini file. So your override comskip.ini gets used instead and will never be overwritten.

You can find docuentation for comskip here https://www.comskip.org/

Nope. Changing it to 3 threads did not work, it's still running very slowly (0 to 5% overall CPU). It's strange how it works fine on the first recording it processes, then apparently reverts to some other ini file for instruction.

I tried a complete ini file the very first time, and it would not use any of it.

Do you know when CDVR fetches the comskip.ini file? If the software is idle, do I still need to shut down CDVR completely to modify the comskip.ini file?

On my system (Synology NAS) it accesses it each time it runs comskip.

You can check the comskip.ini in the new log directories to see if they contain what you expect for the test recordings you made.

Okay, I see it in the video.log file in the log directory.

Right, there is no comskip.ini being copied to the log directory if you have an override comskip.ini in the data directory. If you rename your override comskip.ini file in the data directory to comskip.bak, then run a comskip, ChDVR will copy its default comskip.ini to the log directory.

Using a full comskip.ini in the data directory seems to be working now with 2 or 3 threads. Not sure what I did differently. I thought it may have something to do with recording to a network share on another computer, but no, that wasn't it.

This all sounds suspiciously like you are limited by how quickly comskip is reading the content off of the disk. Movie files are big and need a lot of disk bandwidth to read quickly. If you're running this off of a network share, it's very likely you'll be running into the limitations of your network.

For instance, if you have a 1 hour TV show recorded off of a HDHomerun that is 6.7GB, if you had a very stable 1 gigabit/second network connection (which can send around 100 megabytes per second), it would take 71 seconds to just transfer it over the network (with no processing). If you only had a 100 megabit/second network connection, it would take almost 12 minutes just for the transfer.

Check on your disk IO statistics and network IO statistics when running comskip to help identify what your bottleneck is.

The more complicated your environment is, the more chances you're going to have for a slow component making everything worse.

2019/11/10 13:33:32 [DVR] Running commercial detection on file 126 (TV\The Office\The Office S08E20 2012-04-12 Welcome Party 2019-11-10-1302.mpg)
2019/11/10 13:35:44 [DVR] Commercial detection finished with 8 markers.
2019/11/10 13:35:44 [DVR] Processing file-130: TV\Drug Wars\Drug Wars S03E08 2016-08-24 Furious Falfurrias 2019-11-10-1303.mpg
2019/11/10 13:35:46 [DVR] Running commercial detection on file 130 (TV\Drug Wars\Drug Wars S03E08 2016-08-24 Furious Falfurrias 2019-11-10-1303.mpg)
2019/11/10 13:37:39 [DVR] Commercial detection finished with 6 markers.
2019/11/10 13:37:39 [DVR] Processing file-129: TV\Jessie\Jessie S03E08 2014-01-10 Krumping and Crushing 2019-11-10-1303.mpg
2019/11/10 13:37:40 [DVR] Running commercial detection on file 129 (TV\Jessie\Jessie S03E08 2014-01-10 Krumping and Crushing 2019-11-10-1303.mpg)
2019/11/10 13:39:17 [DVR] Commercial detection finished with 6 markers.
2019/11/10 13:39:17 [DVR] Processing file-128: TV\Brooklyn Nine-Nine\Brooklyn Nine-Nine S04E21 2017-05-23 The Bank Job 2019-11-10-1302.mpg
2019/11/10 13:39:18 [DVR] Running commercial detection on file 128 (TV\Brooklyn Nine-Nine\Brooklyn Nine-Nine S04E21 2017-05-23 The Bank Job 2019-11-10-1302.mpg)
2019/11/10 13:41:36 [DVR] Commercial detection finished with 8 markers.

Not only am I running through a network, but it's a temporary condition where I'm running my entire office back to a main router via a powerline adapter, which is capable of about 25 megabytes per second (one way). That said, a couple minutes of comskip per 30 minute recording is decent for now.