The clock runs slow in this image!!!

[105547111]

Has anyone noticed any problems with the clock and the 1.3 version?

By this I mean its the same TIVO motherboard, HDDs as I was using before, cachecard NOTHING hardware has changed! Reformatted and installed.

Before with the old 1.0, I had cron set the clock 7 days a week at midnight.

But during the day and night (furthest away from the time being set) recordings were spot on time. True I never checked the accuracy of the clock, but surely within 15 seconds per 24 hours my guess...

Now this version my recordings are starting late, same shows!!! and I mean late by over a minute and more!

I found the clock is now running slow, to the degree of approximately 15 seconds every 30 minutes!!! If I set the clock fixtivotime or fixtime.cron and type date, the clock matches my GPS time. I check it in 30 mins and its 15 seconds out!!!

I have cron now setting the clock every hour, but surely something is a miss.

Everything else is perfect, just the clock runs slow.

Can the clock speed be adjusted anywhere?

Thanks!

[DavidSymons]

Sorry no solution for you but there is a thread on the mailing list which could be related:

http://minnie.tuhs.org/pipermail/oztivo/2004-April/012351.html

Peter has two TiVo's losing time - around the same amount too. I understand that both of his run CacheCards (like yours). Could it be ... ?

Craig Curtin theorised that Peter's problem could be a software issue in this post:

http://minnie.tuhs.org/pipermail/oztivo/2004-April/012361.html

Perhaps see how it goes without the CacheCard drivers?

[105547111]

David,

Thanks a lot for your help I will have a play around and see. Failing that it is something easily fixed, how often could I safely set cron updating the clock?

I run my own NTP server on the network so it wont overload my server, but I dont want to overload tivo.

I will post the time info on cachecard support also seeing if its a bug.

Thanks!

[DavidSymons]

Hi.

Frequent NTP updates on a TiVo are outside my experience I'm afraid. Anyone else???

Even so I'd be surprised if your half hourly updates would overload it.

I'm running the 1.3 image and have a CacheCard on the way. Hence I'm very interested to hear how you go.

Cheers, Dave.

[tenty]

Hi.

Frequent NTP updates on a TiVo are outside my experience I'm afraid. Anyone else???
I'm about to fire up my computer and connect via ppp to the TiVo, so as soon as I have an answer, I'll post it.

Edit:
telnet into tivo and edit crontab. This can be done in this way:


telnet 192.168.1.51
rw
cd /hack/etc
vi crontab
G
i
59 23 * * * /bin/ntpdate server.ip.address.here
ESC ESC
:wq
sync
ro


For all those above, rw makes the file system read/write, using vi, "G" (capital G) makes it go to the last line. "i" (lower case i) is insert.

59 23 * * * /bin/ntpdate server.ip.address.here
59 minutes, 23 hours past ie. 11:59pm, execute ntpdate with the variable server ip address. I say server IP address because tivo cannot do dns/WINS lookups by default

ESC ESC (press escape twice), :wq (colon, lower case "w", lower case "q") it will show on screen. This means "Write and Quit".

sync - Write changes to disk just in case it writes them later and we reboot before then.

ro - Set the file system back to "Read Only"

If you know how to use "joe" to make the adjustments, go ahead. just remove the commands like "G" and "i" and ":wq" and such.

[105547111]

tenty,

Hmmm since I run my own NTP server, I did not think about using ntpdate :)

Question.... If I update hourly say like:

05 * * * * ntpdate 192.168.0.1

Does this mean I can get rid of fixtime.cron completely as my Windows 2003 Server accounts for daylight savings :) If I check at 05, the server will report the new time (DST or no DST)?

It executes so much faster than fixtime.cron, even though fixtime is looking at the same server....

[tenty]

Does this mean I can get rid of fixtime.cron completely as my Windows 2003 Server accounts for daylight savings :) If I check at 05, the server will report the new time (DST or no DST)?

It executes so much faster than fixtime.cron, even though fixtime is looking at the same server....

05 * * * * ntpdate 192.168.0.1
Means execute 5 minutes on the hour "ntpdate"

The way time sync works:
http://www.eecis.udel.edu/~mills/ntp/html/notes.html

