Opened 15 years ago

Closed 15 years ago

#620 closed enhancement (fixed)

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

Reported by: mythtv@… Owned by: bjm
Priority: minor Milestone: 0.19
Component: mythtv Version:
Severity: medium Keywords:
Cc: Ticket locked: no


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.

Attachments (1)

titlesort.patch (3.8 KB) - added by mythtv@… 15 years ago.
proposed patch

Download all attachments as: .zip

Change History (6)

comment:1 Changed 15 years ago by bjm

Milestone: 0.19
Owner: changed from Isaac Richards to bjm
Type: defectenhancement

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.

Changed 15 years ago by mythtv@…

Attachment: titlesort.patch added

proposed patch

comment:2 Changed 15 years ago by 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).

comment:3 Changed 15 years ago by bjm

Resolution: fixed
Status: newclosed

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

comment:4 Changed 15 years ago by mythtv@…

Resolution: fixed
Status: closedreopened

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?

comment:5 Changed 15 years ago by bjm

Resolution: fixed
Status: reopenedclosed

(In [7899]) Closes #620

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

Note: See TracTickets for help on using tickets.