Roger: This is really getting off-topic.
Just by using ntp you can usually get the time locked down with accuracy in the millisecond range. If using EIT data can't get you any closer than a second or two, there's really no advantage to using it over ntp. If you're worried about the quality of upstream ntp sources, it's simply not a concern. Use pool.ntp.org (multiple times) as your source. Hint: Take a look at http://www.pool.ntp.org for additional info. (Disclaimer: www.isely.net has been a pool member for many years now.) -Mike On Tue, 29 Nov 2011, [email protected] wrote: > > On Tue, Nov 29, 2011 at 09:05:11PM -0900, Roger wrote: > >Just toss this into a crontab after replacing with a channel frequency: > >$ atsc_epg -f 189028615 | grep "TS STT time" | sed 's/TS STT time: //' > > Just realized, atsc_epg would need to be backgrounded in order to set the > time > relatively close to the remote time. ie: > > $ atsc_epg -f 189028615 & | grep "TS STT time" | sed 's/TS STT time: //' > > ... and then a combination of "date $DATE_TIME && hwclock --systohc" > > For me, I'm thinking I'm going to still have a 5 second difference unless I > use > an offset. > > -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
