[mythtv] Re: Re: Re: [PATCH] delete recording schedules
gigem at comcast.net
Sun Apr 3 04:22:41 UTC 2005
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
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.
gigem at comcast.net
More information about the mythtv-dev