Mailing List Archive

There isn't a way through the interface as far as I've been able to determine. If you are comfortable with SQL though, you can delete the show from the oldrecorded table by hand. Just make VERY sure you know what you are doing before you hit enter on that delete command :) Seems this would be very easy to do with MythWeb, I'll give adding it there a shot.

-----Original Message-----
From: Adrian Burden [mailto:aburden@onegeeksopinion.com]
Sent: Tuesday, May 13, 2003 10:04 PM
To: 'Discussion about mythtv'
Subject: [mythtv-users] Unsupress a recording



Is there a way to clear a grayed scheduled recording in the Fix
Conflicts ?

I want to re record a show, but it comes up with 'This program has been
suppressed because it has already been recorded' and shows up in gray.

Thanks...


_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

I did do it manually, I hooked up phpMyAdmin to make life easier, I know
be a man and use the command line, but I do that all day ;)

That would be a good feature for mythweb, great interface by the way.
People are blown away when they look over my shoulder and I explain to
them what I am doing.

Cheers...


-----Original Message-----
From: mythtv-users-bounces@snowman.net
[mailto:mythtv-users-bounces@snowman.net] On Behalf Of
jasonmiller@micron.com
Sent: Wednesday, May 14, 2003 8:13 AM
To: mythtv-users@snowman.net
Subject: RE: [mythtv-users] Unsupress a recording


There isn't a way through the interface as far as I've been able to
determine. If you are comfortable with SQL though, you can delete the
show from the oldrecorded table by hand. Just make VERY sure you know
what you are doing before you hit enter on that delete command :) Seems
this would be very easy to do with MythWeb, I'll give adding it there a
shot.

-----Original Message-----
From: Adrian Burden [mailto:aburden@onegeeksopinion.com]
Sent: Tuesday, May 13, 2003 10:04 PM
To: 'Discussion about mythtv'
Subject: [mythtv-users] Unsupress a recording



Is there a way to clear a grayed scheduled recording in the Fix
Conflicts ?

I want to re record a show, but it comes up with 'This program has been
suppressed because it has already been recorded' and shows up in gray.

Thanks...


_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

I have this problem all the time :(

From the interface you can change your recording
preference for that show to "record only this
showing".
then after the recording you can switch it back to
whatever it was before.

I agree that this is a feature that should be
available on the interface. I.E. if you hit enter on
a supressed recording in the "fix scheduling
conflicts" list then it takes you to a menu where you
can click a checkbox that says "I want to record this
show anyways".

anyways ... the fix above should get you what you
need.

--- jasonmiller@micron.com wrote:
> There isn't a way through the interface as far as
> I've been able to determine. If you are comfortable
> with SQL though, you can delete the show from the
> oldrecorded table by hand. Just make VERY sure you
> know what you are doing before you hit enter on that
> delete command :) Seems this would be very easy to
> do with MythWeb, I'll give adding it there a shot.
>
> -----Original Message-----
> From: Adrian Burden
> [mailto:aburden@onegeeksopinion.com]
> Sent: Tuesday, May 13, 2003 10:04 PM
> To: 'Discussion about mythtv'
> Subject: [mythtv-users] Unsupress a recording
>
>
>
> Is there a way to clear a grayed scheduled recording
> in the Fix
> Conflicts ?
>
> I want to re record a show, but it comes up with
> 'This program has been
> suppressed because it has already been recorded' and
> shows up in gray.
>
> Thanks...
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
>
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
>
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

I would like this as an option as well... since I don't think it is, I
respectfully request that it be considered as an option to the
scheduling conflict screen. :)

Regards,
Aran


On Tue, 2003-05-13 at 23:04, Adrian Burden wrote:
> Is there a way to clear a grayed scheduled recording in the Fix
> Conflicts ?
>
> I want to re record a show, but it comes up with 'This program has been
> suppressed because it has already been recorded' and shows up in gray.
>
> Thanks...
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

