The clock drift sounds like it's probably the cause of my woes. The clocks are normally synced to the same ntp server but I just discovered that the ntp process wasn't being launched because the service name changed after an update and I never added it to the default run level. The difference that had accumulated was 12 seconds, which might be the reason why I keep getting screwed. I fixed the problem, and will see what happens with the next bunch of recordings.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Kristjansson Sent: Saturday, October 08, 2005 1:27 PM To: Development of mythtv; [EMAIL PROTECTED] Subject: Re: [mythtv] Re: Ticket #430: Tuner busy on consecutive recordings On Sat, 2005-10-08 at 12:18 -0700, Mark Kundinger wrote: > I was also experiencing the tuner busy problem yesterday. And making > the eventsleep change suggested did nothing. > > For what it's worth, testing 7416 (which includes the change Daniel > made in 7410), I was able to tape 5 back-to-back shows on one tuner > (MPEG) and 3 back-to-back on the other (MJPEG). > > This apparently diverges from JR's experience with 7410, and I cannot > offer any explanation for that. There are apparently 3 problems: Waiting problem, recently introduced, and fixed in 7410. Race problem, old but was made worse by event loop improvements. Clock drift problem, which has been around a while. The clock drift problem is basically this: The master backend expects the slave backend to end a recording itself. If the slave backend clock drifts out of sync so that it ends recordings after the master backend expects it to, then the master abandons the next recording. I'm working on a fix for all three. -- Daniel
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
