My list of feature ideas
Added by Delta Mike Charlie over 1 year ago
Some of these I have done absolutely no research into and may already exist.
Rating Labels
Finish my work on this. This includes getting the data into Kodi and displaying it there.
Permanent EPG Grabbing
The DVB EIT contains a version number. Having an ultra-low priority subscription constantly tuning to each mux and then saving the EIT version number will allow detection of EPG changes that can initiate a full-scale EPG grab.
EPG Now/Next processing
As well as the bulk EPG, DVB also carries 2 single-entry EPGs carrying the current and next event only. Keep track of these for currently recording muxes and look for changes that may require extending current recordings.
Saving EPG metadata with recordings
TVH does save some EPG data with recordings. However, I'm not sure that it updates the title, subtitle and description if they have changed since the recording was scheduled. More research required.
Keeping track of the EPG history for a recording
This is mostly for timer recording blocks. These don't traditionally have EPG data saved. Simply keep track of all EPG events that occur during the recording and save them somewhere.
Recording conflict prediction
TVH will allow more simultaneous recordings to be scheduled than there are available muxes. This is resolved at recording time using a series of priorities to determine which recordings succeed and which fail.
I have built a predictive model in Python using the JSON API that will simulate a portfolio of current and scheduled recordings plus any recordings that will arise from timers in a given period. The portfolio of recordings is executed against a set of modelled tuner hardware and conflicts are identified.
Replies (3)
RE: My list of feature ideas - Added by Dave Pickles over 1 year ago
EPG Now/Next processing
As well as the bulk EPG, DVB also carries 2 single-entry EPGs carrying the current and next event only. Keep track of these for currently recording muxes and look for changes that may require extending current recordings.
I believe this can already happen. On my system I have set a 30-second 'warm-up' time before recordings; during this time TVH seems to check the EIT p/f and reschedule the timer if needed.
TVH can also use EIT p/f to control recordings directly (so-called 'Accurate Recording') though I find this unreliable.
Recording conflict prediction
TVH will allow more simultaneous recordings to be scheduled than there are available muxes. This is resolved at recording time using a series of priorities to determine which recordings succeed and which fail.
I have built a predictive model in Python using the JSON API that will simulate a portfolio of current and scheduled recordings plus any recordings that will arise from timers in a given period. The portfolio of recordings is executed against a set of modelled tuner hardware and conflicts are identified.
Similar in Javascript: https://github.com/dave-p/TVHadmin-JS/blob/master/timers2.js
Unfortunately TVH is not deterministic; if two timers fire at the same time it is not possible to predict the order in which they will grab their tuners. And of course all bets are off if someone is watching live TV at the same time...
RE: My list of feature ideas - Added by Delta Mike Charlie over 1 year ago
Dave Pickles wrote:
Similar in Javascript: https://github.com/dave-p/TVHadmin-JS/blob/master/timers2.js
Yes, I found this just as I was finishing my Python code.
Unfortunately TVH is not deterministic; if two timers fire at the same time it is not possible to predict the order in which they will grab their tuners. And of course all bets are off if someone is watching live TV at the same time...
I realise that it is not possible to precisely predict exactly which timer will fail, especially when equal priorities are involved, however, it should be possible to determine with a fair degree of certainty that there is a conflict in a specific group of recordings.
RE: My list of feature ideas - Added by Delta Mike Charlie about 1 year ago
XMLTV Programme Update
More research is required, however, it would appear that a programme can only be updated from XMLTV if the start/stop have not changed. Look into storing an XMLTV unique programme identifier (if one exists) in the TVH EPG database and use that to match for updates. DVB already carries a unique event ID so it may be possible to use/adapt this existing feature.