Padding, clashes and multiple devices - how it could be!

[mtb]

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!

[futzle]

In effect you're advocating a striped RAID set of PVRs.

As you say, all things are possible.  What is probably also possible is IceTV extending the device API so that configurable PVR information such as padding settings get uploaded from the PVR to IceTV.  Then the user can't screw it up.

Your assumption about all devices being good about reporting timer failures is unfortunately not supported by the evidence (sorry): EyeTV never reports failed timers back to IceTV; it just happily accepts all of them, and then silently fails to actually perform some of the recordings.  So you'd need to get that fixed.  Given what Elgato support is like, IceTV would have to issue a workaround.  IceTV knowing how many tuners the EyeTV box has would be sufficient.

Not everyone's going to like your suggestion.  Our household has shows which are important enough to my significant other that I make sure that they are recorded in at least two places.  Also, my boxes are in different rooms, and there's no way I'm going to want to record the sci-fi show on the device that is connected to the LCD screen (I like my blacks to be black, thank you).  For the level of configurability I want, it's probably easier for me to just stick with the status quo and fix things manually.  But I am only speaking personally.

I've only really got one question for you.  There are a lot more points of failure with what you're suggesting.  Who'll be handling all of the customer support queries for your scheme? :)

[mtb]

In effect you're advocating a striped RAID set of PVRs.

Erm, no, not for most.  You've picked up on a latter stage option that really needs all the rest to be in place to be of significance.  The multi-device options are quite far down the features list and only for those who have multiple devices (not the majority, I expect) - the top priority is still clash detection at the Ice end of things.

As you say, all things are possible.  What is probably also possible is IceTV extending the device API so that configurable PVR information such as padding settings get uploaded from the PVR to IceTV.  Then the user can't screw it up.

Actually probably not, since that would require Ice to be able to interface on a more complex level with every device - which presumes that each device has a published API and is able to report the required information, far less likely and harder to arrange as it involves multiple manufacturers potentially making changes.  My approach negates this need by relying on just one piece of readily available information being in sync. between the device and Ice.  After all, how frequently do you change your padding settings once set?

Your assumption about all devices being good about reporting timer failures is unfortunately not supported by the evidence (sorry): EyeTV never reports failed timers back to IceTV; it just happily accepts all of them, and then silently fails to actually perform some of the recordings.  So you'd need to get that fixed.  Given what Elgato support is like, IceTV would have to issue a workaround.  IceTV knowing how many tuners the EyeTV box has would be sufficient.

Unfortunately you've not understood me.  I am not at all relying on the device reporting clashes back to Ice, quite the contrary - I am calculating the clashes based on the schedule data and the device's padding information held in Ice (the tuner details is a given).  At no point am I suggesting that the devices communicate with Ice, other than the existing timer and EPG data download from Ice to the device.  

If the devices don't warn the user of clashing programmes, then my approach would provide the user with a nett gain, even if they don't use any of the advanced features - Ice could warn them of a problem that the device won't.  If all Ice do is detect clashes better, then we're all better off - if they can build that into Interactive timers being sent to the device, so much the better.

Not everyone's going to like your suggestion.  Our household has shows which are important enough to my significant other that I make sure that they are recorded in at least two places.  Also, my boxes are in different rooms, and there's no way I'm going to want to record the sci-fi show on the device that is connected to the LCD screen (I like my blacks to be black, thank you).  For the level of configurability I want, it's probably easier for me to just stick with the status quo and fix things manually.  But I am only speaking personally.

I don't expect everyone to, which is why the design allows for continued functioning as things are right now - leave the Interactive padding values at the default (probably -0/+0, no priority) and  no overflow device.

Want a particular recording on a particular device?  No problem - set that device as the one to use and set the multiple device overflow option to None.  When Interactive tries to schedule the timers and detects a clash, it can warn you and let you fix it yourself - if you don't then something will fail... much the same as it would be now, except that you would get a warning from Interactive which you might not otherwise.

I've only really got one question for you.  There are a lot more points of failure with what you're suggesting.  Who'll be handling all of the customer support queries for your scheme? :)

Only one point of failure (assuming the testing irons out all the wrinkles in the code-base) which is the user keeping the the padding values up to date.

I might add that it could be possible to derive the padding from the devices by setting a special timer or two of test length then seeing what length the device reports back. I know the Beyonwiz reports manually set timers back to Ice but don't know about the other devices.  That said, I actually think it would be far more error prone and less reliable than asking the user to provide the padding information that they have set themselves.

