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

[Bruce Markey]

David can correct anything I mis-state here but this is the
general idea as I understand it.

Daniel Kristjansson wrote:
> On Fri, 2006-01-06 at 23:14 -0500, Isaac Richards wrote:
>> On Friday 06 January 2006 22:24, you wrote:
>>> #866: Record in LiveTV doesn't work if you leave LiveTV.
>>> ----------------------------------------------+----------------------------
>>> - Reporter:  adrian.wilkins at spamoff.gmail.com  |        Owner:  danielk
>>> Type:  defect                            |       Status:  assigned
>>> Priority:  major                             |    Milestone:  0.19
>>> Component:  mythtv                            |      Version:  head
>>> Severity:  medium                            |   Resolution:
>>> ----------------------------------------------+----------------------------
>>> - Comment (by danielk):
>>>
>>>  Commit readers, please test the attached patch attached to this ticket.
>>>
>>>  AFAIC This should be the last big changeset before 0.19...
>> Nothing obviously wrong jumps out after a once over of the patch.  Missing, 
>> however, is the fact that the scheduler needs to be made aware of the 
>> recording (similar to how it handles a slave-backend, I believe David 
>> mentioned), else it could interrupt the in-progress recording and bad things 
>> will happen.
> 
> Yep, I e-mailed David asking for some direction on this.
> 
> 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:

  if (sp->inputid && !found)
  {
      reclist.push_back(new ProgramInfo(*sp));
      sp->AddHistory(false);
      VERBOSE(VB_IMPORTANT, QString("adding %1/%2/\"%3\" as recording")
              .arg(sp->cardid).arg(sp->chansign).arg(sp->title));
  }

> I haven't heard back from David yet, but really bad things still won't
> happen. The scheduler is blocked from killing the an progress recording
> started in LiveTV, by just starting a new recording as it normally does.
> This isn't ideal as it means post-roll is not a soft post-roll and the
> scheduler will try to start a recording on every reschedule, but should
> work until I hear back from David.

The scheduler keeps track of what is in progress by not removing
rsRecording items from the reclist when it clears the list at the
start of a run. Therefore, all that needs to happen is that entry
needs to be added sometime before PruneOldRecords() is called the
next time the scheduler runs. 

void Scheduler::PruneOldRecords(void)
{
    RecIter dreciter = reclist.begin();
    while (dreciter != reclist.end())
    {
        ProgramInfo *p = *dreciter;
        if (p->recstatus == rsRecording)
        {
            dreciter++;
            VERBOSE(VB_SCHEDULE, QString("Card %1 is recording \"%2\"")
                                         .arg(p->cardid).arg(p->title));
        }
        else
        {
            delete p;
            dreciter = reclist.erase(dreciter);
        }
    }
}

This is how the scheduler knows that this item cannot be disturbed
as an rsRecording can't be moved to another input, etc.

So:

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.

--  bjm