Sub, could you take another look at your code here? I've found that all skips are still off by about 3 seconds. 10 second skips go 13, 1 minute skips go 1:03. By itself this wouldn't really be an issue, except that all comskip skip points are also 3 seconds early. So every comskip occurs abruptly and cuts off the last half-line of dialogue before the commercial break. The end-point of the comskips are fine, it's just the beginning points that are early.
Everything I'm seeing is consistent with what you already described, that "it was a case of misreported current playback location" - it always seems to think it's 3 seconds ahead of where it really is.
server: NextPVR 5.0.7/Win10 2004/64-bit/AMD A6-7400k/hvr-2250 & hvr-1250/Winegard Flatwave antenna/Schedules Direct main client: NextPVR 5.0.7 Desktop Client; LG 50UH5500 WebOS 3.0 TV
johnsonx42 Wrote:Sub, could you take another look at your code here? I've found that all skips are still off by about 3 seconds. 10 second skips go 13, 1 minute skips go 1:03. By itself this wouldn't really be an issue, except that all comskip skip points are also 3 seconds early. So every comskip occurs abruptly and cuts off the last half-line of dialogue before the commercial break. The end-point of the comskips are fine, it's just the beginning points that are early.
Everything I'm seeing is consistent with what you already described, that "it was a case of misreported current playback location" - it always seems to think it's 3 seconds ahead of where it really is.
I'v also noted that Comskip skips a bit early and resumes a bit early too.
"I'd rather have a bottle in front of me than a frontal lobotomy"
johnsonx42 Wrote:There was a time when NPVR would do comskip jumps so precisely they sometimes looked like professional edits.
I can remember that too I'v tried tweaking comskips settings but it doesn't get any better, looks like the whole skip is moved some seconds.
I think you guys were either imagining it, or you just happened to get luck with the recordings you were using. Prior to the patch on the last page, the playback position was just a guess, and definitely not always right. Its now pretty much dead on, since its using the timing.info to lookup the current playback position.
I can probably give you a patch to allow you to specify some comskip offset or something similar, which would allow you to tweak it a bit. This way you could specify a one/two/three seconds (or whatever) offset from the times comskip would normally jump. You'd have to decide whether it'd apply to start+end times, or just start times - you two seem to disagree on this.
sub Wrote:I think you guys were either imagining it, or you just happened to get luck with the recordings you were using. Prior to the patch on the last page, the playback position was just a guess, and definitely not always right. Its now pretty much dead on, since its using the timing.info to lookup the current playback position.
I can probably give you a patch to allow you to specify some comskip offset or something similar, which would allow you to tweak it a bit. This way you could specify a one/two/three seconds (or whatever) offset from the times comskip would normally jump. You'd have to decide whether it'd apply to start+end times, or just start times - you two seem to disagree on this.
When I say that I remebmer comskip beeing accurate, it was way back in gbpvr days and with .mpg recordings...
A patch to adjust the skip would be welcome, it's worth a try.
"I'd rather have a bottle in front of me than a frontal lobotomy"
The patch in this thread vastly improved matters over the stock 1.5.36 behaviour. However skips were definitely much more accurate with prior versions; 1.5.28 introduced the Timing.Info, and a couple of patches early after the release made it work right. Since then, 10 second skips have always been 10 seconds, and 60 second skips have always been 60 seconds. Comskip skip points have been more accurate since then as well. Now with 1.5.36+patch forward skips are 2 to 3 seconds too long, and comskip jumps are 2 to 3 seconds too early. I'm definitely not imagining this.
That all said, with GB-PVR I had wished for the ability to tweak comskip jump points so such a feature would be welcome. There do seem to be slight variances among different systems, decoders, etc. that can throw off the apparent skip points a little bit. A half-second could be the difference between a skip that looks abrupt and accidental vs a skip that looks smooth and planned.
server: NextPVR 5.0.7/Win10 2004/64-bit/AMD A6-7400k/hvr-2250 & hvr-1250/Winegard Flatwave antenna/Schedules Direct main client: NextPVR 5.0.7 Desktop Client; LG 50UH5500 WebOS 3.0 TV