skipping fouled up again

[sub]

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.

I think we'll just have to agree to disagree on that one. I really think you're wrong. The old scheme would just guess the current playback time based on the duration from timing.info, and could get it way wrong for variable bitrate files, or if their was glitches in the recording (causing the average bitrate to not consistent over the entire file). The new scheme uses the info in timing.info to determine the playback position.

That all said, with GB-PVR I had wished for the ability to tweak comskip jump points so such a feature would be welcome.

I've attached a patch that'll allow you to tweak the comskip start and end times by adding the following in the config.xml's <General> section

<ComskipStartOffset>-3000</ComskipStartOffset>
<ComskipEndOffset>-3000</ComskipEndOffset>

You can use negative or positive values.

[sub]

If you want, you can see if this helps. This test version puts it back to guessing the position based on the duration from timing.info. (there is only six lines of code different between old method and new method)

[johnsonx42]

Thanks sub, I'll give these a try a little later today.

[johnsonx42]

No, the test Unmanaged.dll is no good. That breaks skipping at least as bad as, if not worse, than it was with the 1.5.36 released version; 10-second forward skips go anywhere from 10 seconds forward to 10 seconds backwards, or nowhere at all. It's probably bad form to argue with the guy writing the code, but you've forgotten about something somewhere along the way.

I'm not disagreeing with the method being used to determine position - with the original patch in this thread, it seems to determine position very precisely, but accuracy is off by 2 to 3 seconds (I'm recalling the scientific definitions of accuracy and precision). It's always off by the same amount, whether it's near the beginning of the file or near the end.

Now given that the precision is ok and it's only the accuracy that's suffering, the new Comskip Offset feature will help. But it will be just covering up for the error elsewhere.

[johnsonx42]

by the way, it's the patches in this thread: http://forums.nextpvr.com/showthread.php...recordings which initially made skipping with Timing.Info work just right. I think perhaps you lost some code change somewhere along the way, as every time after that you made any change to fix the 12:48 resume issue, it would break skipping back to the way it was prior to the 1.5.28 patches in that thread.

[johnsonx42]

I've found these settings work pretty well for me:

Code:

<ComskipStartOffset>3000</ComskipStartOffset>
    <ComskipEndOffset>750</ComskipEndOffset>

Thanks sub for the new feature. Regardless of why I need a 3000ms offset, the ability to set an offset at both ends in both directions is a valuable feature that will be appreciated by all comskip users.

[#66]

I found the the skipping erratic at times. I have the patch and it did improve, however I still get some odd behavior. Large skips freezes the picture for about 7 secs, and short skips back goes forward!

[johnsonx42]

I found the the skipping erratic at times. I have the patch and it did improve, however I still get some odd behavior. Large skips freezes the picture for about 7 secs, and short skips back goes forward!

Which patch did you install? the only one I can think of that would cause that problem is the one in post #22, which you should not be using.

[jksmurf]

I had some weird things going on too.

When I started the timeline showed negative.
When I pressed forward I got some big steps backward.
All the cuts looked OK, but were all offset by about the length of the ad break.

On the PC, when I rebooted later, the comskip cuts were all perfect??

k.

[mvallevand]

This sounds a lot like problems I have seen and had to correct for on the NMT when resuming and com skip at the beginning of file cause NPVR to think that the first reported second was the actual first second.

Martin