As always, my objective is to have the best DVR possible. What I'm pondering here isn't which point of view would get more points in a debate but what leads to the most reasonable behavior.
Daniel Kristjansson wrote: > On Mon, 2006-01-09 at 17:46 -0800, Bruce Markey wrote: >> MythTV wrote: >> Kudos for making it promote to a scheduled recording at the time >> of exiting the live player. However, unless there is some issue >> that requires that it must be delayed, this should probably happen >> ASAP at the time of TOGGLERECORD. This card and input will be busy >> and this should be reflected on the conflicts page of another >> frontend, "Preview schedule changes", --printsched, etc. > >> Update: Enter live TV and press "R". Start another mythfrontend >> or mythweb session. Go to the EPG. Single record any other show >> in progress. At this point, the card/input have not been reserved >> yet by the scheduler. Things are confused and not worth describing. >> I guess it has to update when R is pressed. See: http://cvs.mythtv.org/trac/ticket/1014 > The main reason was to avoid having to delete the rule and > reschedule if the user toggles the recording bit an even number 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. Also, if the backend crashed between the time that the user pressed R and before they exited, the recording would not restart when the backend restarted. Also, there would be no record entry to match the 'recorded' entry and file. I believe the recordid should be created at (about) the same time as recorded.recgroup is updated from LiveTV to Default and the scheduler informed of the new reality. > of times during the recording. But delaying also allows us to > show the 'the scheduler wants to record X' dialog while we > are in this LiveTV record mode; the reasoning being that if > this conflicts with something important like your SO's Survivor > episode then you'll be duly notified. 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. 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. - 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. - 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. - There is only one card available with inputs for the sources of the live show and the upcoming scheduled show (more on this later =). - Live is using the same card as the scheduled show. With more than one card, this may not be the case. I could have card 2 when I press R and then next show is slated for 1. 1 would be the first input choice if the scheduler started the current in progress (this had been the case in the past) but since 2 is recording it now, 2 is the busy card. - If the same card is in conflict, the scheduled show doesn't have a later showing that can be chosen. [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.] - 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 ;-) 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. Let's say there is a myth system with two or more cards. Someone in the household has scheduled "The Ladies of Dancing with the Stars: A Barbra Walters Special" on Lifetime at 9:00 pm and has dropped subtle hints over the past few weeks that this must record. At 8:15, someone else is laying on the sofa (in peril of sleeping there for the night) stumbles across "Ultimate Fighting Champion's Muscle Cars that Rule The Galaxy" from 8-10 on SpikeTV. He (or she?) hits "R". As it stands at about 8:59:30 a menu pops up asking if the recording should be canceled to continue watching, return to the menu or watch the new show as it records (choose wisely). At 9:00, card 1 will be recording one or the other. However, If the scheduler was informed of the UFC recordings right away, it would schedule Baba Wawa for card 2 and record both with no manual intervention or partial file and would keep domestic bliss in tact. While I've never heard of a case where "R" caused a conflict with an scheduled recording which then never had an opportunity to record, moving a scheduled recording to card 2 when watching card 1 has been mentioned well over a hundred times. I've always thought that this was the key advantage of recording from live. Make the commitment so that the scheduler knows what is happening and can adjust accordingly. Putting this commitment off until later doesn't seem to me to be useful and could be the source of more awkward problems. 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. When this is implemented, the reschedule should be committed as soon as the user confirms that they do want to record. This also suggests to me that we should build no top of code that commits the reschedule right away in the meantime rather than working out bugs with the commitment delayed then tearing it out later. -- bjm _______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
