null originalairdate values in recorded table produces lots of cosmetic errors to logs

[otto at kolsi dot fi]

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

[danielk]

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.

[Nick Morrott <knowledgejunkie@…>]

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.

[sphery <mtdean@…>]

Checks for NULL before using QDate::fromString()

[sphery <mtdean@…>]

Checks for invalid dates before using QDate::fromString()

[sphery <mtdean@…>]

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).

[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.

[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

[otto at kolsi dot fi]

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.

[danielk]

(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.