Scheduled recording overrides (Re: [mythtv] Question about finding
mdz at debian.org
Sat Jul 12 20:50:16 EDT 2003
On Fri, Jul 11, 2003 at 05:18:18PM -0500, David Engel wrote:
> The basic idea is to try to place definitive will or won't record
> information in the program table. Specifically, the following columns
> would be added to the database.
I had started thinking about something similar. The basic idea would be to
store the decisions made by the scheduler in the program table in the
database, and store the user's override decisions there as well.
> In the program table:
> recordid: Points to the corresponding row in the record table, if any.
> I know this isn't strictly necessary, but it would probably make some
> queries simpler and faster.
> recordstatus: Indicates whether or not the program will be recorded.
> This would normally be set automatically when a record entry is set or
> new programs are added to the table. It could be manually changed by
> the user from the program guide, resolve conflicts, etc.
> 0: not applicable or undetermined yet
> 1: will record, manually selected
> 2: will record, automatically selected
> -1: won't record, manually deselected
> -2: won't record, automatically deselected
> In the record table:
> recorddups: Indicates whether or not to record duplicate espisodes.
> Could either be a simple yes/no, or yes/no/not within x days of
> deletion. Most users probably don't need this but there was some
> interest in it previously.
> And in case anyone is wondering, yes, I am willing to work on
> implementing this.
My current idea is somewhat similar, but differs in some significant ways:
- recordid referencing the record table (this is the important one)
- recordstatus is not necessary. This is what joins are for; this
information is available by joining with record and looking at the 'type'
- an 'override' field which can (as the name implies) override the action
which would otherwise be taken based on the record type. The only values
I had thought of which would initially be useful are:
- a default value, which means that the user has not requested any
particular behaviour, and implicitly agrees with the automatic decision
of the scheduler
- record always, even if it is a duplicate ('unsuppress' functionality,
which is currently implemented in a hackish way by deleting from
- don't record, even if it matches a scheduled recording ('suppress'
functionality, which mythtv currently doesn't have)
I'd be interested to hear if there are other interesting ideas that people
have for overrides, so that they can be considered in the design (not that
I'll be implementing anything but the above, if that). One thing which I do
not think fits into this idea is fudging start/end times; I think that
should be done differently.
More information about the mythtv-dev