In particular, NTP does not attempt to synchronize clocks to each other. Rather, each server attempts to synchronize to Universal Coordinated Time (UTC) using the best available source and available transmission paths to that source. This is a fine point which is worth understanding. A group of NTP-synchronized clocks may be close to each other in time, but this is not a consequence of the clocks in the group having synchronized to each other, but rather because each clock has synchronized closely to UTC via the best source it has access to.

So in theory, you shouldnt need fixtime.cron

[curto]

OK guys this looks interesting - based on the mailing list threads pointed to earlier in this thread there may be an ongoing theme here.

For what it is worth I have a Cache card with drivers from February and am using OZTIVO Emulator RC1 and do not have any issues with the time drfiting - obivously it gets updated everyday with the dial in.

I am also using the hacked TIVOAPP with backdoors and 30 sec skip enabled.

What version of the Cachecard drivers are you using and do you have anything weird/non-standard (i.e. not from the OZTIVO image) loaded ??

Craig

[DavidSymons]

I've just found the following from a post on the "Skip 30 Seconds Button ..." thread. It probably needed to be posted on this thread as well:




Okay getting back to the 30 second thing. Did you know now I have changed my tivoapp.orig to the all hacked one, the time problem in my other post is GONE!!

So obviously the time problem is something going on in 1.3. My tivo was within seconds per 24 hours with the old 1.0 version, and yes the same cachecard drivers...

Its strange how tivoapp.orig has fixed the time problem. I willl keep you posted but loks great for me at the moment.

I left my NTP server off last night to see how 'bad' it was and its bad, we are talking over 10 mins in 24 hours....



Interesting. I'm running the 1.3 image completely unmodified and having no problems with timing whatsoever.

Another point to note is that Peter's slow clock issue goes away when he connects to mains power rather than his UPS:

http://minnie.tuhs.org/pipermail/oztivo/2004-April/012367.html

Methinks a number of factors are interacting here.

[105547111]

Craig sorry for the reply did not get to TIVO last night.

Okay with the old image I was running (the one you use loadguide), I had the same cachecard hardware and software, the clock was within seconds per day.

I updated last week to this tivo version and the clock is off, same cachecard, driver and software.

Apart from 'stock' software the only mods done are:

Using the March 31st cachecard drivers from siliconimage (the tivo not pc installer)
Mods to fixtivotime and fixtime.cron (using my NTP server)
Mod to /hack/etc/crontab calling fixtime.cron hourly at 10 after the hour
Mod to /etc/rc.d/rc.sysinit.author not starting vserver (I use tystudio)
Installed tystudio (same version I used on last tivo software version)
Mod to /hack/bin/fixtivotime and fixtime.cron pointing to my NTP server.
Now mod using tivoapp 'all'

I presume tivoapp all has all the hacks?

That is all, everything else is the same.

If you need to know anything just yell, anxious to track this down. Meantime what would be an exceptable update I could get cron doing using fixtime.cron? At the moment I am doing it every hour 10 after the hour.

David - Interesting about the UPS, but I cant see them referencing mains frequency for the clock, if that was the case with 50 hz power we would be running all very slow. All I can think in his case, the UPS is generating a harmonic that is upsetting TIVO. But why the old version was not upset and this one is leads to further investigation, it has to be related.

Still the cheap UPS are a standby and not used unless the mains fail, it is then a passive device (unless in UPS mode). Normally they cause problems as they generate a 50Hz square wave, not a 50Hz sine wave, and to some devices a 50 hz square wave looks like 100 Hz sine. But since the TIVO uses like a PC a switch mode supply and I see no AC output to the board, it must be another harmonic related issue.

Something in this image makes the clock more unstable. Its also worthy to mention is all to do with slow not fast.

Thanks!

David

[tenty]

Mod to /hack/bin/fixtivotime and fixtime.cron pointing to my NTP server.

Playing around with my TiVo just doing a `rtimetz ip.address.v.4`



[TiVo [p0] /hack/bin]# rtimetz -v 207.126.98.204 207.126.98.204 129.6.15.28 131.107.1.10
Our postcode is 03000. Found matching timezone Australia/Melbourne
Offset 36000 for timezone EST, daylight saving is 0
Connecting to time server 207.126.98.204
t was 3292141374 from server
t is now 1083188574
Time is 2004-04-28 21:42:54
20040428214254


It appears that using rtimetz syncs time to the timezone that the TiVo is set to. I'm not sure what effect this will have on GMT or how this works with time. Just figured I would note this in this post. Cheers