[mythtv] playbackbox periodically jumps to the bottom of the title list

[Michael T. Dean]

Sorry.  Sent this 16 hours ago, but it didn't go through.  Probably the
stupid hotel internet, but this time I'm tunneling through their
firewall to my mail server so it will go through.

On 11/28/2007 02:51 AM, Dan Wilson wrote:
> 
> On 11/27/2007 at 11:35 PM Dan Wilson wrote:
>> 
>> It is unclear to me what the best fix is for this.  Null values
>> need to be handled in some way, but what is the best way to deal
>> with this?
> 
> I have corrected the null originalairdate values for all episodes
> that had them, and the problem has cleared up for those titles.
> 
> Knowing now what the problem is, I looked at the database and saw
> that all of the movies I have recorded also have null original air
> dates.  If I go to one of the category lists, such as "War", and
> scroll through those movies, I  see the same behavior - the cursor
> suddenly jumps to a different spot in the list.
> 
> The list sorting algorithm has a definite blind spot when it comes to
> null values in the original air date field if one is sorting by
> original air date.  I would be happy to code and test a patch if
> someone with some experience with this piece of the code could
> provide me with some kind of guidance as to how it would be best to
> handle it.  Should the null values simply be ignored and some other
> field be used for determining sort order for that record?

What particular section of code are you referring to?  It seems that
comp_originalAirDate() and comp_originalAirDate_rev() in
programs/mythfrontend/playbackbox.cpp properly use startts as a
secondary sort key and recstartts as a tertiary sort key.

Perhaps we just need to fix the hasAirDate determination (around
libs/libmythtv/programinfo.cpp +893 and +4592 and +4769 ) to include a
check for "0000-00-00" since that's the default value for the DB field
(which would also likely fix the "one of those warnings" mentioned at
http://svn.mythtv.org/trac/ticket/3478#comment:6 ).  In other words,
TTBOMK, any time we have a NULL/empty/"0000-00-00" originalairdate,
hasAirDate should be false (where "should be" indicates the program is
designed such that it /must/ be--though it seems there's a bug that may
allow a NULL originalAirDate in certain situations).

It looks to me like the code was written assuming that "0000-00-00"
would parse to a valid date using QDate::fromString() and the check
for > QDate(1940, 1, 1) would set hasAirDate appropriately, but in my
experience (at least with QT 3.3.7--see
http://svn.mythtv.org/trac/ticket/3478#comment:3 ), a zero-valued date
passed to QDate::fromString() results in a NULL value.  When testing the
patch I made for #3478, my initial tests indicated that "0000-00-00"
would parse correctly, but after more rigorous testing, I found that it
doesn't, so I completely understand how this case could have been missed
by the dev writing the hasAirDate determination code. :)

Mike