[mythtv-users] Unsupress a recording
Joseph A. Caputo
jcaputo1 at comcast.net
Tue May 20 23:53:33 EDT 2003
On Tuesday 20 May 2003 09:18 pm, Bruce Markey wrote:
> Joseph A. Caputo wrote:
> > *Sigh*
>
> Right back at cha... ;-)
>
> > This is exactly the functionality accomplished by my patch. It adds two
> > flags to the database: PROGRAM.overridesuppression and
> > RECORD.ignoreduplicates
> >
> > PROGRAM.overridesuppression does what you want Single Record to do
>
> No. What I want is to mark a single showing of a single
> entry from the program table with no regard to any other
> entries in the program, record, recorded or oldrecorded
> tables that happen to have the same title. The single
> record entry should not be affected by a series record
> of the same title. Using the example of attributes that
> Chris suggested, I should be able to use a different
> recording profile, start/end offsets, etc. for this single
> record independent of the attributes assigned to a series
> in a separate entry in the record table. If the series is
> removed, I want the single record to remain. Sorry to invoke
> the T word but this is how TiVo does it and it just plain
> makes a lot more sense.
>
Let's separate the issues here -- I agree that single record should be a
separate entry in the record table from a recurring recording type. However,
that doesn't nullify the usefulness of my approach. If I have 'Enterprise'
set up to record 'whenever shown', and I want to re-record a previously shown
episode, that information should be part of the recurring recording setup.
If I decide I don't want to record Enterprise anymore, then I don't want the
single episode either. If I did, I'd schedule that episode for a single
record.
> How do you propose to embed the chanid/start/end to define
> the one showing to be recorded? What if there are two or
> more instances to be marked to be sure to record?
The chanid/start/end is already in the program table where the new flag is
being added. Flagging a single recording occurs in the PROGRAM table, not
the RECORD table.
> How would
> you assign different attributes to one showing?
That's not a current feature of Myth, and I'm not adding it. Someone else can
feel free.
> And, you
> raise the question of what happens if you choose a single
> record then add a series vs. choose a series then add a
> single record? And why should a single record of a show
> be treated any differently depending on if there is a series
> of the same title that is also being recorded.
>
> All of these issues resolve themselves if each single record
> is a separate entry. It's easy to see that recording "Pulp
> Fiction" at 10AM on the 8th has no impact a timeslot record
> of "The Daily Show" at 11PM. It just takes a little leap to
> grasp that you could record "The Daily Show" at 10AM on the
> 8th ('cause you recorded something else on the 7th at 11 ;-)
> and that selection should have no bearing on the timeslot
> entry for every 11PM showing.
I agree (see above), but that's a separate issue.
> > RECORD.ignoreduplicates tells Myth to always ignore whether a particular
> > program is a duplicate when determining to record a show for a scheduled
> > recording.
> >
> > I'm also going to add PROGRAM.forcesuppress (or maybe make
> > PROGRAM.overridesuppression into an enumerated value: 0 - default
> > behavior; 1 - force suppress; 2 - force unsuppress) so that you can
> > forcibly SKIP recording a single instance of a show.
>
> First, I don't like the word "suppress" because it invites
> double negatives. Either you record unique episode by checking
> the oldrecorded table or record all showings by the absence
> of checking oldrecorded. This should be expressed as a positive
> bool like recordall or recordunique. dontnotoverrideunsupress
> would just cloud the meaning.
I don't really care what the database columns are named. The important thing
is that the text presented in the UI is not confusing.
> Also, either you check oldrecorded
> or you don't. I don't see how you arrived at three different
> states.
0 - current behavior (check oldrecorded & suppress duplicates)
1 - ignore oldrecorded (force single record)
2 - suppress single instance even if not in oldrecorded (useful for
suppressing a single show of a recurring recording)
> And finally, I want to be clear that treating single record
> as a separate entry is one issue and would be a welcome
> improvement. Having a choice to record all shows of a series
> without checking the oldrecorded table is a different issue
> that would be a welcome improvement. Either of these could
> be useful to re-record a previously recorded episode but
> other than that, they are entirely different features and
> both serve a useful purpose.
>
> -- bjm
Obviously, there are lots of other features/behaviors being discussed in
regard to recording scheduling & profiles. I'm not really interested in
addressing them. I only thought I'd provide a short-term solution to a
common feature request that *I* am personally interested in. If you or
someone else wants to do a more comprehensive overhaul of the recording setup
interface, feel free.
-JAC
More information about the mythtv-users
mailing list