Search list/movies ordered by title hides that a movie will be recorded

[mythtv@…]

If I go to "Search list" / "movies" and sort by title, the first showing is what is displayed (duplicates removed). If a later showing is scheduled to be recorded, that should be reflected.

For example, Chicago in one four times. The first time is Friday 11/18 at 8PM, which would conflict with a recording that I have. The Sat 11/19 8PM showing does not, and therefore is currently listed as to be recorded. The list shows the movies to be recorded in green, but, since the Fri 11/18 8PM showing is not going to be, it is not green, despite the fact that the movie (in a different) showing will be.

Two options come to mind:

• If one of the showings a movie is to be recorded, show that one
• List all showings of movies that will be recorded (so, Chicago would appear twice, once green)

Both would allow me to see that Chicago will be recorded.

[bjm]

The query uses GROUP BY and returns one match for each title which ought to be the first starttime and may not be the item marked rsWillRecord. However, the GROUP BY doesn't necessarily return the earliest starttime in all cases. I've been meaning to change this to get all matches then trimming to the earliest times in memory. Preferring rsWillRecord regardless of the starttime is a great idea.

[mythtv@…]

proposed patch

[mythtv@…]

Proposed patch restructures the group by and order part of query extensively. It should solve the earliest program that has the most desirable recording status (recorded (shouldn't happen) is better than recording is better than willrecord is better than everything else). plNewListings is not affected (neither better nor worse).

[bjm]

(In [7895]) Closes #620

Improved lists when sorted by title. The New Titles page and any proglist sorted by title selects one representative row per title. This should be the earliest showing, however, MySQL's "GROUP BY" does not assure that the first starttime will be chosen. "ORDER BY" after the fact will only sort the possibly incorrect rows chosen by "GROUP BY". Therefore, all matching rows need to be SELECTed then the best row can be chosen in memory.

The steps to fill the lists have been restructured. All matches are found with no GROUP BY. All lists, regardless of type are loaded into the sortedList. For plNewListings or titleSort, the list is sorted by title with the "best" showing first. The list is then pruned to leave just these "best" time slots. If titleSort is false, the list is sorted by time. Finally they are loaded back into itemList either forward or reverse depending on reverseSort. This means the sort functions don't need a reverse flag as the lists are forward until the very end.

When comparing two titles that are the same, the "best" showing is, if the recstatus is the same, the earliest starttime. Or, the one that is recording, or the one that will record, or the earliest starttime. The result is that a recording in progress will be chosen, or else the earliest rsWillRecord, or else the earliest showing.

So, I record several Reality series. If I go to Search Lists->Categories, choose Reality and press "2" for Title sort, all the titles where I have upcoming recordings appear in green even if it is not the very next showing that will record. Also, the New Titles lists will now be sure to show the earliest showing for each title except when a later showing has been chosen to record.

Thanks to Hal Burch for his input.

[mythtv@…]

Upgraded and tested. For one movie, with four showings, it is recording the last show. 7895 shows the first showing in white, instead of the last showing in green.

[7895] is suspicious, as it does not refer to any line of code that considers recstatus. Were changes to plTitleSort mistakenly not included?

[bjm]

(In [7899]) Closes #620

I'd checked in an intermediate saved version. This is the complete version including the changes to the sort classes.