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

[Daniel Kristjansson]

On Thu, 2006-01-12 at 14:14 -0800, Bruce Markey wrote:

> The rule shouldn't be deleted. As with any other single record
> that was stopped (or ran to completion for that matter) mfdb
> will clear it in the morning. Even a partial record should be
> allowed to have post comm flagging or automatic transcoding.
> There will be a record table entry for this show eventually.
> If the entry is created first and the recording is started,
> stopped then restarted, GetScheduledRecording() ought to find
> the same recordid for this chanid/startts.
But you wouldn't want transcoding/comm flagging to start while
you are still watching the program... it would make it to the end
of the file and quit, in some cases deleting the file...

> If the scheduler knows that the tuner will be busy, it can move
> the upcoming recording to another card or later showing. This, I
> believe is the chief benefit of marking a live show to record.
Yeah, I see that as a real benefit too.

> The possibility that recording the current show could cause an
> unresolvable conflict is an interesting case but I'd never though
> of this nor have I ever seen this mentioned in four years. This is
> possible but a bit obscure.
I don't agree here, this is very likely for 'prime-time' and sports
shows which often don't have any later showings.

> - The live show marked to record has to extend beyond the start
> of the next scheduled recording. This would be an hour show with
> a recording starting on the half hour or a two hour movie with a
> show starting on the next hour.
Yup.

> - The user is unaware of the upcoming recording. For me, I doubt
> I ever go into live without knowing when my next recording is but
> I can't speak for those who still think they are supposed to
> channel surf.
I never know when programs are actually broadcast, I just find
the programs I want to record create a rule for it and forget
about it.

[some other conditions]

> [Also, even in the case of a single tuner, the upcoming recording
> may have a later showing and would record just fine if the used
> chose to 'continue watching' from the menu. The user wouldn't know
> this just from seeing the pop up.]
Yeah, this is a problem. But I'd know if it was the "The Ladies of
Dancing with the Stars: A Barbra Walters Special".

> - Finally, if the same card is in conflict and there is no alternative,
> the upcoming scheduled show is preferred over the in progress show.
> 50-50 shot here ;-)
My couch is very uncomfortable :)

> While the idea that the user could see the warning menu if all
> these conditions come about, promoting the TOGGLERECORD to a
> scheduled recording right away can actually resolve the conflict
> altogether.
Especially in multiple tuners per lineup systems.

[2 tuner example]

Ok, I'm sold on this early scheduling being a better way to do this. I'm
looking at #981 & #919 tmrw, I'll look at the early scheduling next.

> The idea of having an OSD warning before committing does sound like
> a good idea even though I suspect it would rarely if ever come up.
> This could be done with Hal Burch's speculative scheduler used for
> the "Preview schedule changes". Run a specsched with the new single
> and see if a new rsConflict comes up.
I'll leave this to someone else to implement.

-- Daniel