[mythtv-users] [Xmltv-devel] mythfilldatabase: Ignoring unknown timestamp format: 20161231235960

[Ian Campbell]

On Sat, 2016-12-17 at 19:05 -0500, Kevin Groeneveld wrote:
> On Sat, Dec 17, 2016 at 3:58 PM, Ian Campbell <ijc at hellion.org.uk>
> wrote:
> > On Sat, 2016-12-17 at 15:28 -0500, Kevin Groeneveld wrote:
> > > I do wonder if maybe it is already fixed.  I have made
> > significant
> > > changes to the time handling in the CVS code that is not in an
> > > official release yet.  These changes make the CVS version
> > > significantly faster than the release version.  Maybe these
> > changes
> > > also fixed the leap second (or maybe it is okay in the release
> > > version and I broke it in the CVS version).
> > 
> > Sorry, I should have said: I'm running 0.5.68-1 from the Debian
> > packages.
> 
> I just tried running 0.5.68 (although not the Debian package) and the
> latest CVS code and in both cases I could not seem to trigger any
> output which includes a time that ends in "60" or "59".  Maybe there
> is something different about the time setup on my system.

Possibly. FWIW my lineup is GBR-0001194-DEFAULT, I'm running a Debian
Stretch/Sid hybrid system.

> I still think the latest CVS version may fix the problem you are
> seeing.  It converts all times to unix time internally (which does
> not include leap seconds) and uses the gmtime function to convert the
> times back to strings for the final output.  It seems it should be
> impossible to get a time ending in "60".  The 0.5.68 code stored and
> manipulated times using perl DateTime objects.  DateTime does support
> leap seconds so I could see it outputting a time ending in "60".
> 
> Can you try running the latest CVS version?  You can download just
> the tv_grab_sd_json grabber from:
> http://xmltv.cvs.sourceforge.net/viewvc/xmltv/xmltv/grab/sd_json/tv_g
> rab_sd_json.  You should be able to run that file from pretty much
> any location on your system if you have a recent xmltv package
> installed.

I tried to install the dev version like I always have but:

    $ perl Makefile.PL  PREFIX=/usr/local/stow/xmltv-head/
    Can't locate lib/Ask/Term.pm in @INC (you may need to install the lib::Ask::Term module)
    (@INC contains: /etc/perl /usr/local/lib/i386-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1
    /usr/lib/i386-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/i386-linux-gnu/perl/5.24
    /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/i386-linux-gnu/perl-base)
    at Makefile.PL line 254.

lib/Ask/Term.pm is in the XMLTV tree AFAICT, not a 3rd party module.

Maybe regular devs don't notice this because they also have a new
enough one installed from a previous iteration to allow them to
iteratively update it?

I set PERL5LIB to my xmltv.git checkout (i.e. "PERL5LIB=`pwd` perl
Makefile.PL ..." and was able to install. The previously bad entry:

    <programme start="20161231232500 +0000" stop="20161231235960 +0000" channel="24321">
    <programme start="20170101000000 +0000" stop="20170101001500 +0000" channel="24321">
has now become:
    <programme start="20161231232500 +0000" stop="20170101000000 +0000" channel="24321">
    <programme start="20170101000000 +0000" stop="20170101001500 +0000" channel="24321">

and what was previously:
   <programme start="20161231210000 +0000" stop="20161231220000 +0000" channel="65161">
   <programme start="20161231220000 +0000" stop="20170101002959 +0000" channel="65161">
   <programme start="20170101003000 +0000" stop="20170101011500 +0000" channel="65161">
is now:
    <programme start="20161231210000 +0000" stop="20161231220000 +0000" channel="65161">
    <programme start="20161231220000 +0000" stop="20170101003000 +0000"
    channel="65161">
    <programme start="20170101003000 +0000" stop="20170101011500 +0000" channel="65161">

So it's all looking good, thanks!

Ian.