Feature #1273
Feature #1087: DVR Improvements
Warn if future recordings will oversubscribe available tuners
0%
Description
I bought a very high-spec set of hardware (2 PCs, four tuner cards totalling 12 tuners in all) for recording the London 2012 Olympics, but because the BBC were broadcasting 24 HD channels on satellite (and several more terrestrially), I actually got tuner clashes that I had to cancel the recordings on some of the scheduled programmes.
Imagine someone with just a twin tuner card trying to, say, record 3 channels simultaneously, each on separate multiplexes/transponders. Sadly, tvheadend gives no advanced warning that one of the three recordings won't take place, so if the recording is being done unattended, one of the three programmes won't be recorded, which isn't very nice.
I do realise that the code for this could get complex because you have to look at all future recordings in chronological order, maintaining a "virtual allocation" of tuners/transponders/recordings right through to the most distant recording scheduled in the future (including any pre/post padding) and detect if the tuners would be overallocated at any time (remembering that multiple channels can be recorded on the same transponder/multiplex without using up an extra tuner). It would be nice if all overallocation periods are listed and some advice given on how to fix the issue (i.e. list the possible scheduled recordings to stop the overallocations).
History
Updated by Adam Sutton about 12 years ago
Updated by - Status changed from New to Accepted
- Assignee deleted (
Hein Rigolo) - Parent task set to #1087
As you point out its not a simple task. For simple setup's it's not too difficult, you do indeed just need to scan the existing recordings and warn when the number of required transponders is more than you have available.
But this can become a quite complex scheduling and optimisation task. I'm considering various improvements for the DVR code, when I can find time so this would fit in there.
But there is a lot to consider, some of this is indirectly related. For example consider the case where you have multiple delivery systems which carry multiple copies of the same service, but not necessarily using the same transponder grouping. Now you could also start optimising where you record things to ensure the best usage etc...
And then there are repeats, just because you have a clash there might be another time slot that you can record later in the day/tomorrow/later in the week etc.. So now it's not just about warning the user of a clash, it's informing them stuff has moved.
And finally you've got live tv interaction, if a client sets higher priority and causes a recording to terminate and therefore need re-scheduling that might cause another recording previously added to move. So now you're not just informing the user at the point of entry (actually the same is true for the previous paragraph).
But.. I do agree it needs to be included.
Adam
Updated by Ronald van Eijck about 12 years ago
Updated by For scheduling algorithms MythTV might be a good source of inspiration.
Live view is though because it is unpredictable.
A simple configuration could set preference to recording or live view and possibly designate x tuners for (possible) live view.
If the preference is on recording live view would stop if the tuners are not there, if the preference is on live view
x tuners can be stolen from your recordings. Running the sceduling with all tuners and all tuners - x for live view would
supply information for an indication that the recording can fail if live view steals a tuner.
I have not seen any unit tests in the TVHeadend code. For implementing a complex algorithm like scheduling it might be
a good idea to use them. It can prevent errors in the code and it will allow others to make changes and have them
validated against a wide set of scenario's.
Updated by Rob vh about 10 years ago
Updated by Would it be possible to add a column to the "Current and upcoming recordings" tab that shows the adapter that is (going to be) assigned to a recording, based on:
- start at a time slot when there is no recording
- assign the highest priority adapter for the network
- assign services from the same much to the same adapter
etc?
This would not be true optimization, but would give a quick estimate of conflicts in the coming day(s) IF and ONLY IF there is no one using live streaming (which should be acceptable for a first order solution), and (re)move some recordings as needed.