[mythtv-users] Subtitle then Description duplication check giving surprising results

[Mike Perkins]

Nick Morrott wrote:
> On 19 October 2010 16:51, Mike Perkins <mikep at randomtraveller.org.uk> wrote:
>> Mike Perkins wrote:
>>> Nick Morrott wrote:
>>>> How are you installing things? Source or package manager?
>>>>
>>> I mentioned in another message to this thread that I discovered I had, in
>>> fact, installed 0.5.58 a while back (source). The OS I have on that machine,
>>> Mandriva 2010.0, only supplies 0.5.55 (package).
>>>
>>> As I mentioned elsewhere, it seems that there is a problem whereby the
>>> tarball only installs into $PREFIX/local/bin whereas init.d files don't have
>>> that in their path so I was picking up the wrong version. I manually edited
>>> the Makefile and rebuilt it so all is now (apparently) well.
>>>
>> Yech. Spoke too soon. Every time mfdb runs now, whether automatically or by
>> hand, it runs for /hours/ and then terminates with the dreaded:
>>
>> FillData, Error: xmltv returned error code 256
>>
>> ...it then gets the database management all wrong and collapses without
>> apparently doing anything constructive.
>>
>> There is /very/ little to be gleaned about xmltv error codes via google, and
>> /none/ on the xmltv wiki.
> 
> If it is running properly, tv_grab_uk_rt returns an exit status of 0
> on successful listings retrieval, and an exit status of 1 if it was
> unsuccessful in retrieving some or all listings. The grabber will also
> abort (die) on fatal errors, but as mentioned in the Perl
> documentation "the exit code used by die can be non-predictable, so
> should not be relied upon, other than to be non-zero."
> 
>> Anyone any clues? I'm guessing on a possible perl
>> library conflict here, but I really don't know. All the directories and
>> files accessed appear to have the right owners, groups and permissions.
> 
> Test in isolation. What does mythfilldatabase's status show in
> mythfrontend/mythweb?
> 
> A library issue is possible with Date::Manip - you want a recent
> version, and I'd recommend 6.11. Running the grabber in non-quiet mode
> will output key library versions at the start of the stderr output but
> you can quickly check your Date::Manip version by running:
> 
> $ perl -MDate::Manip -e 'print DateManipVersion(1) . "\n";'
> 
> Run the grabber manually from the command line with your regular
> configuration file:
> 
> tv_grab_uk_rt --config-file /path/to/config.conf --output /tmp/ukrt.xml
> 
> Do you see any errors? The RT service has been unstable for the past
> several weeks, but has improved a lot recently (it still has days when
> it provides no listings though).
> 
Typical. When you want something to fail...

On another suggestion, I faked up a .xmltv file with a single channel statement 
in it and ran the grabber using it. No errors.

Used the output to run a 'mythdatabase --file" by hand, no errors.

Based on this, I decided to run the grabber manually with my standard 
Freeview.xmltv file. No errors.

Ran the output through mythdatabase as above, no errors.

Right, go for it, ran the grabber manually with my Cable.xmltv file, which has a 
subset of the Virgin channels (127). No errors.

Ran the output through mythfilldatabase as before, no errors.

The /only/ thing I can think of which was different (apart from actually running 
from the command line, that is, which is going to possibly introduce environment 
issues) is that the temp files I created were in /home/mythtv rather than /tmp. 
I wouldn't think that should be an issue.

I'll see what happens to the default run tomorrow in case it was some kind of 
data issue which has now resolved itself.

My version of Date::Manip returns 5.42. The software manager insists I have 5.54.

[root at ruby micheal]# find / -iname '*manip*' -print
/usr/lib/perl5/vendor_perl/5.10.0/Date/Manip.pm
/usr/lib/perl5/vendor_perl/5.10.0/Date/Manip.pod
/usr/share/doc/perl-Date-Manip
/usr/share/man/man3/Date::Manip.3pm.lzma
[root at ruby micheal]#

As I said, typical.

-- 

Mike Perkins