Anyway, my system is soooo perfect that there wouldn't be any support calls!  Seriously though, the only thing the support staff would need to confirm with the user is the padding settings, that's the whole point of my design... to keep the user interface simple and to rely on the least amount of (rarely changed) data.

[futzle]

You do need the user to say how many tuners their devices have too.  EyeTV will use all the tuners that you connect to it, and some of those can be single, and some of them can be dual.  For more appliance-like devices like the Beyonwiz, this isn't a configurable option, naturally.

[mtb]

Fair enough, I don't have experience of those so your experience with them is gratefully received.  I guess the same would apply for any MythTV, MCE and other home grown PVR type solution that consumes the Ice EPG and timers.  

Still, I would hope that, for most people, the number of timers on the device would change even less frequently than their padding settings!

[prl]

All this so far assumes that all recording is done through IceTV.

What if I set up some recordings, Ice makes sure there are no clashes, then someone else in the household sets a timer on the PVR between when I set up IceTV and the PVR synchronises with Ice?

How does Ice padding interact with the PVR padding? How do you model the PVR padding?

[mtb]

All this so far assumes that all recording is done through IceTV.

What if I set up some recordings, Ice makes sure there are no clashes, then someone else in the household sets a timer on the PVR between when I set up IceTV and the PVR synchronises with Ice?

...and that is different to your current situation in what way?  How do you currently deal with this?  If you don't know it's happened then something will stuff up, if you do then you work around it (if you can) or someone's recording bites the dust.  At least with my approach the original timers would likely not have been in conflict, before the human mucked it up.

As I have said, my approach is not perfect and there are limitations to what can be done without significant changes to the Ice/device communication layer.  However, the scenario you present is no worse than you already have - the worst case is that this approach maintains the current status quo.

If I currently set a recording manually on my BW, I see it reflected in the Interactive schedule after the next data transfer occurs between the device and Ice - the scheduler would then be able to highlight any issues arising from that timer too (as it currently does, but without knowledge of padding issues).  Obviously if the user intervenes between Ice and the device talking then things may break, but is that really any different to now?  If you blindly make changes to the recordings after Ice has sent its timers down, you currently have to take responsibility to make sure you don't muck things up - it's no different under my scheme except that the Ice timers have greater validity in themselves.  You can currently interfere with timers set by Ice and screw things up by setting conflicting timers manually but you are (or should be) aware of that.

The point is that people who are using Ice Interactive are probably using it to set nearly all of their recordings, or at least a significant portion of them;  I know that we do - if it's more than a couple of hours ahead, we use Interactive, even for one-offs.  If people are not setting most of their timers via Interactive, then they will already be aware of the issues associated with interleaving their own recordings with Ice's.  At the end of the day, if these changes could make conflict detection better, that has to be a gain does it not?

How does Ice padding interact with the PVR padding? How do you model the PVR padding?

Not quite sure what you mean, perhaps the examples weren't clear enough.  The padding values (actual, desired, priority [and tuner count - thanks futzle]) are held as one set per customer device.

If you currently have a device which is set to pad -10/+20 and Ice sets a 30 minute timer at 12:00, the device will pad this out to 60 minutes and start it at 11:50, that's 10 minutes earlier and 30 minutes longer than Ice set the timer for (0:30 + 0:10 pre + 0:20 post = 1:00), ok?
But what if you had your device set for -5/+10 padding and Ice knew this and that your desired padding is -10/+20.  Ice could then send a timer for 11:55 for 45 minutes, knowing that the device would pad it out to the same 11:50 for 60 minutes.  

As formulae, this could be represented as...

TimerStart = ProgrammeStart - DesiredPrePadding + DevicePrePadding
TimerEnd = ProgrammeEnd + DesiredPostPadding - DevicePostPadding

...which becomes...
11:55 = 12:00 - 0:10 + 0:05 => which reaches the device and is pre-padded to 11:50
12:40 = 12:30 + 0:20 - 0:10 => which reaches the device and is post-padded to 12:50

So your 30 minute programme gets recorded as a 60 minute programme starting 10 minutes early, just as it would be currently if you hit record on the programme in the current Interactive.

The advantage is that Ice would be able to better detect if the padding would cause an overlap or not because it would know how the device will pad the timers it sends and will adjust them accordingly - that's what the three examples (are meant to) show.

If Ice doesn't know how the device will pad timers then it has to assume that it won't pad them at all (as is the case right now) and blindly send down potentially conflicting timers... just like it does now!

Obviously there may be some subtleties with some devices that I'm not aware of but I doubt that there would be any real show-stoppers that couldn't be easily incorporated in this design.

[mtb]

