Opened 18 years ago

Closed 18 years ago

#2231 closed defect (wontfix)

Automatically move nextRecording to other tuner if scheduled tuner is busy for showing LiveTV

Reported by: mythtv@… Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

This code is useful if you have only one high qualtiy tuner like dvb and an analog tuner for backup recordings. Normally you use the dvb card preferred for records and live tv. The default behavior is that you get a popup to decide whether you will record your scheduled recording or stay at your live tv show.
With this patch you have a new behavior to resolve the conflict and the ability to control it by the priority of your scheduled recording:

  • if the recording priority is greater zero you get a popup as now
  • for all priorities lower and equal zero the scheduler looks for an alternative and reschedule the recording. if no free tuner is found you get the popup again

Attachments (1)

livetv_conflict.diff (3.0 KB) - added by mythtv@… 18 years ago.

Download all attachments as: .zip

Change History (8)

Changed 18 years ago by mythtv@…

Attachment: livetv_conflict.diff added

comment:1 Changed 18 years ago by derek@…

Cc: derek@… added

comment:2 Changed 18 years ago by derek@…

Instead of using the recording priority to decide if the recording should be automatically moved to another tuner why not check the priorities of the other tuners? Something like:

if(liveTV conflict)
{
   tuners = list of available (and free) tuners w/ priority >= tuner being watched
   foreach(tuner as t)
   {
      if(t has program to be recorded)
      {
         change tuner for recording
         return;
      }
   }
}
// If we got here then the recording couldn't be moved
continue on to user popup, etc.

My other idea was to use the recordmatch table to find other instances, but a quick look at recordmatch suggests there isn't quite enough data in that table to be able to use it (at least not without doing more work before making a decision).

I've been wanting to look into this for some time now. Seeing this ticket was the motivation I needed. I guess I'll start by modifying the patch here with my algo above (hopefully my pseudo code makes sense). Just out of curiosity, shouldn't the scheduler be run again if the switch is made since a recording could be scheduled to start during the running time of the recording moved? And then another interesting point - if a recording is moved, does the scheduler detect that and act accordingly. Were any of these scenarios tested with the patch here?

comment:3 Changed 18 years ago by anonymous

Cc: derek@… removed

comment:4 in reply to:  2 ; Changed 18 years ago by mythtv@…

Replying to derek@battams.ca:

Instead of using the recording priority to decide if the recording should be automatically moved to another tuner why not check the priorities of the other tuners? Something like:



I thought the m_tvList is already sorted by priority? And you need something other than the tuner priority also, cause in that case your dvb tuner will also have the highest priority and you will have some shows which you only want to record in high qualtiy. For this shows you want to have a popup to decide to interrupt your live tv session.

My other idea was to use the recordmatch table to find other instances, but a quick look at recordmatch suggests there isn't quite enough data in that table to be able to use it (at least not without doing more work before making a decision).

I've been wanting to look into this for some time now. Seeing this ticket was the motivation I needed. I guess I'll start by modifying the patch here with my algo above (hopefully my pseudo code makes sense). Just out of curiosity, shouldn't the scheduler be run again if the switch is made since a recording could be scheduled to start during the running time of the recording moved?



Ok. There is point I have to test if there are two recordings starting at the same time.

And then another interesting point - if a recording is moved, does the scheduler detect that and act accordingly. Were any of these scenarios tested with the patch here?



The scheduler works correct in my tests, he shows 30 seconds before the recordings start the moved tuner in the schedule list.
I have tested it with several scenarios. I have one dvb and two analog cards and startet three delayed recordings that are available on all three tuners. The recordings were rescheduled correct. The first goes to the next prio card (pvr), the second one to the bttv and for the third on the dvb where I was asked. Also tests with e.g the second recording scheduled on a digital channel that is only available on the dvb card works perfectly and I would be asked again.

comment:5 in reply to:  4 ; Changed 18 years ago by derek@…

Replying to mythtv@linux-dude.de:

Replying to derek@battams.ca:

Instead of using the recording priority to decide if the recording should be automatically moved to another tuner why not check the priorities of the other tuners? Something like:



I thought the m_tvList is already sorted by priority? And you need something other than the tuner priority also, cause in that case your dvb tuner will also have the highest priority and you will have some shows which you only want to record in high qualtiy. For this shows you want to have a popup to decide to interrupt your live tv session.

m_tvList may already be sorted by priority, haven't really investigated that yet. I can see you're point about needing something more than the tuner priority. My suggestion would be to use a recording group instead of priority. When I rank my recording rules I don't do it by tuner preference, I rank them by importance of show. For example, I have a custom rule setup to record movies off of my digital cable source. The rule limits itself to only record off the digital source, but has a priority of -50. I use a low priority to ensure that movies expire before regular tv shows since I can always rerecord the movie or rent the DVD (I use the weighted auto-expire method in SVN). I'd rather change the recording group of this rule to something like 'Digital Only' and use that as the check to decide if we can auto-move the recording instead of having to increase the priority to something above zero.



My other idea was to use the recordmatch table to find other instances, but a quick look at recordmatch suggests there isn't quite enough data in that table to be able to use it (at least not without doing more work before making a decision).

I've been wanting to look into this for some time now. Seeing this ticket was the motivation I needed. I guess I'll start by modifying the patch here with my algo above (hopefully my pseudo code makes sense). Just out of curiosity, shouldn't the scheduler be run again if the switch is made since a recording could be scheduled to start during the running time of the recording moved?



Ok. There is point I have to test if there are two recordings starting at the same time.