I'm currently working the kinks out of a patch to allow this behavior --
namely, flagging a single instance of a show for recording even if it is a
duplicate, and also turning off duplicate checking for all instances of a
scheduled recording.

The mechanism is two new columns in the database. I submitted the patch
once with the caveat that I thought there was a bug in either it or the
general duplicate-checking code, but I've been unable to reproduce the
problem since. I just need to update to current CVS and test it out on my
box before I re-submit it. Might not get to that 'till next week, as real
life intrudes!

All that being said, assuming this patch eventually gets committed to CVS,
someone will still need to update the frontend GUI interface to allow the
user to manipulate those settings. I have a feeling the feature will find
its way into MythWeb first.

-JAC

> -----Original Message-----
> From: mythtv-users-bounces@snowman.net
> [mailto:mythtv-users-bounces@snowman.net]On Behalf Of Aran Cox
> Sent: Monday, May 19, 2003 1:57 PM
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] Unsupress a recording
>
>
> I would like this as an option as well... since I don't think it is, I
> respectfully request that it be considered as an option to the
> scheduling conflict screen. :)
>
> Regards,
> Aran

Joseph A. Caputo wrote:
> I'm currently working the kinks out of a patch to allow this behavior --
> namely, flagging a single instance of a show for recording even if it
is a
> duplicate, and also turning off duplicate checking for all instances of a
> scheduled recording.

It seems to me that a solution for this and other problems
would be to have single record ignore other considerations
like oldrecorded and the record type of the series and simply
record that episode. If you mark a showing for single record
it should record that showing. This probably should have been
the default behavior all along. This solution wouldn't involve
any database or GUI changes. Only some logic changes in the
scheduler.

I can see the value in marking a series to record all showings.
Another feature I would find useful is a single negate recording.
I sometimes know I don't want to record a showing but don't want
to change the series to 'don't record' then have to remember to
find it and add it again after the unwanted showing has past.

-- bjm

actually .. this is the behavior right now, but it is
not as convenient for the same reasons you provide in
your second comment. Its annoying the have a timeslot
recording that you have to change to single record and
then back again. And its especially annoying if you
change it to single record and forget to switch it
back before the next episode.

This is why it would be a whole lot easier to have 2
possible options:

1) a setting like "don't suppress previously recorded
shows"

2) the ability to hit "enter" on a grey line
(suppressed) recording in the Resolve conflicts menu
and be offered a chance to click "record this episode
anyways"

those both sound pretty reasonable to me ... and
certainly useful.
--- Bruce Markey <bjm@lvcm.com> wrote:
> Joseph A. Caputo wrote:
> > I'm currently working the kinks out of a patch to
> allow this behavior --
> > namely, flagging a single instance of a show for
> recording even if it
> is a
> > duplicate, and also turning off duplicate
> checking for all instances of a
> > scheduled recording.
>
> It seems to me that a solution for this and other
> problems
> would be to have single record ignore other
> considerations
> like oldrecorded and the record type of the series
> and simply
> record that episode. If you mark a showing for
> single record
> it should record that showing. This probably should
> have been
> the default behavior all along. This solution
> wouldn't involve
> any database or GUI changes. Only some logic changes
> in the
> scheduler.
>
> I can see the value in marking a series to record
> all showings.
> Another feature I would find useful is a single
> negate recording.
> I sometimes know I don't want to record a showing
> but don't want
> to change the series to 'don't record' then have to
> remember to
> find it and add it again after the unwanted showing
> has past.
>
> -- bjm
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
>
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Good idea... I'll add this to my patch; it'll be a piece of cake.

Any volunteers to write the UI? We need it in 3 places:

- Hit 'space' on a suppressed recording to bring up a screen to force
un-suppress a single instance
- Hit 'space' on a scheduled recording to force-suppress a single instance
- An option in the 'Schedule a recording' window to ignore duplicates for an
entire show/series/etc (IIRC, Isaac didn't want anything added to that
screen, so it might be time to add an "Advanced..." button to it for
collecting other recording options on a separate screen)

