[mythtv-users] [SOLVED] Re: how long will myth record shows an hour late

[Robert M. Riches Jr.]

> Date: Mon, 03 Dec 2012 17:29:07 -0800
> From: rm.riches at jacob21819.net (Robert M. Riches Jr.)
> To: mtdean at thirdcontact.com, mythtv-users at mythtv.org
> Subject: Re: [mythtv-users] how long will myth record shows an hour
> 	late
> Message-ID: <20121204012907.C8652267CE at one.localnet>
> Content-Type: text/plain; charset=us-ascii
>
> > Message: 12
> > Date: Mon, 03 Dec 2012 10:35:46 -0500
> > From: "Michael T. Dean" <mtdean at thirdcontact.com>
> > To: Discussion about MythTV <mythtv-users at mythtv.org>
> > Subject: Re: [mythtv-users] how long will myth record shows an hour
> > 	late?
> > Message-ID: <50BCC6D2.6050207 at thirdcontact.com>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > On 12/02/2012 05:42 PM, Nick Rout wrote:
> > > On Mon, Dec 3, 2012 at 8:05 AM, Robert M. Riches Jr. wrote:
> > >
> > >> Ever since the change back from DST back to standard time, Myth
> > >> has been recording scheduled shows an hour late.  After seeing
> > >> (most of) the discussion about how Myth uses UTC internally for
> > >> scheduling,
> > >
> > > Not on your version it doesn't, that change came in 0.26.
> > >
> > >
> > >> I would have thought the situation would fix itself
> > >> after a couple of weeks.  Fortunately, I have a manual recording
> > >> of the same time-slot, and that is working fine.  This is on a
> > >> system that runs 24x7 and has 70 days of uptime.
> > >
> > > Sorry about your uptime, but I think a reboot may sort this.
> > >
> >
> > Yes. Even in MythTV 0.24, a properly-configured system (i.e. the distro 
> > underlying MythTV) will handle the time change without problems--I never 
> > rebooted my systems nor restarted MythTV on them for any DST changes and 
> > recordings worked without issue, even before any mythfilldatabase runs 
> > occurred after the change.  I.e. the change was transparent (with the 
> > exception that recording a show that started or ended on or crossed the 
> > DST boundary required a start early/end late).  And, especially for US 
> > users (guessing based on your e-mail address) who use Schedules Direct, 
> > you can't have old listings data stick around, so it couldn't be a 
> > problem with your data.  (Now, if you're using EIT data because you 
> > didn't think it was worth $25/yr to get high-quality data, you may 
> > actually still have old, garbage data still--i.e. perhaps this is part 
> > of the price you pay to save that $25/yr.)
> >
> > So, assuming you're a Schedules Direct user (and, potentially, even if 
> > you're an EIT or XMLTV user***) something underneath MythTV is broken on 
> > your system, causing MythTV's behavior to be broken.  In these 
> > situations, the easiest thing to do is to reboot so that the underlying 
> > system "picks up the change."  The alternative is to find the underlying 
> > brokenness and figure out how to fix it so that in the future, users of 
> > your distro won't have such problems.
> >
> > Mike
> >
> >
> > *** If you are in North America, you should *not* be using XMLTV with 
> > tv_grab_na_dd rather than using the "internal" Schedules Direct code 
> > because there's no benefit in doing so--and there are actually some 
> > disadvantages.  And if you're in North America, I know you're not using 
> > XMLTV with mce2xml, since doing so is a violation of the Windows MCE 
> > Terms of Service.
>
> Thank you for the info.  In my case, I'm using plain-old EIT,
> because $25/yr is a bit cost-ineffective when the recording
> list is only one (well, two on weekdays) news programs.  No
> Windows in this house, so MCE is not applicable.
>
> Thanks,
>
> Robert

In case it might help some other user, restarting MythBackend
was sufficient to fix the problem of shows being recorded an
hour late--which MythBackend had been doing since the switch
from DST back to standard time.  So, there was no need to
reboot and lose the 70+ days of uptime.  It sort-of looks like
the Myth TV 0.24.1 in Mageia 1 records the difference between
local time and UTC/GMT once when it starts and doesn't check
whether local time changes in between.

(Sadly, after passing 79 days of uptime, the run was cut short
by a kernel NULL pointer when unplugging the USB cable to a
Plextor PX-M402U I bought at a thrift store for US$10.  It's
a nice-looking unit, but it's not worth crashing the kernel
when the go7007 driver module lays an egg.)

Thanks for the replies that yielded the solution.

Robert