When I first thought about doing this I was slowed down by this issue. :-) Ideally, you'd want to move the recording to the next tuner and then rerun the scheduler as it should be able to figure everything out. But I think there are issues. If you do move the recording and run the scheduler, it will either move the recording back to where it was or if there is a program scheduled on the new tuner then it will become a conflict. So now you really only want to move the recording if it doesn't create a conflict. Basically when I first wanted to do this I concluded there are a lot of cases that need to be handled in order for this to work right.



And then another interesting point - if a recording is moved, does the scheduler detect that and act accordingly. Were any of these scenarios tested with the patch here?



The scheduler works correct in my tests, he shows 30 seconds before the recordings start the moved tuner in the schedule list.
I have tested it with several scenarios. I have one dvb and two analog cards and startet three delayed recordings that are available on all three tuners. The recordings were rescheduled correct. The first goes to the next prio card (pvr), the second one to the bttv and for the third on the dvb where I was asked. Also tests with e.g the second recording scheduled on a digital channel that is only available on the dvb card works perfectly and I would be asked again.

Seems like you're saying that the scheduler does get called after you move the program to a new tuner and the scheduler leaves the program on the new tuner and acts accordingly. Is this the case? If so, then the only thing that needs to be checked is that a new conflict was not caused by the move.

My other idea is to add an option to the popup called 'Move recording to new tuner' or something like that. That way we don't need a special priority or recording group, instead we simply move the recording if told to. The same checks would have to be made, we just wouldn't need to check for a special priority or recording group.

comment:6 in reply to:  5 Changed 18 years ago by mythtv@…

Replying to derek@battams.ca:

Replying to mythtv@linux-dude.de:

Replying to derek@battams.ca:

Instead of using the recording priority to decide if the recording should be automatically moved to another tuner why not check the priorities of the other tuners? Something like:



I thought the m_tvList is already sorted by priority? And you need something other than the tuner priority also, cause in that case your dvb tuner will also have the highest priority and you will have some shows which you only want to record in high qualtiy. For this shows you want to have a popup to decide to interrupt your live tv session.

m_tvList may already be sorted by priority, haven't really investigated that yet. I can see you're point about needing something more than the tuner priority. My suggestion would be to use a recording group instead of priority. When I rank my recording rules I don't do it by tuner preference, I rank them by importance of show. For example, I have a custom rule setup to record movies off of my digital cable source. The rule limits itself to only record off the digital source, but has a priority of -50. I use a low priority to ensure that movies expire before regular tv shows since I can always rerecord the movie or rent the DVD (I use the weighted auto-expire method in SVN). I'd rather change the recording group of this rule to something like 'Digital Only' and use that as the check to decide if we can auto-move the recording instead of having to increase the priority to something above zero.

The solution with the recording groups sounds good. I don't know yet that it is possible to use different recording groups to limit the recordings to videosources. I use 0.19+fixes, so I think I missed something.

My other idea was to use the recordmatch table to find other instances, but a quick look at recordmatch suggests there isn't quite enough data in that table to be able to use it (at least not without doing more work before making a decision).

I've been wanting to look into this for some time now. Seeing this ticket was the motivation I needed. I guess I'll start by modifying the patch here with my algo above (hopefully my pseudo code makes sense). Just out of curiosity, shouldn't the scheduler be run again if the switch is made since a recording could be scheduled to start during the running time of the recording moved?



Ok. There is point I have to test if there are two recordings starting at the same time.

When I first thought about doing this I was slowed down by this issue. :-) Ideally, you'd want to move the recording to the next tuner and then rerun the scheduler as it should be able to figure everything out. But I think there are issues. If you do move the recording and run the scheduler, it will either move the recording back to where it was or if there is a program scheduled on the new tuner then it will become a conflict. So now you really only want to move the recording if it doesn't create a conflict. Basically when I first wanted to do this I concluded there are a lot of cases that need to be handled in order for this to work right.



And then another interesting point - if a recording is moved, does the scheduler detect that and act accordingly. Were any of these scenarios tested with the patch here?



The scheduler works correct in my tests, he shows 30 seconds before the recordings start the moved tuner in the schedule list.
I have tested it with several scenarios. I have one dvb and two analog cards and startet three delayed recordings that are available on all three tuners. The recordings were rescheduled correct. The first goes to the next prio card (pvr), the second one to the bttv and for the third on the dvb where I was asked. Also tests with e.g the second recording scheduled on a digital channel that is only available on the dvb card works perfectly and I would be asked again.

Seems like you're saying that the scheduler does get called after you move the program to a new tuner and the scheduler leaves the program on the new tuner and acts accordingly. Is this the case? If so, then the only thing that needs to be checked is that a new conflict was not caused by the move.

The conflict on the new tuner could be done by the FindNextConflict? function, but I didn't have the time yet to check it. I will test this and the other possible issues next week.

My other idea is to add an option to the popup called 'Move recording to new tuner' or something like that. That way we don't need a special priority or recording group, instead we simply move the recording if told to. The same checks would have to be made, we just wouldn't need to check for a special priority or recording group.

That was my first thougt, but the idea to automate it for low prio shows arise when I came back from the toilette and my mythtv interrupted my live tv session and switched to one of a more or less important daily technical magazine and I have to go to the recording menu, cancel the magazine and go back to livetv. Therefore I like the automatic reschedule.

comment:7 Changed 18 years ago by gigem

Resolution: wontfix
Status: newclosed
Type: enhancementdefect

The approach currently being discussed probably won't be accapted. It doesn't take into account program, tuner, etc. priorities and it doesn't give any indication of what will happen until the next recording actually needs to start.

What might be accepted is something like the following. Whenever live TV is started, stopped or changes cards, a reschedule is performed. OPTIONALLY, the scheduler will try to use cards not currently being used for live TV before those that aren't. There are a number of ways this could be done. The quickest and easiest way would probably be to create a negative priority to be subtracted for showings on live TV cards.

Note: See TracTickets for help on using tickets.