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