[mythtv] Re: Ticket #430: Tuner busy on consecutive recordings

Jack Hyde jr at jrh.net
Sun Oct 9 07:05:27 UTC 2005


I just had my first successful consecutive record, so it's pretty obvious 12
seconds might as well be years as far as mythtv and clockdrift are
concerned. Apparently not even 3 seconds is close enough since ntp takes
awhile to adjust the clock, and I had a failed consecutive recording when it
was still trying to bring them into sync.

-----Original Message-----
From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org]
On Behalf Of Jack Hyde
Sent: Saturday, October 08, 2005 3:42 PM
To: 'Development of mythtv'
Subject: RE: [mythtv] Re: Ticket #430: Tuner busy on consecutive recordings

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: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org]
On Behalf Of Daniel Kristjansson
Sent: Saturday, October 08, 2005 1:27 PM
To: Development of mythtv; mtk at alumni.rice.edu
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





More information about the mythtv-dev mailing list