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 [EMAIL PROTECTED]
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
