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

[Braklet]

Yeah, that's bad... time has stopped! Sub wouldn't have thought that could ever happen, so he didn't build in any check for that.


NPVR uses it's own filters to write transport stream files. NPVRTSWriter.ax and NPVRTSMon.ax are involved; both were updated in NPVR 3.1.1 and further in the R1 rollup.

Been a VERY long time since I had to look at a filter graph, but it sure sounds like I stumbled across a bug. Willing to extract whatever's necessary to help fix it. Guess we'll see what sub thinks after he gets back.

Also, my source is a Hauppauge HVR-2250, don't know about the drivers but I remember downloading the latest from Hauppauge when I installed the card, late 2009-ish.

[mvallevand]

That tweak which sub wrote just for me and my apparently screwball mainboard and it's slightly slow clock is only useful in a very special scenario which I hacked my way into. You could try setting the registry value and see if it changes anything though... it will change the clock source it uses to generate the timing.info data.

My gut says that this is somehow related to this change maybe XP related http://forums.nextpvr.com/showthread.php...post465912

If it was me I'd rename NPVRTSMon.ax and rerun the 3.1.1 installer to see if the original (that will be closer to older versions) works

Martin

[johnsonx42]

You're probably right, the first change sub made was to switch from using the GetTickCount() call to timeGetTime() (both of which get time from the up-time counter, but he though the newer timeGetTime() call was supposed to be higher resolution and more accurate). That had no effect on my situation, so then he made the change to getting the time from the system clock instead which he then made optional and controlled by the registry key. However I'll bet the original change to using the timeGetTime() call is still there, and that's what's not working for Braklet; it's either returning 0 or returning a non-zero time that never increments.

It can't be just XP vs. not XP though, because the R1 rollup has been downloaded over 2000 times, no way Braklet is the first XP user. It has to be something else about his system, maybe XP + something (or lack of particular update).

If this theory is correct, then undoubtedly setting HLKM\Software\NPVR\UseClockForTimingInfo=1 will fix the problem.

[Braklet]

You're probably right, the first change sub made was to switch from using the GetTickCount() call to timeGetTime() (both of which get time from the up-time counter, but he though the newer timeGetTime() call was supposed to be higher resolution and more accurate).

I just checked MSDN and both calls return the same effective time value (i.e. milliseconds since the system started). Microsoft's weasel-worded documentation implies that GetTickCount is less precise but both methods point back to "the system timer." What's more interesting in my case is that GetTickCount() is implemented in Kernel32.lib|dll while timeGetTime() is implemented in Winmm.lib|dll. I wonder if the MSI checks for a Winmm dependency on XP? Safe bet that my system has Kernel32 installed but perhaps not Winmm.

It can't be just XP vs. not XP though, because the R1 rollup has been downloaded over 2000 times, no way Braklet is the first XP user. It has to be something else about his system, maybe XP + something (or lack of particular update).

If this theory is correct, then undoubtedly setting HLKM\Software\NPVR\UseClockForTimingInfo=1 will fix the problem.

All automatic security updates are applied on my HTPC, but I can easily believe that I'm missing some optional library (Winmm?).

I'll give the registry change a shot, but I am out of town and won't be able to try until Sun or Mon. Don't want to tweak the system remotely since I have recordings scheduled and don't want to mess them up.

Thanks for the ideas, guys.

[johnsonx42]

Maybe winmm.dll comes with some windows media player update? Media Player 9 is still listed as a pre-req on the wiki.

[Braklet]

Maybe winmm.dll comes with some windows media player update? Media Player 9 is still listed as a pre-req on the wiki.

WMP v9.00.00.4510 is on the system. Been using this since late 2006 with whatever version of GB-PVR was current at the time. I purposely stay far away from the bleeding edge, but felt it was time to dive into v3.1.1. Silly me.

The fun part is switching my traveling video collection to MPEG-4 and maintaining DirectShow compatibility on this old HTPC, but that's not NextPVR's problem.

Actually, I just checked and found winmm.dll in C:\WINDOWS\system32, version 5.1.2600.6160. So, it's not a missing library AFAIK. No idea why the TS filters are generating zero time values.

[johnsonx42]

Based on everything, I'm about 99% sure it's that new timeGetTime() call that's failing for you (or it returns an invalid but constant number). That part of NPVR operates at a level where it can't log errors (similar reason why the setting for the alternate time source has to be a registry setting and not config.xml). I wonder if you're getting anything in the System or Application event logs?

[mvallevand]

So, it's not a missing library AFAIK. No idea why the TS filters are generating zero time values.

I thought you posted that analog files did have the timing, so it seems it is more how NextPVR was doing things now, which is why I said try with the original 3.1.1 ts writer.

Martin

[Braklet]

I thought you posted that analog files did have the timing, so it seems it is more how NextPVR was doing things now, which is why I said try with the original 3.1.1 ts writer.

Very true, analog recordings had decent looking timing but digital does not. Is it possible to extract the TS filters from the 3.1.1 MSI directly, without going through the reinstall? No big deal if I have to wipe the directory & start over again, just looking for a shortcut.

[johnsonx42]

I thought you posted that analog files did have the timing, so it seems it is more how NextPVR was doing things now, which is why I said try with the original 3.1.1 ts writer.

When sub first made these changes for digital, he updated NPVRTSMon.ax. When I later asked for the same change for analog, he updated NPVRWriter.ax. I don't know the exact internal machinations, but I suspect that only the digital path is using timeGetTime(), while he had no reason to make that particular change when he did the analog side so that's probably still using GetTickCount(). Thus digital is broken for Braklet, while analog works as before.

I believe you're correct that using the original 3.1.1 NPVRTSMon.ax would make it work, but I think he's better off temporarily setting HLKM\Software\NPVR\UseClockForTimingInfo=1 than messing around going backrev on one file.

Ultimately the solution will depend on what sub wants to do with it... if he thinks timeGetTime() is a better call to use going forward then it will be on Braklet to sort out why his system doesn't execute that call correctly when everyone else's system does. If sub is just as happy to go back to using GetTickCount() which always worked before, then he'll post a patch which I'll immediately include in an "R1a" patch .zip just in case anyone else might have the same issue.