-JAC


On Monday 19 May 2003 05:10 pm, Bruce Markey wrote:
>
> Another feature I would find useful is a single negate recording.
> I sometimes know I don't want to record a showing but don't want
> to change the series to 'don't record' then have to remember to
> find it and add it again after the unwanted showing has past.
>
> -- bjm

Allen T. Gilliland IV wrote:
> actually .. this is the behavior right now...

Hummm... Nothing in my last message described the current
behavior so I can't be sure what you are referring to.
If it was "have single record ignore other considerations
like oldrecorded and the record type of the series" then
try the following. Go the EPG and find a show that is on
daily ("The Daily Show" seems like an appropriate example ;-).
Press "i" and select timeslot recording. Esc and it should
be marked "T". Press "End" to move forward a day. This
should also be marked "T". "Home" to return, "i" then select
"Record only this showing of the program", "Esc" and "End".
What do you see?

Single record should a separate entity independent of any
other rows in the database that happens to have the same
title. You should be able to mark that you want to record
a single showing with no impact on a selection for a
series that may happen to have the same title. Single
negate would be the opposite that says don't record this
showing even if there is a series of that title (I could
have used this feature this evening).

>
> This is why it would be a whole lot easier to have 2
> possible options:
>
> 1) a setting like "don't suppress previously recorded
> shows"

This is a double negative based on assumption about what
is going on internally. "Record all showings" is more to
the point. This is an attribute for a series and a different
feature than the independence of a single record.

> 2) the ability to hit "enter" on a grey line
> (suppressed) recording in the Resolve conflicts menu
> and be offered a chance to click "record this episode
> anyways"

Or be able to hit "i" on any item on the conflict page
be it grey, white, red, yellow or whatever. If single
record worked correctly, you could then mark that one
grey show to be recorded. If there was a "Record all
showings", you might choose that instead if that is what
you want to future shows.

-- bjm

> > 2) the ability to hit "enter" on a grey line
> > (suppressed) recording in the Resolve conflicts menu

> Or be able to hit "i" on any item on the conflict page
> be it grey, white, red, yellow or whatever. If single

I think it would be nice to have another screen pop up when you hit
i/m/ENTER/whatever on the scheduled recordings screen. The screen
would be for editing the recording information for the current item.
It could contain widgets to change things like:

* Advanced Recording options (list regular options as well)
- Record this show at this time on this channel on this day of the week
- Record this show at this time on this channel on Weekdays
- Record this show at this time on this channel on Weekends
* One-time Recording changes (for this instance)
- Force single record (overriding oldrecorded table)
- Suppress single record (overriding record always)
* Recording profile
* Adjust Start time
* Adjust End time
* Auto-delete options (not all options listed here)
- Never auto-delete
- Keep at most X copies of this show around (if I only want to keep
the last 5 copies of the Simpsons around)

Chris

> Single record should a separate entity independent
> of any
> other rows in the database that happens to have the
> same
> title. You should be able to mark that you want to
> record
> a single showing with no impact on a selection for a
> series that may happen to have the same title.

It has never worked this way for me, whenever I change
a shows recording setting from say Timeslot record to
Single Recording then it removes the timeslot record.
I am not debating that functionality because it makes
sense, you don't want to double record things. To me
it sounds like in your example above you would expect
to see a single show marked with 2 recording types
(single and timeslot) ...

are you suggesting this is how it should work?


> > 1) a setting like "don't suppress previously
> recorded
> > shows"
>
> This is a double negative based on assumption about
> what
> is going on internally. "Record all showings" is
> more to
> the point. This is an attribute for a series and a
> different
> feature than the independence of a single record.

Well ... really then you would need 2 options.
"Record all showings except previously recorded
episodes", which is the way it is now. And "Record
all showings INCLUDING previously recorded episodes",
which is what I want. What I am suggesting is
basically an alternate db column for recordings called
say "neglect_suppress" which can be either "true" or
"false" for each recording. This could be represented
by a checkbox on the UI page for setting the recording
type for a show and defaults to unchecked.

