So, I've heard that nforce board clocks can drift, but do they drift backwards?

I got up this morning, and, as usual, obsessively checked the listings only to find NO DATA for each channel. Checking the backend status page revealed some pgms scheduled to record, mythfilldatabase claimed to have 820 days of data available!

It turns out, that my master backend's system clock had reset itself back to 01/01/2003. I don't know why. I didn't manually set it there, and I've been relying on occasional resets with ntpdate to reset the clock so didn't have ntpd running or anything.

Anyhow, fixing the clock and re-running mythfilldatabase seems to have fixed everything up here.

Amy

I do believe TJC has posted a fix for the drifiting. Having an nforce myself, I have not seen this issue.

_________________
cesman

When the source is open, the possibilities are endless!

The normal drift is forward caused by extra clock interupts from the APIC or IOAPIC in certain specific Nforce2 chipsets. This is according to info sent to the Linux kernel mailing lists by someone at Nvidia. I've posted a link to it somewhere around here...

Jumping backward I've never heard of...

I just went through this as well. Here's the fix:

Edit /etc/lilo.conf
Find the "append" line and add " noapic noioapic"
Save, run lilo, and reboot.

That did it for me.

Here's the code for mine:


Then I did a:


And then rebooted. Unfortunately, it's still running too fast.

_________________
Retired KM user (R4 - R6.04); friend to LH users.

The "noapic noioapic" work around is only relevant for one very specific Nforce2 chipset bug: http://www.ussg.iu.edu/hypermail/linux/kernel/0410.1/1505.html
For clock drift caused by other issues you're probably just spinning your wheels...

Darn.. I do have an nforce2 chipset and had my fingers crossed that was the issue. Thanks for the info.

...any other ideas for causes of the drift? It's always 2-5 minutes fast after a shutdown.

_________________
Retired KM user (R4 - R6.04); friend to LH users.

I had this same problem too. What I did is just setup a cron job to kick off ntpdate program. It it is really bad you can set it up to even check every hour or whatever, I have mine kick off once a day.

_________________
ASUS A7N266 Micro-ATX Motherboard
Athlon 2200 processor
512K Kingston PC2100 Memory
MicroAtx Case
2 PVR250's w/remote
eVGA e-GeForce mx4000 (64 Ram with Tv/Out (Svideo))
Lite-on DVD cd-rw combo
120 GB Western Digital

Yeah, I followed these instructions on the wiki (quoted relevent scetion below) for doing so and the problem is not an issue... still doesn't explain what's going on - damn nforce 2 chipset

_________________
Retired KM user (R4 - R6.04); friend to LH users.

I'm now also noticing the problem with my nForce2-based motherboard on my master backend machine (Chaintech 7NIF2).

I tried the "noapic noioapic" lilo fix, which worked great for my other nForce-2 based machine (Shuttle SN41G2 as a remote frontend, no capture cards).

Doing this to my master backend, though, apparently killed one or all of my capture cards (I forget which ones stopped working; I did this a while back). Getting rid of the options, re-running lilo, and rebooting, brought back my capture cards. Mysteriously, the clock drift went away too, so I thought all was well.

Yesterday I rebooted my master backend after adjusting some sshd config files, and clock drift is back in a big way (about 30 seconds over the past 3-4 hours). So maybe the problem has always been there, and only showed up randomly after a reboot.

I'll try the BIOS setting referred to in the link that tjc posted and see if that helps.

The clock on my nforce2 board is also a bit fast. A strange thing happened last weekend...I rebooted the machine for some reason and realized the clock was drifting WAY fast. It gained almost 24 hours in a 12 hour period. I'm not sure what happened. I went back into the bios and set the hardware clock to GMT because it was set to local time and I realized /etc/default/rcS had it set for GMT (UTC=yes). After booting it seemed to settle down with the normal slight forward drift but I'm not convinced the hardware clock was the problem since it had been working before. I have no idea what happened. Anyway, I ended up setting up chronyd to keep the clock in sync and it has been working great since.

I tried the line
append="splash=silent apm=power-off nomce noapic noioapic"
in my lilo.conf but it made no difference.

I checked my clock and it is accurate to the second, so my clock isn't drifting off either, yet myth still claims to be xxx behind realtime when it isn't. It means that if you ever press forward you jump to the xxx + jump point in time which is never actually where you intended to jump to.

E.G If Myth claims to be say 30 seconds behind (when in reality it is 0 seconds behind) and you press a button to jump forwards 10 seconds you will in fact end up 20 seconds behind realtime so effectively have jumped BACK 20 seconds. At least at that point when it says you are 20 seconds behind you will be!

Hehehehehehehehehe... This wouldn't be when you're watching live TV would it? Ever read something while someone else was writing it? They have to get it down and move their hand before you can read it. Which means that you as the reader are ALWAYS slightly behind reatime... Right about now you should have one of these floating over your head...

Thanks, I needed a good laugh...

Huh? I don't think you understood my post. My issue is that Myth claims to be about 30secs per hour behind realtime. It continually drifts back and back so after 6 hours of live tv it will claim to be 3 minutes behind. It is of course in reality, actually only the usual 3 or so seconds behind. It is not an issue until you try and jump +/- when it will offset from that false postion to get the new position.

EG If myth thinks it is 3 mins behind but is really only 3 secs behind, and I do a -10sec jump (action replay) myth will jump you back not to -13 secs as it should but to 3:10 behind as it offsets -10 secs from -3 mins behind. Giving quite a long 3 min action replay!

HappyTalk - you're not using a PAL PVR350 TVout are you? If so then maybe this is your problem:
http://mysettopbox.tv/phpBB2/viewtopic.php?t=9132

_________________
HP VL400 (PIII 866), Skystar2 2.6D, PVR350, Nvidia FX5200, 384MB, 200GB, KnoppMyth R5.5