[mythtv-commits] Ticket #13015: mythfilldatabase may fail with leap second

MythTV noreply at mythtv.org
Mon Mar 13 16:17:15 UTC 2017


#13015: mythfilldatabase may fail with leap second
---------------------------------------+-------------------------
 Reporter:  pbennett                   |          Owner:  stuartm
     Type:  Bug Report - General       |         Status:  new
 Priority:  minor                      |      Milestone:  unknown
Component:  MythTV - Mythfilldatabase  |        Version:  0.28.1
 Severity:  medium                     |     Resolution:
 Keywords:                             |  Ticket locked:  0
---------------------------------------+-------------------------

Comment (by Gary Buhrmaster <gary.buhrmaster@…>):

 Replying to [ticket:13015 pbennett]:
 > This seems to be due the calculation of end time, adding 1 hour to time
 23:00:00, instead of getting 0:00:00 of the next day, getting a time of
 23:59:60.

 Not necessarily. If the origin source data provided a start time of
 23:00:00 and indicated the program duration was indeed 60 minutes (3600
 seconds), the end time *IS* 23:59:60 (on a leap second day).  But the
 duration almost certainly should have been 3601 seconds (and not 3600) in
 the origin data (unless the channel(s) in question shows a black screen
 for a second I guess).  It is possible that the grabber itself(*) might
 have done some internal adjustments to deal with the leap second
 (depending on the source data).  But neither origin sources, nor grabbers,
 tend to handle the leap seconds completely correctly and reliably.

 AFAIK, Qt has never handled leap seconds.  I do not really expect that
 situation to change (for multiple hard reasons).  And trying to properly
 handle it within MythTV would mean trying to do all the work that Qt has
 not done (for all those multiple hard reasons).

 Here are two different proposed patch solutions (both untested).  Neither
 do leap seconds technically right, but are both potentially viable.

 First, just truncate any leap second.  A side effect might be that a
 recording is off by a second in some cases.

 {{{
 diff --git a/mythtv/programs/mythfilldatabase/xmltvparser.cpp
 b/mythtv/programs/mythfilldatabase/xmltvparser.cpp
 index f3249ce..ba69500 100644
 --- a/mythtv/programs/mythfilldatabase/xmltvparser.cpp
 +++ b/mythtv/programs/mythfilldatabase/xmltvparser.cpp
 @@ -199,7 +199,11 @@ static void fromXMLTVDate(QString &timestr, QDateTime
 &dt)
      {
          QString tsTime = ts.mid(8);
          if (tsTime.length() == 6)
 +        {
 +            if (tsTime == "235960")
 +                tsTime = "235959";
              tmpTime = QTime::fromString(tsTime, "HHmmss");
 +        }
          else if (tsTime.length() == 4)
              tmpTime = QTime::fromString(tsTime, "HHmm");
          else if (tsTime.length() == 2)
 }}}


 Second, attempt to move to the first second of the next day.  A side
 effect is that this might generate overlapping program elements which are
 handled in a different way which can result in some recording being off by
 a second.

 {{{
 diff --git a/mythtv/programs/mythfilldatabase/xmltvparser.cpp
 b/mythtv/programs/mythfilldatabase/xmltvparser.cpp
 index f3249ce..d3fc243 100644
 --- a/mythtv/programs/mythfilldatabase/xmltvparser.cpp
 +++ b/mythtv/programs/mythfilldatabase/xmltvparser.cpp
 @@ -199,7 +199,14 @@ static void fromXMLTVDate(QString &timestr, QDateTime
 &dt)
      {
          QString tsTime = ts.mid(8);
          if (tsTime.length() == 6)
 +        {
 +            if (tsTime == "235960")
 +            {
 +                tmpDate = tmpDate.addDays(1);
 +                tsTime = "000000";
 +            }
              tmpTime = QTime::fromString(tsTime, "HHmmss");
 +        }
          else if (tsTime.length() == 4)
              tmpTime = QTime::fromString(tsTime, "HHmm");
          else if (tsTime.length() == 2)
 }}}


 Personally, I can not really decide which proposed patch is less wrong for
 the potential source data being fed to Myth, but in any case, a second
 here, a second there, it probably does not matter, and accepting the
 programme element is probably more useful than trying to handle the extra
 (or missing) second.




 (*) The particular grabber that returned the valid leap second was later
 adjusted due to other code refactor such that it will not be returning the
 leap second in the future (so a fortunate side effect of the refactor).
 But other grabbers may still legitimately return a leap second.

--
Ticket URL: <https://code.mythtv.org/trac/ticket/13015#comment:1>
MythTV <http://www.mythtv.org>
MythTV Media Center


More information about the mythtv-commits mailing list