Opened 14 years ago
Closed 14 years ago
#2992 closed defect (fixed)
mythfilldatabase incorrectly reports a successful listings update as failed
Reported by: | 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)
Change History (7)
comment:1 Changed 14 years ago by
Milestone: | unknown → 0.21 |
---|---|
Severity: | medium → low |
Status: | new → assigned |
comment:2 Changed 14 years ago by
comment:3 Changed 14 years ago by
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.
comment:4 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:5 Changed 14 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 14 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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.