Yeah, that's becoming very apparent.
1 Like
If live commercial detection and concurrent commercial detection processes are required for your use-case, then Channels is not the software for you.
However, I do know that MythTV—and I believe SageTV, too—offers both of those features. Also, both of those services are free, only requiring a cost for your guide data, which can be had for $25/yr from Schedules Direct, which also provides Gracenote data so the quality of the guide info would be the same, for nearly 1/4 of the cost. Clients/frontends (including remote access) and developer response, however, are not nearly as good as Channels.
(Tvheadend also allows for concurrent commercial detection, but they do not offer live commercial detection.)
Just curious what your expectations were for Channels DVR to replace SageTV and why you jumped.
It replaced TiVos and PLEX DVR for me. But I knew what it offered before I jumped.
Okay. Thanks.
I haven't 'jumped.' I'm running them side by side. I researched it a bit before going in, but I was expecting it to have basic file operations already in place ... like being able to realize that a recording is missing (or deleted externally). My mistake.
Are you referring to the developer response to simple questions like this one, where I asked if there were directions to move a DVR server from one pc to another?
Fortunately someone else asked the question and got some response. Thanks.
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" 
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.