[mythtv] Re: [mythtv-commits] Re: Ticket #866: Record in LiveTV doesn't work if you leave LiveTV.

David Engel gigem at comcast.net
Sat Jan 7 06:29:47 UTC 2006

On Fri, Jan 06, 2006 at 09:42:16PM -0800, Bruce Markey wrote:
> David can correct anything I mis-state here but this is the
> general idea as I understand it.

You've got it pretty correct, as usual

> >My understanding is that the slave-backend on master restart is handled
> >with calls from the master, so this doesn't apply directly unless we
> >make the scheduler polls the recorder; which doesn't feel like the
> >right thing architecturally.
> The key point of the slave example is that it pushes an item
> into the reclist so the scheduler will know that this card/input
> is busy and have the proginfo for the show it is busy recording:

Yes, for all intents and purposes, the case of slave reconnecting and
changing a LiveTV recording to a normal recording need to do the same
thing.  That is to recconcile what the recorder is actually doing with
what the scheduler thinks it is doing.

> 1) create a scheduled recording object to get a recordid but don't
> save it yet (foggy here, perhaps it could be saved with the inactive
> flag temporarily set or something =).
> 2) add a function to pass the proginfo from the live TV session
> to the scheduler to stuff it into the reclist. This should reflect
> the real recstartts of the live buffer, profile "Live TV", type 1
> (kSingleRecord), the source, card and input values, recstatus of
> rsRecording and recordid of the new rule.
> 3) once the item is in the reclist, save the record rule which will
> in turn call signalChange(getRecordID().
> 4) the new record rule's recordmatch item will match the rsRecording
> item already in the reclist and life is good. You now have a recording
> in progress that the scheduler will schedule around and will be
> restarted if the master restarts, etc.
> 5) at this point, the frontend mode has to have changed so that the
> playback session can not change channels or other attributes of the
> recording and can not kill the recording when the player exits as
> would happen with a live session.

Spot on, Bruce.  The tricky part is creating a new record rule (to get
a valid recordid) and passing the appropriate information to the
scheduler, recorder and player without creating a race condition.

David Engel
gigem at comcast.net

More information about the mythtv-dev mailing list