[mythtv] Proposing some schedule recordings changes

[Bruce Markey]

Vedran Rodic wrote:

> I've noticed varius bugs with scheduling recordings. For example 
> deleting a manually scheduled recording doesn't work because 
> EncoderLink::MatchesRecording can't find a matching recording because 
> tvrec->recendts != rec->recendts (they usually differ a few seconds - 
> tvrec->recendts:Tue Aug 31 15:10:10 2004 rec->recendts:Tue Aug 31 
> 15:10:00 2004). 

Then the end time shouldn't be checked. The chanid_starttime
is enough to match them up.

Why the recording here isn't simply matched by 'recordid'?

Because the recordid is associated with the record rule. There
may be several recordings in the recorded table with the same
recordid such as every episode of a series.

mysql> select recordid,title from recorded where title like "T%" order by recordid;
+----------+-------------------------+
| recordid | title                   |
+----------+-------------------------+
|     2488 | The Casino              |
|     2488 | The Casino              |
|     2488 | The Casino              |
|     2696 | The Amazing Race 5      |
|     2946 | The Lance Chronicles    |
|     3030 | Things I Hate About You |
|     3030 | Things I Hate About You |
...

> Also, is there a reason why is MainServer::DoHandleStopRecording
> matching the 'recorded' table rows  with 'WHERE chanid = :CHANID AND 
> title = :TITLE AND starttime = :STARTTIME AND endtime = :ENDTIME' 
> instead of 'WHERE recordid = :RECORDID' when updating the recording 
> endtime.

Because there can be more than one show in the listings at a time
that matches the same recordid. Examples "XXVIII Summer Olympics",
"Republican National Convention", "MLB Baseball", "Paid Programming",
and anything is possible with the Search type rule.

> When I stop the recording only the 'recorded' table is updated. 
> Shouldn't the 'record' table also be updated with new endtime? 

Absolutely not. The endtimes in the record rules have nothing
to do with anything. There are six different types of record rules
and most of them are recurring. Changing the endtime in the record
rule has no bearing on the fact that the title (channel, starttime
or weekday depending on the record type) matches something in the
listing. Changing the 'program' table is a bad idea too. You'll
need to look elsewhere for a solution.

> Because if it isn't updated, if I restart the backend, recording starts again.

Stopping and starting the backend after a recording has been
stopped but before the endtime is not a general problem for users.
However, I've had to stop a server and I either set an override
for "Don't record" before shutting down or remove the record rule
from the Set Priorities page if it is a single rather than
recurring type (or deleting the new portion after the server
has restarted). Either way, this is not a big issue. On the
other hand, the "Reactivate" feature that gigem recently added
is a real blessing and any change that would prevent restarting
a previously stopped recording would suck.

> If you agree with my changes I'll submit a patch soon.

I don't =). Sending patches that would break things for everyone
else probably isn't the best way to start feeling your way
around to see how things work ;-) Sorry.

--  bjm