Opened 15 years ago

Closed 15 years ago

#859 closed defect (fixed)

QDateTime comparison in EncoderLink::MatchesRecording causes problems because of miliseconds

Reported by: torbjorn.jansson@… Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: mythtv Version:
Severity: medium Keywords:
Cc: Ticket locked: no


There is a problem in EncoderLink::MatchesRecording? This code:

if (tvrec->chanid == rec->chanid &&
    tvrec->recstartts == rec->recstartts)

Will never be true because tvrec->recstartts contains miliseconds and rec->recstartts does not (ProgramInfo? To/From? String functions only uses seconds) This causes the CHECK_RECORDING command to the backend to never find the recording.

I suspect the cause of this is a QDateTime::currentDateTime() somewere but i haven't found which one.

The easy fix for this is to change the recstartts check to something like:

tvrec->recstartts.toTime_t() == rec->recstartts.toTime_t()

I don't know if there are other places in the code that have similar problems, QDateTime::currentDateTime() is used in lots of places and therefor many of the QDateTime variables can contain miliseconds.

And another thing, is there a reason for not having a break in the for loop in MainServer::HandleCheckRecordingActive? ? Can the exact same recording be recording on more than one recorder at the same time?

Change History (1)

comment:1 Changed 15 years ago by cpinkham

Resolution: fixed
Status: newclosed

recstartts is now set without milliseconds using the new mythCurrentDateTime() added by Isaac in [8505]. I believe this issue should be fixed going forward so I'm closing the ticket. If you find other places that need to be converted, attach a patch to convert them from QDateTime::currentDateTime() to mythCurrentDateTime().

Note: See TracTickets for help on using tickets.