Commercial detection - Thread count vs. priority

The current approach of limiting CPU usage of comskip by restricting the number of threads is inefficient as it can result in resource underutilization and in some cases over-utilization when the user kicks in jobs manually. The mechanism to limit CPU usage by process has been available in unix kernels for quite some time:

nice (Unix) - Wikipedia

tldr; instead of executing

$ comskip foo bar baz

the job should be started as

$ nice comskip foo bar baz

Alternatively the option asking comskip to play nice could be used

$ ./comskip -h
-n, --playnice                  Slows detection down

It might be a good idea to put the priority of jobs started manually from the GUI lower than jobs started at the end of the recording, so:

$ nice -n 10 # for DVR
$ nice -n 19 # for manual jobs

It would make killing the box running DVR a little bit harder.

The developers give you control by allowing you to use an override comskip.ini file with the settings you want.
You can even use the simple comskip.ini editor to tune it for yourself.

And in case you didn't know. All comskip jobs are run from a sequental FIFO queue since the v2021.02.09.0017 pre-release.

It is really hard to come with one size fits all in these scenarios. It is better to let the kernel scheduler do its job and simply run with lower priority. No tweaking necessary.

To make sure comskip runs with lower priority I moved it to and put this into comskip

exec nice -n 19 ../latest/ "[email protected]"

Now more CPUs can be added to commercial detection without any interference with the rest of the system. Faster commercial detection when the system is idle. comskip.ini tweakers will be super disappointed :wink:

This script takes care of everything if run from channels-dvr directory after each upgrade: -

Enabling 4 threads on RPi

$ curl -X PUT ; echo