Can't Skip After v2.5.9->3.1.1 Upgrade

[sub]

I know what the problem is, and that patch should have fixed it.

You don't need that registry setting. It's preferable that you don't have it, since it has the potential to lead to other problems.

I've attached a version of that patch which adds some logging. If this patch doesn't work for you, create a c:\temp directory, and set HKEY_LOCAL_MACHINE\Software\NPVR\LogTSWriter=1 (DWORD), then do a recording and post the c:\temp\writer-xx.txt file.

[Braklet]

I know what the problem is, and that patch should have fixed it.

Here's what I did: removed the old timing registry item, extracted your latest patch, overwrote the AX filter, added the new logging registry item, restarted the recording service, and recorded a couple minutes of ATSC from the same test channel. This time I saw good Timing.info:

Code:

0,0
891,1425416
1766,2850832
2641,4192400
3547,5701664
4406,7127080
5266,8468648
6141,9894064
7016,11319480
7906,12744896
8797,14170312
9672,15595728
10531,16937296
11391,18362712

I attached the log file this latest patch created. Should I leave logging enabled for more data collection?

As always, thanks for your support!

[sub]

Should I leave logging enabled for more data collection?

No, since it's now working, I'd remove that registry setting.

[Braklet]

No, since it's now working, I'd remove that registry setting.

Will do (actually just set it to 0, seems to have same effect). Let's ass-u-me this takes care of my Skip problem, if not I'll post here again.

Thanks again!

[johnsonx42]

sub, I assume you went back to using GetTickCount(), or was it a different issue?

[sub]

I just made a mistake in a fallback logic for XP machines, which didn't support the GetTickCount64 API the app prefers to use. It was supposed to fall back to using GetTickCount() on XP, but due to a way I initialised a flag, it didn't.

[johnsonx42]

got it. So it was something that would have failed on all XP machines.... really surprising then that Braklet was the first to encounter it. Must be precious few XP users left.

[mvallevand]

got it. So it was something that would have failed on all XP machines.... really surprising then that Braklet was the first to encounter it. Must be precious few XP users left.

Or simply the didn't need the patch and until R1 most people probably would have ignored it. The only person that I know of that really needed this patch was you.

Martin

[Braklet]

Just skipped fwd/back in an in-progress recording on the problematic ATSC channel. I think that knocked it out, sub.

johnsonx42, if you're still rolling updates, use the patch in post 41.

Thanks again to everyone for the help.

[johnsonx42]

Or simply the didn't need the patch and until R1 most people probably would have ignored it. The only person that I know of that really needed this patch was you.

Agreed, that particular patch was downloaded by very few people as an individual patch... the alternate clock source is pointless unless you have the exact problem I do AND you're working around it by forcibly re-syncing your clock every five minutes; can't imagine there's anyone else who would benefit from it.

Still, I posted R1 2-1/2 weeks ago, and it's been downloaded over 2000 times. Apparently every XP user who installed the update and didn't set the registry key for the alternate clock source (why would they?) would have had this problem. Yet no one else has reported anything like this that I've noticed.

I'm going to bed now, but will post an R1a update with this patch tomorrow.