>
> > 2) the ability to hit "enter" on a grey line
> > (suppressed) recording in the Resolve conflicts
> menu
> > and be offered a chance to click "record this
> episode
> > anyways"
>
> Or be able to hit "i" on any item on the conflict
> page
> be it grey, white, red, yellow or whatever. If
> single
> record worked correctly, you could then mark that
> one
> grey show to be recorded.

exactly!

> If there was a "Record all
> showings", you might choose that instead if that is
> what
> you want to future shows.

I would argue that the label "Record all showings" is
still ambiguous when trying to determine what happens
with previously recorded shows. Thats why I think its
easiest to leave things as they are and add the extra
checkbox labeled "I want to record these shows even if
I have recorded them previously" ... or something like that.

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Chris Pinkham wrote:
>>>2) the ability to hit "enter" on a grey line
>>>(suppressed) recording in the Resolve conflicts menu
>>
>
>>Or be able to hit "i" on any item on the conflict page
>>be it grey, white, red, yellow or whatever. If single
>
>
> I think it would be nice to have another screen pop up when you hit
> i/m/ENTER/whatever on the scheduled recordings screen. The screen
> would be for editing the recording information for the current item.

This screen should be the same screen wherever the record
options can be set such as the EPG and Program Finder. These
use an InfoDialog object. I tried adding an InfoDialog with
ViewScheduled::displayInfo() in viewscheduled.cpp but I got
segfaults when I called GetProgramRecordingStatus after a
change to the record type. Not sure why. Must have overlooked
something my haste.

If you could manage to add the current info page to the
conflicts page, that would be a good first step.

> It could contain widgets to change things like:
>
> * Advanced Recording options (list regular options as well)
> - Record this show at this time on this channel on this day of the week
> - Record this show at this time on this channel on Weekdays
> - Record this show at this time on this channel on Weekends
> * One-time Recording changes (for this instance)
> - Force single record (overriding oldrecorded table)
> - Suppress single record (overriding record always)

I think a single record would need to be a separate entry
in the 'record' table for this to work (and, I think this
is the way it should be =).

> * Recording profile

Yes! a spinbox on the info page.

> * Adjust Start time
> * Adjust End time

Maybe startoffset and endoffset could be added to the record
table. The startime and endtime would remain so that they
can be checked against the 'program' entries but the endtime
plus endoffset could be used in checking for conflicts and
for the actual start and end when recording.

> * Auto-delete options (not all options listed here)
> - Never auto-delete
> - Keep at most X copies of this show around (if I only want to keep
> the last 5 copies of the Simpsons around)

Or one spinbox with All,1,2,3,4,5...

Not sure what options you didn't list but one consideration
is that you should be able to mark a 'recorded' entry as
exempt from auto-delete. This would need to be an attribute
of 'recorded' that the auto-delete code would honor. Auto-delete
code could also be used to remove the oldest non-exempt show
of any title when disk space falls below some minimum amount
of free disk space.


-- bjm

Allen T. Gilliland IV wrote:
>>Single record should a separate entity independent
>>of any
>>other rows in the database that happens to have the
>>same
>>title. You should be able to mark that you want to
>>record
>>a single showing with no impact on a selection for a
>>series that may happen to have the same title.
>
>
> It has never worked this way for me, whenever I change
> a shows recording setting from say Timeslot record to
> Single Recording then it removes the timeslot record.

Which is what I said in the first place (and you disputed ;-)
Currently it modifies the entry for that title so single
record says record this showing and no others. I'm sure we
agree that this is not the desired behavior.

> I am not debating that functionality because it makes
> sense, you don't want to double record things. To me
> it sounds like in your example above you would expect
> to see a single show marked with 2 recording types
> (single and timeslot) ...
>
> are you suggesting this is how it should work?

Not exactly. There should be two entries in the record
table; record "The Daily Show" everytime it is on at 11PM
on Comedy Central, and another entry to record the show
on Comedy Central at 11PM on 5/20/2003.

