[mythtv-commits] Ticket #2992: mythfilldatabase incorrectly reports a successful listings update as failed

[MythTV]

#2992: mythfilldatabase incorrectly reports a successful listings update as failed
---------------------------------------+------------------------------------
 Reporter:  knowledgejunkie at gmail.com  |       Owner:  stuartm
     Type:  defect                     |      Status:  new    
 Priority:  minor                      |   Milestone:  unknown
Component:  mythfilldatabase           |     Version:  0.20   
 Severity:  medium                     |  
---------------------------------------+------------------------------------
 I run mythfilldatabase manually using output from the XMLTV uk_rt grabber
 for a few different video sources (although I think this problem will be
 evident if it was run automatically via the backend). Some of these
 sources have common channels.

 If a successfull listings update takes a minute or less, which having
 tested one of my video sources is the case, the backend status reports the
 listings update as having failed, due to the same start and finish times
 for the run being entered into the database.

 Looking over the code as a non (as-yet) competent C programmer, it seems
 mythtv/programs/mythfilldatabase/main.cpp compares the latest listings
 entry before the run, with the latest entry afterwards ( if
 (GuideDataAfter == GuideDataBefore) ).

 If a user is updating common channels on >1 video source, then it is quite
 likely that this test will be true after a successful run, as each channel
 will have its own copy of the same data after the MFDB run. However, it is
 quite possible that listins  information could be added for channels that
 are not on other sources and whose end times are earlier than the latest
 program data available.

 On my backend, every day after MFDB run the status remains
 "mythfilldatabase ran, but did not insert  any new data into the Guide"
 and yet new data /has/ been inserted into the guide as new scheduled
 recordings appear.

 Should a different method of determining whether a MFDB run was successful
 be used, or is this how it is intended to be implemented?

 Cheers,
 Nick Morrott

-- 
Ticket URL: <http://cvs.mythtv.org/trac/ticket/2992>
MythTV <http://www.mythtv.org/>
MythTV