[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