Single record "wins" in conflict resolution so 5/20 would
be marked "R" and all other days would be marked "T".

-- bjm

*Sigh*

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 -- it
marks a single instance of a program to be forcibly recorded, without
affecting the current recording type. You don't need a separate entry in
the RECORD table. (Assuming that you've already scheduled the show to
record with one of the recurring record types)

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.

Again, I'm providing (probably next week) the ability to control these
features; someone just has to incorporate it into a GUI.

-JAC

> -----Original Message-----
> From: mythtv-users-bounces@snowman.net
> [mailto:mythtv-users-bounces@snowman.net]On Behalf Of Bruce Markey
> Sent: Tuesday, May 20, 2003 3:54 PM
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] Unsupress a recording
>
>
> Allen T. Gilliland IV wrote:
> >>Single record should a separate entity independent
> >>of any
> >>other rows in the database that happens to have the
> >>same
> >>title. You should be able to mark that you want to
> >>record
> >>a single showing with no impact on a selection for a
> >>series that may happen to have the same title.
> >
> >
> > It has never worked this way for me, whenever I change
> > a shows recording setting from say Timeslot record to
> > Single Recording then it removes the timeslot record.
>
> Which is what I said in the first place (and you disputed ;-)
> Currently it modifies the entry for that title so single
> record says record this showing and no others. I'm sure we
> agree that this is not the desired behavior.
>
> > I am not debating that functionality because it makes
> > sense, you don't want to double record things. To me
> > it sounds like in your example above you would expect
> > to see a single show marked with 2 recording types
> > (single and timeslot) ...
> >
> > are you suggesting this is how it should work?
>
> Not exactly. There should be two entries in the record
> table; record "The Daily Show" everytime it is on at 11PM
> on Comedy Central, and another entry to record the show
> on Comedy Central at 11PM on 5/20/2003.
>
> Single record "wins" in conflict resolution so 5/20 would
> be marked "R" and all other days would be marked "T".
>
> -- bjm

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.

> -- it
> marks a single instance of a program to be forcibly recorded, without
> affecting the current recording type. You don't need a separate entry in
> the RECORD table. (Assuming that you've already scheduled the show to
> record with one of the recurring record types)

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? How would
you assign different attributes to one showing? 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.

> 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. Also, either you check oldrecorded
or you don't. I don't see how you arrived at three different
states.

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

Bruce Markey wrote:

> This should be expressed as a positive bool like recordall or
> recordunique. dontnotoverrideunsupress would just cloud the meaning.

I don't think that "Record all showings" is terribly clear. I'd think
"Of course record all showings! Do you think I want you to randomly
leave out some shows because you don't feel like recording that day?"
I agree that double negatives are not ideal.
I'd call it "Don't record episodes again that have been recorded in the
past", defaulting it to true. I'd still use the negative, because the
straightforward (and thus expected) way is to just record everything and
this option is *enabling* some extra "smart" logic (which happens to
*supress* something).

How about, "Record all showings (including duplicates)" ?

JC

----- Original Message -----
From: "Ben Bucksch" <linux.news@bucksch.org>
To: "Discussion about mythtv" <mythtv-users@snowman.net>
Sent: Tuesday, May 20, 2003 9:46 PM
Subject: Re: [mythtv-users] Unsupress a recording


> Bruce Markey wrote:
>
> > This should be expressed as a positive bool like recordall or
> > recordunique. dontnotoverrideunsupress would just cloud the meaning.
>
> I don't think that "Record all showings" is terribly clear. I'd think
> "Of course record all showings! Do you think I want you to randomly
> leave out some shows because you don't feel like recording that day?"
> I agree that double negatives are not ideal.
> I'd call it "Don't record episodes again that have been recorded in the
> past", defaulting it to true. I'd still use the negative, because the
> straightforward (and thus expected) way is to just record everything and
> this option is *enabling* some extra "smart" logic (which happens to
> *supress* something).
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users
>
>

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