Opened 12 years ago

Closed 12 years ago

#2992 closed defect (fixed)

mythfilldatabase incorrectly reports a successful listings update as failed

Reported by: knowledgejunkie@… Owned by: stuartm
Priority: minor Milestone: 0.21
Component: mythfilldatabase Version: 0.20
Severity: low Keywords: mythfilldatabase guide data problem
Cc: Ticket locked: no

Description

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

Attachments (1)

2992_fix.diff (4.5 KB) - added by stuartm 12 years ago.
Updated version

Download all attachments as: .zip

Change History (7)

comment:1 Changed 12 years ago by stuartm

Milestone: unknown0.21
Severity: mediumlow
Status: newassigned

comment:2 Changed 12 years ago by stuartm

Basing success on how long it takes is clearly flawed. My initial thought would be to base it on the number of programs found in the data, starting at anything more than zero meaning it had been successful. The new xmltv code already works along these lines, although there are unresolved issues with that which still need attention.

comment:3 Changed 12 years ago by stuartm

I mis-read the ticket the first time around and therefore misunderstood the problem.

I've attached a patch with the simplest solution for this specific problem. It's not perfect but should work in most cases. Combined with planned improvements to error catching elsewhere it should mean that the end user only sees the error when a genuine grabber failure has occurred.

Changed 12 years ago by stuartm

Attachment: 2992_fix.diff added

Updated version

comment:4 Changed 12 years ago by stuartm

Resolution: fixed
Status: assignedclosed

(In [12975]) Fixes #2992

Check the programme end times per source and not for all sources when deciding if the xmltv import has failed to add new data.

comment:5 Changed 12 years ago by Nick Morrott <knowledgejunkie [at] gmail [dot] com>

Resolution: fixed
Status: closedreopened

I just noticed that there is still the potential for incorrect reporting of the status of the last mythfilldatabase run.

There is currently an issue which is casuing the uk_rt XMLTV grabber to bail out before downloading any listings data (due to a duplicate channel name in the Radio Times config file causing a premature die.) When I check my mythfilldatabase status via MythWeb after the failed run, I see:

Last mythfilldatabase run started on 2007-07-26 07:00 and is currently running.
There's guide data until 2007-08-07 06:00 (12 days).

MFDB is *not* currently running, and did not import any data on this run.

comment:6 Changed 12 years ago by stuartm

Resolution: fixed
Status: reopenedclosed

(In [14172]) Attempt to fix additional situations where the mythfilldatabase status message is incorrect.

I'm hoping this prevents the problem identified by Nick Morrott.

All the status strings will now be translated.

Fixes #2992

Note: See TracTickets for help on using tickets.