Looking at the various posts in the forums and knowing the nature of the (commercial channel) beast, I think it is safe to say that one of the biggest issues any FTA viewer in Oz has is catering for the appalling time-keeping of TV shows.
I've been thinking about the problems associated with scheduling across multiple timers and tuners for a while now. As our household has become more reliant on the BW/Interactive combination and less on the Toppy, I've missed some of the more advanced features of Trapper's TED/s and decided to re-open the whole padding and clashes issue again for further discussion. After all, IceTV tell us that "you’ll never miss a show again", something that is starting to sound a little hollow as the number of channels increase.
First up, I believe that the current Interactive interface is a total failure when it comes to clash detection/notification - the user has to drill down into failed recording only identified by icons and check multiple recordings to conclude that a clash has occurred. What is needed is an in-your-face warning (window or div or whatever)...
"Warning, Danger, Will Robinson!
Clash Detected - some of the following 3 recordings will fail due to schedule overlaps
20:00-21:30, ABC, Series recording, blah blah...
20:30-21:30, C7, Keyword recording, blah blah...
20:00-22:30, Ten, Keyword recording, blah blah..."
(or something like that!)
Clash detection is critical to good scheduling and has the added benefit (for the user) of enabling more accurate/advanced scheduling options. To better understand what overlap issues might occur on the device due to padding you need to know what it is doing - if you can't interrogate the device to get this information then you should interrogate the user. Once you know how the device is configured to behave you can then work with it, rather than against it.
So what is Ice's argument against these advanced features? They seem to tell us that the padding should be left to the device as each is different and there is no guaranteed way to get feedback between the device and Ice. Well I'm sorry, but as a professional software developer of 25+ years industry experience, that sounds like someone has simply placed it in the "too hard" basket without thinking it all the way through. I've worked on many real-time process control systems - scheduling biscuit production across multiple production lines (much harder than you might think!) and controlling steel bloom casting amongst other things - scheduling and padding TV programmes across multiple tuners and devices is not too hard, if there is a willingness to do it. More likely the concerns about additional storage and processing are the main driving force rather than a real inability to perform the task; I'm sorry if that sounds cynical but it is how it appears to me.
So here is my proposal on a methodology which, I believe, would deliver a far more comprehensive scheduling solution using padding within Interactive. I'm happy to admit that it isn't perfect because it relies on the user ensuring that settings in both Interactive and the device are kept in step and being aware of the limitations in the approach, but it is not uncommon in the I.T. industry to have these sort of issues when synchronising between disparate systems - I've done it myself on a number of occasions; the point is that it can be done.
The following outlines how I see the Nirvana of IceTV Interactive, where all the scheduling, padding and clash handling is controlled by Interactive rather than the device and with minimal user intervention. That said, I'm sure you will see how the simpler issue of clash detection and notification is just one component of this design and could easily be implemented as an initial phase in itself, while still allowing for the more advanced features to be added later. By being aware of the users' device settings, Interactive could identify far more potential scheduling problems which could be brought to the user's attention via the Interactive interface and/or other means.
So, on to the design...
When the user adds a new Interactive enabled device (or updates a device) on their IceTV account, they would have the option of setting what the default padding settings are that the device is configured to apply itself, this could be preset to the default values known for each type of device. This is the only critical setting that Ice is incapable of easily determining and which needs to be kept in sync., no other settings are as important. It could easily be hidden away in an Advanced section so that the naive user doesn't play with it unintentionally.
For the naive user who doesn't know to keep Ice and the device in sync. with regard to this setting it will be set to zero padding with no priority (or whatever the device defaults to) and the result will be no different to what we currently have - so no loss there. The more knowledgeable user will appreciate the benefits and keep things in sync. Users who can override the Ice timings on a more individual basis (e.g. Windows MCE) should also be unaffected.
Additionally, the user could specify the DESIRED padding for programs - this will be used by Ice to extend the timers it sends to the device so that it mimics the current situation that the device based padding currently produces. Having set the padding and desired values per device, it is now a relatively simple task to allow for those values when scheduling programs to ensure that the timers that reach the device result in the same recordings that we currently obtain using just device based settings.
Clear as mud? Yeah, ok, perhaps some examples will help.
I normally use -5 min. pre- and +30 min. post-padding with no priority on my B/W - adequate for the late night programmes but overkill for early evening and for manually set programmes when I can set the start and length myself. Under my design I would probably reduce these to -2 and +10 on the device but set the desired padding to -5 and +30 in Interactive. The only thing I would have to remember, apart from keeping these values the same on the device and Interactive, is that locally set timers will have a shorter padding set by default - but I always check them anyway when the screen appears
Hopefully the following scenarios will explain how the Interactive side of things would work.
Device - has -2 and +10 post-padding set, no pre/post priority.
IceTV - has -2 and +10 configured for the device and has -5 and +30 DESIRED padding set, no pre/post priority.
CASE 1 - simple case:
To be recorded...
* Programme 1, Ch.1, 18:00-18:30
Interactive would send the following timer to the Device...
* Ch.1, 17:57-18:50.
This would result in the desired/expected 17:55-19:00 because the device would pad -2 mins. to the start of the timer and +10 mins. to the end, thus mimicking my current -5/+30 padding on my current BW setup.
CASE 2 - slight padding clash:
To be recorded...
* Programme 1, Ch.1, 18:00-18:30
* Programme 2, Ch.2, 18:30-19:30
* Programme 3, Ch.3, 19:00-19:30
While there are no clashes in the programmes themselves, P1 and P3 clash (on a two tuner recorder) with their padding. In this situation, my current BW, with no pre/post priority, would resolve this by recording the following...
* Ch.1, 17:55-19:00 - all padding applied
* Ch.2, 18:25-20:00 - all padding applied
* Ch.3, 19:00-20:00 - pre-padding ignored, starts at programme start time
So the proposed Interactive could send the following timers...
* Ch.1, 17:57-18:50 - results in Ch.1, 17:55-19:00 with the device -2/+10 applied
* Ch.2, 18:27-19:50 - results in Ch.2, 18:25-20:00 with the device -2/+10 applied
* Ch.3, 19:02-19:50 - results in Ch.3, 19:00-20:00 with the device -2/+10 applied
CASE 3 - back-to-back programme clash:
To be recorded...
* Programme 1, Ch.1, 18:00-18:30
* Programme 2, Ch.2, 18:00-19:00
* Programme 3, Ch.3, 18:30-19:30
While again there are no clashes in the programmes themselves, P1 and P3 are back-to-back on one tuner (on a two tuner recorder). In this situation, my current BW with no pre/post priority, would resolve this by recording the following...
* Ch.1, 17:55-18:30 - post-padding ignored
* Ch.2, 17:55-19:30 - all padding applied
* Ch.3, 18:30-20:00 - pre-padding ignored
So the proposed Interactive could send the following timers...
* Ch.1, 17:57-18:20 - results in Ch.1, 17:55-18:30 with the device -2/+10 applied
* Ch.2, 18:27-19:20 - results in Ch.2, 18:25-19:30 with the device -2/+10 applied
* Ch.3, 18:32-19:50 - results in Ch.3, 18:30-20:00 with the device -2/+10 applied
Now one outcome of this approach is that the user would not ever see the recording conflict screen presented on the device/TV - I am going on my experience with the BW and Toppy here, I presume all devices have some form of warning. Perhaps this is not a good thing and we would need to add a one minute overlap in situations of clash to make the viewer aware of the potential problem if they happen to be watching as the timer problem approaches.
Nonetheless, we would end up with the same recordings being made on the device through Interactive controlling the padding that we currently do with Interactive being oblivious to the device settings. The obvious advantage for the users is that Interactive can now be far more proactive in advising the user of potential clashes - via the website, RSS, e-mail or even SMS (for a service cost, of course).
The benefit of this design is that it can be implemented in multiple stages (e.g clash detection first) and allows for further value-adding features...
* Multiple Device Handling - allows the user to nominate a primary device and use the secondary as a fallback for clash resolution, allowing the user to name "Either" as the recording device for a show;
* Prioritise Shows - nominate which shows MUST be recorded and which are to be dropped in an irreconcilable situation (unless the user intervenes);
* Show By Show Padding - allows specific shows to be given extra time, because we know what the networks are like;
* Time Of Day Padding - evening padding requirements should be different to daytime which are, in turn, different to late night, set padding by time of day.
There may, of course, be a number of other new user preferences added to the user profile to record what the user wants to do when clashes are detected but these are likely to be set once and left alone e.g. priority to earlier/later programme, switch at scheduled time, priority to channel(?), priority to new show/repeat, require manual resolution - the options could be quite flexible. Dare I suggest that some of these features could be optional premium services, providing an additional revenue stream to cover the additional data processing and storage overheads required? Nah, we just want it all!
The point is that Ice have a great start point here but users want/need more. While we only had five channels and two tuners it was adequate. Now we have 15 channels - excluding the digital radio (anyone thought of including that!?!) and the new BW which can record external sources such as Fox - and possibility of multiple devices and/or four tuner devices - suddenly Interactive seems not to be coping quite so well.
So there you have it, my Grand Design for what Interactive could be... with a little (ok, quite a lot) more effort. The point is that I do not see this as in any way unachievable, certainly from a technology point of view - this sort of thing is going on all the time in I.T. and I think that this level of control could make Ice a true world leader in EPG technology.
Sorry for the length of the post - let the discussions begin!
I've been thinking about the problems associated with scheduling across multiple timers and tuners for a while now. As our household has become more reliant on the BW/Interactive combination and less on the Toppy, I've missed some of the more advanced features of Trapper's TED/s and decided to re-open the whole padding and clashes issue again for further discussion. After all, IceTV tell us that "you’ll never miss a show again", something that is starting to sound a little hollow as the number of channels increase.
First up, I believe that the current Interactive interface is a total failure when it comes to clash detection/notification - the user has to drill down into failed recording only identified by icons and check multiple recordings to conclude that a clash has occurred. What is needed is an in-your-face warning (window or div or whatever)...
"Warning, Danger, Will Robinson!
Clash Detected - some of the following 3 recordings will fail due to schedule overlaps
20:00-21:30, ABC, Series recording, blah blah...
20:30-21:30, C7, Keyword recording, blah blah...
20:00-22:30, Ten, Keyword recording, blah blah..."
(or something like that!)
Clash detection is critical to good scheduling and has the added benefit (for the user) of enabling more accurate/advanced scheduling options. To better understand what overlap issues might occur on the device due to padding you need to know what it is doing - if you can't interrogate the device to get this information then you should interrogate the user. Once you know how the device is configured to behave you can then work with it, rather than against it.
So what is Ice's argument against these advanced features? They seem to tell us that the padding should be left to the device as each is different and there is no guaranteed way to get feedback between the device and Ice. Well I'm sorry, but as a professional software developer of 25+ years industry experience, that sounds like someone has simply placed it in the "too hard" basket without thinking it all the way through. I've worked on many real-time process control systems - scheduling biscuit production across multiple production lines (much harder than you might think!) and controlling steel bloom casting amongst other things - scheduling and padding TV programmes across multiple tuners and devices is not too hard, if there is a willingness to do it. More likely the concerns about additional storage and processing are the main driving force rather than a real inability to perform the task; I'm sorry if that sounds cynical but it is how it appears to me.
So here is my proposal on a methodology which, I believe, would deliver a far more comprehensive scheduling solution using padding within Interactive. I'm happy to admit that it isn't perfect because it relies on the user ensuring that settings in both Interactive and the device are kept in step and being aware of the limitations in the approach, but it is not uncommon in the I.T. industry to have these sort of issues when synchronising between disparate systems - I've done it myself on a number of occasions; the point is that it can be done.
The following outlines how I see the Nirvana of IceTV Interactive, where all the scheduling, padding and clash handling is controlled by Interactive rather than the device and with minimal user intervention. That said, I'm sure you will see how the simpler issue of clash detection and notification is just one component of this design and could easily be implemented as an initial phase in itself, while still allowing for the more advanced features to be added later. By being aware of the users' device settings, Interactive could identify far more potential scheduling problems which could be brought to the user's attention via the Interactive interface and/or other means.
So, on to the design...
When the user adds a new Interactive enabled device (or updates a device) on their IceTV account, they would have the option of setting what the default padding settings are that the device is configured to apply itself, this could be preset to the default values known for each type of device. This is the only critical setting that Ice is incapable of easily determining and which needs to be kept in sync., no other settings are as important. It could easily be hidden away in an Advanced section so that the naive user doesn't play with it unintentionally.
For the naive user who doesn't know to keep Ice and the device in sync. with regard to this setting it will be set to zero padding with no priority (or whatever the device defaults to) and the result will be no different to what we currently have - so no loss there. The more knowledgeable user will appreciate the benefits and keep things in sync. Users who can override the Ice timings on a more individual basis (e.g. Windows MCE) should also be unaffected.
Additionally, the user could specify the DESIRED padding for programs - this will be used by Ice to extend the timers it sends to the device so that it mimics the current situation that the device based padding currently produces. Having set the padding and desired values per device, it is now a relatively simple task to allow for those values when scheduling programs to ensure that the timers that reach the device result in the same recordings that we currently obtain using just device based settings.
Clear as mud? Yeah, ok, perhaps some examples will help.
I normally use -5 min. pre- and +30 min. post-padding with no priority on my B/W - adequate for the late night programmes but overkill for early evening and for manually set programmes when I can set the start and length myself. Under my design I would probably reduce these to -2 and +10 on the device but set the desired padding to -5 and +30 in Interactive. The only thing I would have to remember, apart from keeping these values the same on the device and Interactive, is that locally set timers will have a shorter padding set by default - but I always check them anyway when the screen appears
Hopefully the following scenarios will explain how the Interactive side of things would work.
Device - has -2 and +10 post-padding set, no pre/post priority.
IceTV - has -2 and +10 configured for the device and has -5 and +30 DESIRED padding set, no pre/post priority.
CASE 1 - simple case:
To be recorded...
* Programme 1, Ch.1, 18:00-18:30
Interactive would send the following timer to the Device...
* Ch.1, 17:57-18:50.
This would result in the desired/expected 17:55-19:00 because the device would pad -2 mins. to the start of the timer and +10 mins. to the end, thus mimicking my current -5/+30 padding on my current BW setup.
CASE 2 - slight padding clash:
To be recorded...
* Programme 1, Ch.1, 18:00-18:30
* Programme 2, Ch.2, 18:30-19:30
* Programme 3, Ch.3, 19:00-19:30
While there are no clashes in the programmes themselves, P1 and P3 clash (on a two tuner recorder) with their padding. In this situation, my current BW, with no pre/post priority, would resolve this by recording the following...
* Ch.1, 17:55-19:00 - all padding applied
* Ch.2, 18:25-20:00 - all padding applied
* Ch.3, 19:00-20:00 - pre-padding ignored, starts at programme start time
So the proposed Interactive could send the following timers...
* Ch.1, 17:57-18:50 - results in Ch.1, 17:55-19:00 with the device -2/+10 applied
* Ch.2, 18:27-19:50 - results in Ch.2, 18:25-20:00 with the device -2/+10 applied
* Ch.3, 19:02-19:50 - results in Ch.3, 19:00-20:00 with the device -2/+10 applied
CASE 3 - back-to-back programme clash:
To be recorded...
* Programme 1, Ch.1, 18:00-18:30
* Programme 2, Ch.2, 18:00-19:00
* Programme 3, Ch.3, 18:30-19:30
While again there are no clashes in the programmes themselves, P1 and P3 are back-to-back on one tuner (on a two tuner recorder). In this situation, my current BW with no pre/post priority, would resolve this by recording the following...
* Ch.1, 17:55-18:30 - post-padding ignored
* Ch.2, 17:55-19:30 - all padding applied
* Ch.3, 18:30-20:00 - pre-padding ignored
So the proposed Interactive could send the following timers...
* Ch.1, 17:57-18:20 - results in Ch.1, 17:55-18:30 with the device -2/+10 applied
* Ch.2, 18:27-19:20 - results in Ch.2, 18:25-19:30 with the device -2/+10 applied
* Ch.3, 18:32-19:50 - results in Ch.3, 18:30-20:00 with the device -2/+10 applied
Now one outcome of this approach is that the user would not ever see the recording conflict screen presented on the device/TV - I am going on my experience with the BW and Toppy here, I presume all devices have some form of warning. Perhaps this is not a good thing and we would need to add a one minute overlap in situations of clash to make the viewer aware of the potential problem if they happen to be watching as the timer problem approaches.
Nonetheless, we would end up with the same recordings being made on the device through Interactive controlling the padding that we currently do with Interactive being oblivious to the device settings. The obvious advantage for the users is that Interactive can now be far more proactive in advising the user of potential clashes - via the website, RSS, e-mail or even SMS (for a service cost, of course).
The benefit of this design is that it can be implemented in multiple stages (e.g clash detection first) and allows for further value-adding features...
* Multiple Device Handling - allows the user to nominate a primary device and use the secondary as a fallback for clash resolution, allowing the user to name "Either" as the recording device for a show;
* Prioritise Shows - nominate which shows MUST be recorded and which are to be dropped in an irreconcilable situation (unless the user intervenes);
* Show By Show Padding - allows specific shows to be given extra time, because we know what the networks are like;
* Time Of Day Padding - evening padding requirements should be different to daytime which are, in turn, different to late night, set padding by time of day.
There may, of course, be a number of other new user preferences added to the user profile to record what the user wants to do when clashes are detected but these are likely to be set once and left alone e.g. priority to earlier/later programme, switch at scheduled time, priority to channel(?), priority to new show/repeat, require manual resolution - the options could be quite flexible. Dare I suggest that some of these features could be optional premium services, providing an additional revenue stream to cover the additional data processing and storage overheads required? Nah, we just want it all!
The point is that Ice have a great start point here but users want/need more. While we only had five channels and two tuners it was adequate. Now we have 15 channels - excluding the digital radio (anyone thought of including that!?!) and the new BW which can record external sources such as Fox - and possibility of multiple devices and/or four tuner devices - suddenly Interactive seems not to be coping quite so well.
So there you have it, my Grand Design for what Interactive could be... with a little (ok, quite a lot) more effort. The point is that I do not see this as in any way unachievable, certainly from a technology point of view - this sort of thing is going on all the time in I.T. and I think that this level of control could make Ice a true world leader in EPG technology.
Sorry for the length of the post - let the discussions begin!