Opened 14 years ago

Closed 12 years ago

#2864 closed defect (fixed)

sort by original airdate doesn't work for pre-1970 programs

Reported by: ajlill@… Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: mythtv Version: 0.20
Severity: low Keywords:
Cc: Ticket locked: no


If I set mythfrontend to sort programs by original airdate, and all of the shows have an original airdate before 1970, then the shows are sorted by recording date. If the shows span Jan 1, 1970, sorting works. I've confirmed that the original airdate is correct in the database. Using qt 3.3.4-3sarge1 and libmysqlclient14 4.1.11a-4sarge7 and mysql-server 4.0.24-10sarge2

Attachments (2)

oadsort.patch (1.3 KB) - added by ajlill@… 14 years ago.
Patch to fix sorting by original airdate (aganst 0.20-fixes)
oad-mythweb.patch (632 bytes) - added by ajlill@… 14 years ago.
Matching patch to mythweb for protocol change

Download all attachments as: .zip

Change History (11)

comment:1 Changed 14 years ago by Ross.Campbell@…

Heh, Since Jan 1, 1970 is the beginning of UNIX time, this makes sense... not sure where the bug is and best way to work around it is.

UNIX time is actually rather simple. It's a measure of the seconds that have elapsed since the beginning of the UNIX epoch, which officially began at zero hours, zero minutes, and zero seconds on Jan. 1, 1970, as measured by the international standard of Coordinated Universal Time (UTC).

comment:2 Changed 14 years ago by ajlill@…

But the original airdate is stored in the database as a DATE type, and manipulated as a QDate both of which start at the beginning of the gregorian calendar. So it should have nothing to do with unix TIME.

If it just couldn't handle stuff before 1970, I'd expect for a program that spans 1970, the pre-1970 episodes would be in recorded order and the post 1970 episodes sorted correctly. This is what you get when some episodes have no original airdate (or the same oad) and some do. What I see is that if all episodes are pre 1970, sorting by oad doesn't work, but if some are post 1970, they are all sorted properly.

Looking at the code, the only reason it should fall back to sorting by recorddate, is if the original airdates in the programinfo structure are equal, and the only reason that should happen is if the origial airdate fetched from the database is empty for both the two programs being compared. And the entries in the recorded table are not empty and all different.

comment:3 Changed 14 years ago by ajlill@…

May not be related, but most definitely a bug.... In ProgramInfo::ToStringList? you are converting OriginalAirDate? to a UNIX time value by doing DATETIME_TO_LIST(QDateTime(originalAirDate))

I'll try fixing it and let you know, hopefully by next week.

Changed 14 years ago by ajlill@…

Attachment: oadsort.patch added

Patch to fix sorting by original airdate (aganst 0.20-fixes)

comment:4 Changed 14 years ago by anonymous

Tested this patch and it works.

Changed 14 years ago by ajlill@…

Attachment: oad-mythweb.patch added

Matching patch to mythweb for protocol change

comment:5 Changed 14 years ago by cpinkham

Resolution: fixed
Status: newclosed

(In [12904]) Fix the bug causing original airdates prior to 1970 to be erroneously set to Dec 31 1969 by passing the original air date around in Qt::ISODate (YYYY-MM-DD) format instead of converting to unixtime.

Patch by Tony Lill with protocol bump and removal of now-unused variable by me.

Closes #2864.

WARNING: This bumps the MythTV Protocol from 32 to 33 since it changes the

format of the original airdate field in the ProgramInfo? stringlist. You will need to upgrade your frontends, backends, and mythweb all at the same time in order for them to continue to function together properly.

comment:6 Changed 13 years ago by ylee@…

Resolution: fixed
Status: closednew

I'm running 0.20.2, and have discovered a bug with the original airdate field and pre-1970 programs that may or may not be related to the issue that this ticket fixes. Please feel free to reclose the ticket and tell me to open a new one if it is a separate problem.

An example is Star Trek episodes. There are two upcoming in the next two weeks: "Day of the Dove" (aired Friday 1 November 1968) and "Who Mourns for Adonais?" (Friday 22 September 1967). If, from Scheduled Recordings, I push DETAILS for "Dove," the original airdate is printed on Program Details as Saturday 6 February 2106. However, if I push UPCOMING on the episode to list both episodes, then push DETAILS on "Dove," the correct original airdate appears. The same phenomenon occurs with "Adonais," including the specifically-erronenous date of Saturday 6 February 2106.

All other data on Program Details appears accurate regardless of where it is launched from.

comment:7 Changed 12 years ago by cpinkham

Status: newinfoneeded_new

The first set of data you are viewing is coming from the backend if I understand what you are describing. That screen is filled from the scheduler. The upcoming list is directly retrieved from the database via mythfrontend. Can you run your frontend with "-v network,extra" to see if the dates being passed back and forth have the correct time on them for these programs?

comment:8 Changed 12 years ago by ylee@…

I just checked the three available upcoming Star Trek episodes on my 0.21-fixes setup and they no longer exhibit the problem I described aboves, so go ahead and close this ticket.

comment:9 Changed 12 years ago by cpinkham

Resolution: fixed
Status: infoneeded_newclosed

Closing at user's request.

Note: See TracTickets for help on using tickets.