The more I think of this, the more I now realise that the desired padding values are actually redundant.  So long as Ice knows how much the device will pad timers it can happily send the values it wants, knowing that, where there is no conflict, the device will pad them accordingly;  where there is conflict the device will address the problem according to its set behaviour, but at least Ice will be aware that conflict will occur and be able to warn the customer.

So all the cr*p below about formulae and desired padding is unnecessary.  Ice will continue to send the same timer values that it does now but the clash detection code will take into account the padding values when it checks for overlaps and only adjusts timer to take account of manually set timers (which have top priority) and any programme priority system that could be included for devices, channels, specific shows and so forth.

[prl]

All this so far assumes that all recording is done through IceTV.

What if I set up some recordings, Ice makes sure there are no clashes, then someone else in the household sets a timer on the PVR between when I set up IceTV and the PVR synchronises with Ice?

...and that is different to your current situation in what way?  How do you currently deal with this?  If you don't know it's happened then something will stuff up, if you do then you work around it (if you can) or someone's recording bites the dust.  At least with my approach the original timers would likely not have been in conflict, before the human mucked it up.
...

It's different from the current situation because the current situation doesn't claim to be able to tell you about clashes straight off.

[prl]

The more I think of this, the more I now realise that the desired padding values are actually redundant.  So long as Ice knows how much the device will pad timers it can happily send the values it wants, knowing that, where there is no conflict, the device will pad them accordingly;  where there is conflict the device will address the problem according to its set behaviour, but at least Ice will be aware that conflict will occur and be able to warn the customer.

So all the cr*p below about formulae and desired padding is unnecessary.  Ice will continue to send the same timer values that it does now but the clash detection code will take into account the padding values when it checks for overlaps and only adjusts timer to take account of manually set timers (which have top priority) and any programme priority system that could be included for devices, channels, specific shows and so forth.

IceTV may be able to warn that there is a potential padding clash, but it can't always say exactly what the consequences will be.

As far as I know, it's not possible to know ahead of time which programs will get the indicated padding in some circumstances. Assuming Beyonwiz, 5 min pre-padding, 15 min post padding, padding priority None (actual programmed timers take precedence over padding):

Seven: 18:00-19:00
ABC1: 19:00-20:00
Nine: 19:00-20:00  Which recording gets its pre-padding over-ridden?

Seven: 18:00-19:00
ABC1: 18:00-19:00
Nine: 19:00-20:00  Which program gets its post-padding over-ridden?

Even from the Beyonwiz GUI itself I don't think it's possible to know what the answers are before the recordings start.

[mtb]

IceTV may be able to warn that there is a potential padding clash, but it can't always say exactly what the consequences will be.

As far as I know, it's not possible to know ahead of time which programs will get the indicated padding in some circumstances. Assuming Beyonwiz, 5 min pre-padding, 15 min post padding, padding priority None (actual programmed timers take precedence over padding):

Seven: 18:00-19:00
ABC1: 19:00-20:00
Nine: 19:00-20:00  Which recording gets its pre-padding over-ridden?

Seven: 18:00-19:00
ABC1: 18:00-19:00
Nine: 19:00-20:00  Which program gets its post-padding over-ridden?

Even from the Beyonwiz GUI itself I don't think it's possible to know what the answers are before the recordings start.

Not quite.  If all those timers were sent currently then you are correct, Ice is unable to determine which gets the padding - the device does that.  

However, under my approach, Ice would know that there is a potential issue approaching and could (a) warn the user so that they could intervene and/or (b) if a priorities system existed, adjust the lowest priority programme's timer so that the device would pad in an anticipated way.  If there are no priorities available then Ice will just send the timers and let the device work it out - no change from the current situation BUT at least you could get a warning!

If nothing else of my system were implemented other than the improved clash detection then you would be in a better position that you are, because Ice would be able to detect potential padding overlaps, which it currently cannot.  As I have said, the full implementation of my approach would be Interactive Ultimate(tm), but padding clash detection would be a massive improvement just on its own.

Given your example programming, which would you prefer...?

"Potential Clash Detected (padding overlap) with the following three programmes:
Seven: 18:00-19:00
ABC1: 19:00-20:00
Nine: 19:00-20:00

...or...

""

...because that's what you currently get unless the programmes actually overlap.  I know which I'd prefer.

It's different from the current situation because the current situation doesn't claim to be able to tell you about clashes straight off.

That's a matter of interpretation of what Ice is about...

IceTV makes recording and managing your TV shows simpler and smarter - you’ll never miss a show again.

[prl]

IceTV may be able to warn that there is a potential padding clash, but it can't always say exactly what the consequences will be.
...

Not quite.  If all those timers were sent currently then you are correct, Ice is unable to determine which gets the padding - the device does that.  

