timing.info too short, timeline inaccurate

[mvallevand]

If your system clock was drifting you should expect the recording would be cut short too.

Martin

[johnsonx42]

If your system clock was drifting you should expect the recording would be cut short too.

exactly.

All windows systems seem to have some time drift problems, but it isn't really noticeable on a desktop PC since windows syncs the time each week. On the HTPC box though if I drifted out 30 seconds after a week, that'd mean the beginning of shows would be cut off. I finally solved the problem by scheduling a "w32time /resync" command every 5 minutes in the task scheduler. At most my time drifts a second or two before it's brought back to perfect sync.

UNLESS.... is the time source that NPVR uses to write the timing.info connected to the system time which I am syncing to an external time source, or is it an internal time counter unaffected by time sync?

[sub]

UNLESS.... is the time source that NPVR uses to write the timing.info connected to the system time which I am syncing to an external time source, or is it an internal time counter unaffected by time sync?

To be honest, I'm not sure. It depends how it works behind the scenes.

I'm using a Windows API that returns the uptime of the machine milliseconds. Initially I was using GetTickCount(), but the most recent patch switch to timeGetTime()

[imilne]

UNLESS.... is the time source that NPVR uses to write the timing.info connected to the system time which I am syncing to an external time source, or is it an internal time counter unaffected by time sync?

I'm just guessing, but these methods usually just give you the time in milliseconds since 1970, so it probably is linked to the system clock.

Iain

[johnsonx42]

UNLESS.... is the time source that NPVR uses to write the timing.info connected to the system time which I am syncing to an external time source, or is it an internal time counter unaffected by time sync?

I think this has to be it. I turned off my timesync task and ran a 30 minute recording. The timeline shows 29:29, pretty much exactly what it should. However if I run writeTime against the recording, the resulting timeline is longer, 30:03.

So this means whatever clock source NPVR uses to write the Timing.Info is slow by about 5-6 seconds per 30 minutes. If I force the time to sync, then the recordings have the right length because NPVR itself is governed by the clock that I'm syncing, but the written Timing.Info is short. If I let the time drift, then the system clock and Timing.Info will agree, but the recording itself will actually be longer.

[johnsonx42]

I'm using a Windows API that returns the uptime of the machine milliseconds. Initially I was using GetTickCount(), but the most recent patch switch to timeGetTime()

It makes sense that GetTickCount() would use an internal counter not affected by timesync, but you'd think timeGetTime() would be slaved to the system clock. However it seems pretty clear from my tests that clock drift is causing my problem. My 'new' system must have a pretty bad clock generator. I wonder if it's the hardware itself, or something in the BIOS?

[sub]

It makes sense that GetTickCount() would use an internal counter not affected by timesync, but you'd think timeGetTime() would be slaved to the system clock.

They both return the system up-time in milliseconds though, so "timeGetTime" name might be a bit deceptive.

[johnsonx42]

They both return the system up-time in milliseconds though, so "timeGetTime" name might be a bit deceptive.

do you have a call available that would return the system time in ms that you could use?

[mvallevand]

Windows timers etc all depend on a reliable RTC, you should fix your motherboard, and not go for a hack. I suspect that it will impact decoders skipping etc too.

Martin

[johnsonx42]

I may indeed need to replace my mainboard ultimately (I doubt there's anything to fix), but it doesn't seem like using system time to generate the timing.info should be any different in net effect than using the uptime (so neither method in NPVR is more a hack than the other... it just so happens one of them would work better with my hack of forcing time sync every 5 minutes). I agree that having the clock running slow may have other odd effects, but so far this is the only one. Everything else about this system runs just perfectly.