[mythtv] Improving manual recordings

[David Engel]

On Tue, Oct 04, 2022 at 11:33:42AM -0400, Scott Theisen wrote:
> On 10/3/22 21:33, David Engel wrote:
> > On Mon, Oct 03, 2022 at 06:57:27PM -0400, Scott Theisen wrote:
> > > On 10/3/22 17:34, David Engel wrote:
> > > > On Mon, Oct 03, 2022 at 05:16:47PM -0400, Scott Theisen wrote:
> > > > > On 10/3/22 16:41, David Engel wrote:
> > > > > > On Tue, Sep 27, 2022 at 10:11:23AM -0400, Scott Theisen wrote:
> > > > > > > On 9/26/22 21:51, David Engel wrote:
> > > > > > > > I'll have to review your patch.  ENOTIME right now to do a thorough
> > > > > > > > enough job but I did realize removing the "(Manual Record)" bit was
> > > > > > > > not as easy as I'd hoped it was.
> > > > > > > > 
> > > > > > > > David
> > > > > > > Thinking on it a little more, I think this way is better:
> > > > > > > ```
> > > > > > > diff --git a/mythtv/programs/mythbackend/scheduler.cpp
> > > > > > > b/mythtv/programs/mythbackend/scheduler.cpp
> > > > > > > index 5d8a529dfc..fd2a322a06 100644
> > > > > > > --- a/mythtv/programs/mythbackend/scheduler.cpp
> > > > > > > +++ b/mythtv/programs/mythbackend/scheduler.cpp
> > > > > > > @@ -3698,6 +3698,16 @@ void Scheduler::UpdateManuals(uint recordid)
> > > > > > > 
> > > > > > >         RecordingType rectype = RecordingType(query.value(0).toInt());
> > > > > > >         QString title = query.value(1).toString();
> > > > > > > +    {
> > > > > > > +        // match suffix to ProgramInfo manual recording constructor
> > > > > > > +        QString suffix = " (" + QObject::tr("Manual Record") + ')';
> > > > > > > +        // corner case: user changed language between creating rule and
> > > > > > > now,
> > > > > > > +        // don't chop the end in that case
> > > > > > > +        if (title.endsWith(suffix))
> > > > > > > +        {
> > > > > > > +            title.chop(suffix.size());
> > > > > > > +        }
> > > > > > > +    }
> > > > > > >         QString subtitle = query.value(2).toString();
> > > > > > >         QString description = query.value(3).toString();
> > > > > > >         QString station = query.value(4).toString();
> > > > > > > ```
> > > > > > > 
> > > > > > > It has the same effect and is more correct in my opinion, even if it is more
> > > > > > > computationally intensive.  It is also clearer what it is chopping.
> > > > > > Sorry for the slow response.  Last week turned into a rather hectic week.
> > > > > > 
> > > > > > I'm going to veto this patch and anything similar to it.  While it
> > > > > > will likely work for the basic case of recording, there are enough
> > > > > > enough other cases (e.g duplicate checking, override recordings,
> > > > > > reactivation, change ending time, etc.) that I'm not confident in.
> > > > > Manual recordings are excluded from duplicate checking:https://github.com/MythTV/mythtv/blob/167e016e38b30fb2984e1959dc323bbdaea30468/mythtv/programs/mythfrontend/manualschedule.cpp#L214
> > > > The scheduler performs its own form of duplicate checking while a
> > > > program is recording and when one is stopped early.
> > > Could that be why creating a new manual recording with the same (default)
> > > name resulted in only one recording with the newer duration overriding the
> > > old?
> > Probably.  The oldrecorded table serves multiple purposes.  One
> > purpose is maitaining scheduler state and that keys off scheduled (not
> > recording) starttime, callsign and program title.
> 
> If it uses the callsign, that may be the cause of a separate issue I
> discovered.  I receive two channels (22.1 and 67.1) with the same callsign,
> MPT-HD.  When I manually scheduled a test recording on 22_1, it recorded
> from the other channel, 67_1, instead.
> 
> > 
> > > > > What do you mean by "override recordings"?
> > > > Override rules -- don't record and record with override settings.
> > > Don't record this showing works fine.
> > > 
> > > Record with override appeared to work, although setting two overrides with
> > > three conflicting recordings and two tuners did not select both overrides
> > > without reducing the recording priority of the third recording.  However, we
> > > don't use that kind of override so I don't know how it's supposed to work.
> > > 
> > > > > I will perform some tests with overlapping manual recordings. Stopping the
> > > > > recordings early worked fine from what I remember. I'll also test two
> > > > > identically named recording rules with different lengths, with one canceled.
> > > > > 
> > > > > You can't change the end time (or the start time) after creating a manual
> > > > > recording rule, except by adjusting the start early and end late times.
> > > > > Unless you were talking about something else?
> > > > The ending time can be changed while a program is recording.  Programs
> > > > can also be restarted either manually or automatically due to crashes
> > > > either with the normal end time or another one for that recording.
> > > > 
> > > Changing the end late amount worked for a recording in progress. Restarting
> > > a failed recording manually worked.
> > I'm still not comfortable with the change.  The more I think about it,
> > I like the ruletitle change much, much more.  It's the old adage -- If
> > a thing is worth doing, it's worth doing well.
> > 
> > David
> 
> I don't want perfect to become the enemy of good enough.

That's true sometimes.  I don't think so in this case.

> I think trimming "
> (Manual Record)" is good enough.

Not when you've got a low risk alternative that not only solves this
but another, related issue too.  

> If *you* also want to add ruletitle, that seems to me like a mostly separate
> enhancement.  Since it is your idea, you probably have a better idea of what
> that change entails.

Fine.  I'll leave it on my TODO list.  Until I get to it, *you* can
use the existing option to edit recording metadata after the fact.

David
-- 
David Engel
david at istwok.net