However, under my approach, Ice would know that there is a potential issue approaching and could (a) warn the user so that they could intervene and/or (b) if a priorities system existed, adjust the lowest priority programme's timer so that the device would pad in an anticipated way.  If there are no priorities available then Ice will just send the timers and let the device work it out - no change from the current situation BUT at least you could get a warning!

So you're agreeing with me then :)

It's different from the current situation because the current situation doesn't claim to be able to tell you about clashes straight off.

That's a matter of interpretation of what Ice is about...

IceTV makes recording and managing your TV shows simpler and smarter - you’ll never miss a show again.

That's known to be hyperbole for all sorts of different reasons.

In the case of padding clashes, there are quite common scenarios where if the shows ran to schedule, you could record everything you wanted to, but if they don't run to schedule, even if you know ahead of time what the exact start and finish times are, there's nothing you can do to prevent part of some show you wanted being lost. The only solution in these cases is to use another tuner.

[mtb]

So you're agreeing with me then :)

No, because, as I said, with a prioritising system, you could have a controllable, predictable outcome defined in a rule set.

...but if they don't run to schedule...

Let's be honest, the commercial channels don't, there's no if or but about it.

...there's nothing you can do to prevent part of some show you wanted being lost.

If you've defined such a situation, then you're stuffed whatever... and have to arrange something else, assuming you realise!  But what if you don't?  Wouldn't you like the opportunity to receive some warning of such a problem?

The only solution in these cases is to use another tuner.

If my system were configured to use multiple devices for overflowing and there was a spare tuner on another device then it would cope.

I'll be honest with you, I'm actually surprised at how opposed to the idea you seem to be.  I've yet to see a valid example showing how my system makes anything worse than it currently is and I've been able to show tangible benefits, so why do you appear so negative?

[futzle]

I'll be honest with you, I'm actually surprised at how opposed to the idea you seem to be.  I've yet to see a valid example showing how my system makes anything worse than it currently is and I've been able to show tangible benefits, so why do you appear so negative?

I can't speak for prl, but I'm not trying to be negativeâ€"sorry if we're coming across that wayâ€"I'm merely playing devil's advocate.  If you can knock over my objections then you've got a chance.  If I see a problem, I'll point it out, and give you an opportunity to strengthen your argument.

The way I understand IceTV timers is that they are attached to a show, not a start time and end time.  The information that gets sent from IceTV to the PVR is a show ID, and the PVR goes and looks it up and sets a timer with a start time and end time.  (If I'm wrong, then it's a good illusion.)

Your proposal needs IceTV to send a lower-level information set to the PVR: LCN, start time, end time.  Of course, that's possible, but it's not something that currently happens.  It wouldn't surprise me if every PVR needed a software update to adapt to this change.

I want to reiterate that I'm not saying your plan is a bad one.  But it's a big one.  For changes this big you've got to sell it better than "it doesn't make anything worse than it currently is".  Devil's advocate, remember.

[prl]

So you're agreeing with me then :)

No, because, as I said, with a prioritising system, you could have a controllable, predictable outcome defined in a rule set.
...
I'll be honest with you, I'm actually surprised at how opposed to the idea you seem to be.  I've yet to see a valid example showing how my system makes anything worse than it currently is and I've been able to show tangible benefits, so why do you appear so negative?

I was replying after you proposed using the PVR recording scheduler. That means IceTV has no control over the priorities; it's all up to the PVR. All IceTV can do is try to warn. And I was saying in particular in some cases that IceTV would be able to warn of a problem, but would be unable to tell the user what the actual outcome of some desired recording schedules would be.

Like futzle, I'm not trying to be negative. I know my way around the scheduling problems on the Beyonwiz; I'm the author of the FAQ on the subject on the Beyonwiz forum. The interaction between IceTV and PVRs isn't simple. There are, I suspect, good reasons why the IceTV engineers haven't modelled the scheduling behaviour of of all the PVRs they support. The Beyonwiz scheduler is now reasonably well behaved (but it still has ambiguities in the kind of cases I mentioned), but it wasn't always that way, and had some fairly flakey behaviour in the past. The H1 scheduler still has known problems in some cases. Trying to predict exactly what the scheduler will do in some of the trickier scenarios isn't easy. Even in its correct behaviour, the H1 has some quirks, like being able to do two recordings from the one tuner in some circumstances.

I agree with most of what futzle says, though I'm not sure quite what's exchanged between IceTV and the PVR. The Beyonwiz timer file contains both IceTV id information and times. Even recordings set on the Beyonwiz have IceTV id information. Where's peteru when you need him? :)