Opened 17 years ago
Closed 16 years ago
#3478 closed defect (fixed)
null originalairdate values in recorded table produces lots of cosmetic errors to logs
Reported by: | otto at kolsi dot fi | Owned by: | danielk |
---|---|---|---|
Priority: | trivial | Milestone: | unknown |
Component: | mythtv | Version: | head |
Severity: | low | Keywords: | |
Cc: | Ticket locked: | no |
Description
Most of my entries in recorded table have null in originalairdate -column. Every recorded program with null originalairdate seems to produce one of these lines to backend's log, when MythWeb's Recorded Programs -page is visited. Totally, there are almost hundreds of these:
QDate::fromString: Parameter out of range
Visiting the Backend Status -page also creates exactly one this kind of log line. This doesn't break anything, it's more a cosmetic issue.
One place for a fix seems to be around here, null values should be checked/handled:
source:/trunk/mythtv/libs/libmythtv/programinfo.cpp@13468#L358 source:/trunk/mythtv/libs/libmythtv/programinfo.cpp@13468#L420
Attachments (2)
Change History (9)
comment:1 Changed 17 years ago by
Owner: | changed from Isaac Richards to danielk |
---|
comment:2 Changed 17 years ago by
How many grabbers actually populate the originalairdate field - i.e. is it just zap2it?
I too see these errors, and, using the uk_rt grabber from XMLTV, have the field in recorded
populated with zero dates (0000-00-00) rather than nulls. In program
I have ~35,000 entries, of which ~32,000 have NULL dates, the balance being zero dates like the recorded
table.
Changed 17 years ago by
Attachment: | mythtv-3478-null_originalairdate.patch added |
---|
Checks for NULL before using QDate::fromString()
Changed 17 years ago by
Attachment: | mythtv-3478-null_originalairdate-2.patch added |
---|
Checks for invalid dates before using QDate::fromString()
comment:3 Changed 17 years ago by
The attached patch, mythtv-3478-null_originalairdate-2.patch, checks for an empty QString or for the value "0000-00-00" before using QDate::fromString() to parse the string. Since NEXT_STR() sets the value of the QString to the empty string if the value read from the list is NULL, a NULL originalairdate will actually result in passing the empty string to QDate::fromString(), so we never actually pass NULL to QDate::fromString(), but were we to do so, isEmpty() would still catch it.
Although QDate::fromString() has been patched to check for empty before parsing in later versions of QT (at least in the 4.x series) and QT3 versions may have been patched in some distros, it doesn't hurt to perform this check for those versions that do not check. I know that vanilla QT 3.3.7 does not perform the check. Also, regardless of whether QDate::fromString() checks for empty strings, we still need to check for the zero-valued dates seen in MySQL (which result in the same errors, contrary to the results of my initial tests).
comment:4 follow-up: 5 Changed 17 years ago by
Thanks for the patch sphery. This seems to work perfectly on my FC4/qt-3.3.4-15.5 system with no more extraneous warnings.
comment:5 follow-up: 6 Changed 17 years ago by
Replying to Nick Morrott <knowledgejunkie [at gmail [dot] com>]:
Thanks for the patch sphery. This seems to work perfectly on my FC4/qt-3.3.4-15.5 system with no more extraneous warnings.
Same here on F7/qt-3.3.8-4
comment:6 Changed 17 years ago by
Replying to anonymous:
Replying to Nick Morrott <knowledgejunkie [at gmail [dot] com>]:
Thanks for the patch sphery. This seems to work perfectly on my FC4/qt-3.3.4-15.5 system with no more extraneous warnings.
Same here on F7/qt-3.3.8-4
I've FC5/qt-3.3.7 and sphery's patch solves the main problem (lots of warnings with MythWeb Recorded Programs -page). I still have one of those warnings when visiting Backend Status -page. But that should not keep this patch from being committed.
comment:7 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(In [14953]) Fixes #3478. Quiet logs about invalid dates when parsing programinfo.
This patch from mtdean just checks for empty and '0000-00-00' dates in ProgramInfo::FromStringList?() before parsing them, and set's them to a null date in this case, rather than having QDateTime do it for us and print a warning. The dates can be null on a normally functioning MythTV system so we shouldn't be printing these warnings constantly.
I don't know when I'll get to this, but it has bugged me in the past and I'm glad you've tracked it down.