[mythtv-users] how long will myth record shows an hour late?

[Michael T. Dean]

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.