[mythtv] Re: Re: Re: [PATCH] delete recording schedules

[David Engel]

On Sat, Apr 02, 2005 at 01:50:00PM -0500, Jeremiah Morris wrote:
> >If a recording ends at 3am and mythfilldatabase runs a 4am, that is
> >not when "mythfilldatabase runs the next day".
> 
> My mistake -- it's a random time between 4 and 28 hours, then, not a 
> random time between 0 and 24 hours. I fail to see that as a significant 
> improvement.

It's not random.  It's perfectly deterministic.  Improvement over what?

> >It makes perfect sense because mythfilldatabase is where any database
> >housekeeping is done.
> 
> If it's an integral part of the housekeeping process, why is it 
> included in a separate binary and run as frequently or infrequently as 
> the user specifies? That is necessary for filling the database, where 
> the procedure may involve custom jobs in the data grabbing, but not for 
> normal mythbackend housekeeping.

Myth is a suite of programs that all work together.  Are you saying
everything should be in one binary because it makes sense to you?

Like Bruce, I think you're getting all worked over something that is
really very minor.  The current implementation is one of probably many
ways to do things, but it works.  If you have a better way that is
cleaner, clearer and doesn't lose functionality, let's see the patch.

> Okay, I had assumed "prematurestop" in the code meant "prematurely 
> stopped", not "stopped due to error". Does Myth know when a recording 
> is truly actually finished, then? 

I suppose it could know, but as Bruce pointed out, it doesn't really
matter.  Housekeeping will still have to be done some place.

> Is mythcommflag initiated from 
> another place, or does it get triggered if a user stops a recording in 
> the middle?

If the recording isn't deleted in the same action, yes, commercial flagging
is queued even for stopped recordings.

> Can someone provide a use case for reactivation? I just can't imagine 
> choosing to delete a recording, and then wanting to start it again, and 
> not caring that I missed some in the middle.

Bruce gave several examples.  Reactivation isn't needed often, but
when it is, it's a nice feature to have.  It's certainly better than
restarting backends and possibly messing up other recordings that
might be in progress.

On Sat, Apr 02, 2005 at 01:58:11PM -0500, Jeremiah Morris wrote:
> That's exactly the case where I think the current code is illogical. If 
> you set a movie to record over your vacation and the listings change, 
> then it won't get recorded and the evidence of your previous schedule 
> will disappear too, leaving you with no indication of what happened.

Knowing why something didn't record would be a useful feature.  I look
forward to seeing your patch.  Please make sure it works for recording
types besides kSingleRecord too.

FWIW, I have plans to improve Myth's reporting of recording and not
recording actions, but it won't be before 0.18 is released.  I'll try
to make sure this case is handled.

> I don't think unsuccessful rules should delete automatically, whether 
> they're a day old or a year old, until the user has a chance to review 
> them and decide if they can reschedule the program with a new rule.

So you want the user to have to perform his/her own housekeeping when
Myth is capable of doing it itself?  Now, that's illogical.

David
-- 
David Engel
gigem at comcast.net