
mtdean at thirdcontact
Nov 28, 2007, 5:00 PM
Post #4 of 4
(351 views)
Permalink
|
|
Re: playbackbox periodically jumps to the bottom of the title list
[In reply to]
|
|
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 _______________________________________________ mythtv-dev mailing list mythtv-dev[at]mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
|