This is what I use on SageTV ...
live_tv=1 ; set to 1 if you use parallelprocessing and need the output while recording
live_tv_retries=4 ; change to 16 when using live_tv in BTV, used for mpeg PS and TS
Does the comskip log in sagetv show mpeg2video and ac3 errors?
There are no mpeg errors in my SageTV comskip log file. It’s from the same SiliconDust HDHR source device.
I hope there is something found to fix this issue.
I have often found that the in-process commercial accuracy is MUCH worse than the post-process detection, but this is just my observation playing recordings and I have no log details.
1 Like
Any update on why the in-process commercial detection has timestamp drift?
Just chiming in to say I am also eagerly awaiting this fix... 
1 Like
As the Olympics approach, is there anything I can do to help identify the source of this problem?
It's Football season again.
@tmm1 what can be done to identify the source of this "time stamp drift" bug? I think we've ruled-out comskip being the issue.
Ugh, this "timestamp drift" bug is so annoying. Time after time I'll be watching a game and just as a big play is happening the automatic commercial skip kicks in 30 seconds early and completely ruins the moment.
The fact that such an intrusive bug has been allowed to persist for so long just seems so antithetical to the sublime user experience that Channels has always been about. @tmm1 @maddox, this has been a known issue for at least two years (!), will this ever be fixed?
I resolved this issue. I turned it off and use the remote.
My feeling is that the developers gave this a try due to popular demand yet a fix is beyond their control so they should pull the feature.
1 Like
Just to be clear, commercial detection is third-party software not developed by the Fancy Bits team. It has been around long before Channels. While the Channels developers do make contributions to that project, it is not theirs.
(Even before live detection was added as an option to Channels it was noted that it was far less accurate and offered a less-than-great experience. I personally lobbied against adding the feature because I knew from personal experience how poor it is with other DVRs. While the Channels devs have made additions that have improved commercial detection, live detection is still alpha-quality.)
This is more avoiding the the issue than resolving it, but I get your point.
I conducted numerous A/B tests with SageTV and Channels recording the same show at the same time and both doing the same in-process commercial detection with the same ComSkip settings. I provided all of the results and log files. Every indication is that this is not a ComSkip problem, but rather an issue with the Channels playback positions. In-process detection worked as expected with SageTV (it occasionally missed a commercial, but all of the skips that were detected happened at the correct start/stop points.)
I think reduced accuracy of in-process commercial detection is a separate issue. It should not be confused with this playback position drift issue. This isn't about ComSkip detecting or not detecting all the commercials. It's about Channels not accurately jumping to the correct timestamps for the commercials that ComSkip did accurately detect.
For reference, in-process detection for SageTV didn't detect every commercial, but for the commercials it did detect, the skips happened at the correct times. For Channels, it detected the same commercials, but the timestamps in the comskip file do not align with where Channels is skipping from/to during playback. The results should be the same between two different DVRs recording the same show, from the same source, using the same ComSkip library (missed commercials and all should be the same.) This is unfortunately not the case, because the issue isn't about commercial detection. This a separate time drift issue with Channels.
Three hours into a 4 hour recording, I deleted the in-process ComSkip files and started in-process Comskip detection over, which should make the first ~2:45 minutes of the recording the same as post-processed ComSkip. It detected all of the commercials correctly, but the playback of the in-process recording still had playback position drift. Each skip happened earlier and earlier than when it should have as playback progresses through the recording.
I can't tell if it's an issue with how the Channels Server writes incremental chunks to the recording file that makes reading timestamps error-prone or if it's a problem with not accurately tracking the current playback position, or something else. Regardless, it seems to clearly be a Channels issue, not a ComSkip issue.
8 Likes
This is not a commercial detection problem, but rather a commercial skipping one.
The commercial start and end points are correctly identified by comskip as evidenced by the darker color on the playback progress bar, but Channels somehow gets confused and starts progressively skipping earlier and earlier the longer the recording goes. It is an issue with Channels. Please see @ChannelSurfer's post above
PS Big thanks to @ChannelSurfer for all the work identifying and documenting this 
3 Likes
Sigh. Still no love.
1 Like
Yeah I don't understand why the devs are ignoring this. I've been around these forums for a long time and they have always seemed very user experience focused. Yet they ignore this bug that is pretty severe as far as debilitation of user experience goes 
I guess they don't get enough support requests to bother with this one. They obviously don't watch a lot of slightly time-shifted live sports like I do 
3 Likes
With so much content now being available via streaming, live sports is now the only thing I record with Channels.
Unfortunately they ignore a lot of stuff, like shows in the grid guide being 3-4 hours off if you scroll around it in Android. It makes the grid guide useless in that app, very basic and easy to replicate for anyone that would care.
I have given them a lot of credit for fixing issues that have been raised here by me and many others, but some of the easily replicated, common stuff like this that's seen by many doesn't even get acknowledged as worth a fix.
2 Likes
This is just a Community Discussion Forum where you can vent your gripes, but...
Acknowledgement of bug reports - General - Channels Community
1 Like
The problem, as always, is that certain stuff gets ack'ed here and a lot doesn't. Even if the users provide examples, how to replicate etc. as in this thread.
And there are plenty of reports that stuff sent to official support gets ignored. I've sent some stuff and got responses on some but not others.
My point being that official support and dev responses here seem to have similar results. Just an observation, not a slam, and yeah I know it's just a few folks that have to deal with it. I do give them all the credit for rapid response on the big issues, but there's a lot of chronic smaller stuff like this that never gets fixed or even ack'ed.
1 Like
March Madness is approaching - would be great to auto-skip those commercials to catch up to live.
1 Like