[mythtv-users] I hate when this happens

[Joseph A. Caputo]

On Wednesday 17 September 2003 02:51 am, Jarod C. Wilson wrote:
> On Tuesday, Sep 16, 2003, at 18:24 US/Pacific, Bruce Markey wrote:
> 
> >> The secondary issue was suggested because a number of us have had this
> >> happen not when the system goes down, but when we restart the backend
> >> program.  As a solution for this, it was suggested that the recording
> >> process be spawned separately, such that a backend restart wouldn't
> >> affect any in-progress recordings.
> >
> > Then the backend really hasn't shutdown and I haven't fixed
> > the problem that I needed to fix when shutting down the backend
> > (lost audio buffers, VIDIOCSYNC, whatever). When the master
> > restarts it kicks off any recordings that should be in progress.
> > How would it find all the orphaned processes on the master and
> > slaves that might be writing the same file and how would it grab
> > the device files that were already busy? If I deliberatly restart
> > the backend I'd want a fresh start for the recordings without
> > overwriting the previous portion. If the recordings where going
> > along nicely and I wanted an unblemished file I wouldn't restart
> > while it was recording.
> 
> Well, there are a number of daemon processes that have both a restart 
> and a reload function that behave slightly differently. Perhaps 
> something along those lines would work. You could have restart kill off 
> all the processes, and reload only kill off the main process, leaving 
> in-progress recordings running. Have your cake and eat it too, both 
> sides get what they're after. Just an idea...


I agree with Bruce (I think... it's getting hard to tell who's being 
quoted...): you could wind up with orphaned processes that don't give up the 
device, among other problems.  Maybe the best (or at least the easiest) 
method would be for the backend to check to see if the file exists before 
starting a new recording; if it does, it simply renames the existing file 
(maybe with a ".0" extension or something).  This way, you could easily 
identify the separate parts of an interrupted recording because they'll share 
the same base filename.  If you wanted to get fancy, you could even come up 
with a scheme for this information to be added to the database, so that you'd 
get multiple entries (Part 1, Part 2, etc) for a show, or even have it just 
automatically start with the first part and continue with the remaining parts 
(somewhat) seamlessly.

-JAC