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!
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? :)
Quote from: futzle on February 08, 2010, 05:07:48 PM
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.
Quote
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?
Quote
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.
Quote
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.
Quote
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.
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.
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!
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?
Quote from: prl on February 09, 2010, 10:27:33 PM
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?
Quote
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.
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.
Quote from: mtb on February 10, 2010, 02:03:25 AM
Quote from: prl on February 09, 2010, 10:27:33 PM
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.
Quote from: mtb on February 10, 2010, 02:15:47 AM
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.
Quote from: prl on February 10, 2010, 09:46:23 AM
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.
Quote from: prl on February 10, 2010, 09:36:25 AM
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...
Quote from: IceTV about page
IceTV makes recording and managing your TV shows simpler and smarter - you’ll never miss a show again.
Quote from: mtb on February 10, 2010, 12:24:29 PM
Quote from: prl on February 10, 2010, 09:46:23 AM
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 :)
Quote from: mtb on February 10, 2010, 12:24:29 PM
Quote from: prl on February 10, 2010, 09:36:25 AM
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...
Quote from: IceTV about page
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.
Quote from: prl on February 10, 2010, 04:52:40 PM
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.
Quote
...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.
Quote
...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?
Quote
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?
Quote from: mtb on February 10, 2010, 06:29:54 PM
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.
Quote from: mtb on February 10, 2010, 06:29:54 PM
Quote from: prl on February 10, 2010, 04:52:40 PM
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? :)
Ok, I can see where you are both coming from, sorry but it did seem rather negative.
I guess it was the fact that you were both seeming to knock the concept based on the most complex version, which to be fair is unlikely to be given consideration at Ice, without apparently even giving a tacit acknowledgement that at its lowest level, the improved warning would have to be an improvement on what we currently have (or don't). Only last night I had another of those crappy little "Failed" icons and I had to work out what was the conflict.
In the meanwhile I'm going to see if I can't get some more details on what goes to and from Ice and the BW, to confirm if this idea has any more legs in it. I'm certainly not going to give up on the idea of an improved clash screen, even if they don't even include padding clash detection.
All the comments in my last post addressed difficulties in your simplified version. It even says so in the post.
The very simplest version of my approach is the one where Ice is simply aware of the padding settings on the device and can at least identify which programs may cause a clash and highlight them.
QuoteThe interaction between IceTV and PVRs isn't simple."
The interactive between Ice and the device is irrelevant to forward calculating potential clashes - you could identify potential problems seven days ahead of time before the timers have even been sent to the device!
Ice would simply need to be aware of how many tuners a device has and that there will be a certain amount of padding to be applied to all recordings and calculate if these will result in an overlap in the padding. I refer you back to my latter two examples again - I have simulated these via Interactive and while Interactive happily sets them, it later reports one as having failed, but only after the device reports it back. With Ice's assumption of zero padding there are no perceived problems because there is no apparent overlap so nothing is reported to the user, until the device has an issue and reports the problem to Ice (which will probably be too late).
But hey, why not try it yourself...
I've just programmed:
11:30 Trapped (30 mins) Seven
11:30 Message Stick (30 mins) ABC1
12:00 Russian News (30 mins) SBS ONE
...and after the timers were downloaded to the device at 10:55 they ALL showed as valid in Interactive (Red dot) and on the device. Later, however, we KNOW that a conflict will occur (at 11:55) because the padding will come into play - the device will then have to sort things out unless the user intervenes. If the device's padding were known to Ice it could see the potential problem ahead of time and warn the user, as much as seven days ahead of time! We don't need to know HOW the device will fail to satisfy the timers or what tuners it will use or which recording will succeed or fail, we just need to know that something WILL fail to record as expected (or at all).
In an ideal world with perfect scheduling and zero padding necessary, these timers would be fine, but we don't live in that world and we DO use padding and it is obvious that these timers will clash, irrespective of what tuners are used by the device, we KNOW the device will be unable to completely satisfy the timers with padding applied to them all and only two tuners available. We do not have to rely on the device saying it cannot set a timer, we can calculate that fact in advance.
In fact, to try to make this as simple as possible for you, let's pretend padding doesn't exist for a while! It is no different to you having a device with two tuners and no padding set and setting three over-lapping programs (in Interactive). I've just tried that too - when the timers go down to the device the first time, two get set and shown in Interactive as set (red dot), but the third simply remains unset (red donut), it simply didn't set. Only once the device and Ice communicate again later does the failure icon appear, by which time it may be too late... and all this without padding even being drawn into the calculation.
That Interactive cannot even flag this level of obvious, in-your-face, conflict simply and quickly, despite knowing what device I have and therefore how many tuners it has, is pretty pathetic.
I'm sorry, but if you truly cannot see, by knowing what padding the device has set (and the number of tuners), that Ice would be able to more pro-actively warn the user that there may be issues with their recordings due to the device applying the padding it has been told will be applied, then there is little point continuing to discuss this with you.
Yes, there's a padding conflict, yes, it would be better if IceTV warned about this, but I don't know of a way under the present interaction between IceTV and the PVR of IceTV knowing:
- Whether there is in fact a padding conflict - there is none if padding isn't enabled.
- Whether it's Trapped or Message Stick that has the padding conflict.
- Whether non-adajacent programs have a padding conflict (this is a broader version of the first point).
- And in the circumstances you posted, if there are only two tuners available, then there's actually little you can do about the conflict anyway.
I've already posted a number of times in this forum about wanting to have more information about timer conflicts (not padding conflicts). I'm happy for IceTV to provide more information about potential recording problems, including padding conflicts, but there are limits to what can actually be done.
Which comes back to my original idea.
With the exception of some hardware, Ice knows the number of tuners, for the rest they could ask the user.
QuoteWhether there is in fact a padding conflict - there is none if padding isn't enabled.
The whole point of this exercise is get padding included in the conflict calculation, if there isn't any then the user won't have an issues (other than missing most commercial channel programme ends!).
If Ice were to get from the user the correct padding settings (it is the responsibility of the user to set this right and in their best interest to set it right), they could calculate potential issues long before they occur.
QuoteWhether it's Trapped or Message Stick that has the padding conflict.
No! That is irrelevant to detecting the conflict before it occurs!
Conflict: a state of opposition between two or more persons or ideas or interests.
Whether
Trapped or
Message Stick or
Russian News will actually be impacted by the device does not matter because it is the combination of the three items and two tuners which defines the conflict, not one programme on its own. Only once the device has its hands on the timers and processes them can we see which loses and how, but we can see that there is a problem coming up long in advance - how the device handles it is not relevant to conflict detection. Hell, the device could be in the repair shop for all Ice is concerned - Interactive should still be able to identify potential conflicts within its schedule data without even needing to contact the physical device, as long as it has been told what the padding settings of the device should be.
They are all in conflict with each other and it is their combination which is the conflict - a conflict by definition needs at least two parties, a two tuner programming conflict requires at least three timers. All of this can be seen, calculated and resolved without reference to the device. Whether the user deletes a timer, or moves the timer to another device, or drags out the old VCR or phones a friend - it is still a resolution.
If a friend phoned you just before you went out for the evening and asked you to record two programs on at the same time (while you were out), and you had just one two tuner device that already had a recording set for that time (or within the padding overlap) what would you do?
Would you say "yeah, no problem", set the timers knowing one would fail partially or fully and go out, then tell him tomorrow that one didn't record but you knew that? Or would you tell him that you could only record one programme (which one is irrelevant to you) and let him choose which to record and make alternate arrangements for the other?
QuoteI'm happy for IceTV to provide more information about potential recording problems, including padding conflicts, but there are limits to what can actually be done.
From a software development perspective I cannot see any technical reason why Ice could not implement this mechanism of identifying potential conflicts and padding conflicts, if they are willing to request the padding (and tuner count, where unknown) data from the user. It would be in the user's best interests to keep it accurate. If the user didn't provide it, things would continue as they are.
This would not need ANY change to the Interactive/Device interface, none whatsoever. Obviously there would be a small increase in storage per customer device and some slight increase in processing, but that's hardware/infrastructure.
Quote from: mtb on February 13, 2010, 06:46:20 PM
...
If a friend phoned you just before you went out for the evening and asked you to record two programs on at the same time (while you were out), and you had just one two tuner device that already had a recording set for that time (or within the padding overlap) what would you do?
Would you say "yeah, no problem", set the timers knowing one would fail partially or fully and go out, then tell him tomorrow that one didn't record but you knew that? Or would you tell him that you could only record one programme (which one is irrelevant to you) and let him choose which to record and make alternate arrangements for the other?
...
Your example is underspecified, and what I'd say to my putative friend would depend on exactly what the circumstances were.
If the friend wanted me to record two programs that were on at the same time as another program I was recording, than I'd have to say, sorry, I can only do one of the two. Twin tuner PVRs are like that. If the two programs followed the one I was recording, I'd be able to say (with my padding priority setting of None), "That's possible", but I'd probably miss the end of the program I was recording, especially if my recording was on a commercial service. I could adjust my padding priority to preserve my recording, but I wouldn't be able to tell him which program of his would lose its start. If they were both before the program I wanted to record, then I'd have to tell him that I could record them, but one wouldn't record in full, but I had no control over which.
The problem here is really that two tuners aren't adequate for the job they're being asked to do. Nothing in your second simplified proposal changes what I'd tell him in the slightest. All that proposal does is warn me if I didn't notice that the programs had overlapping and conflicting padding. All that your original proposal does is in the case where the friend's two recordings have padding conflicts with mine is to allow him to chose which of his recordings will be missing either their start or end (depending whether they are before or after my recording), if he still wants me to do the recording. The warning of potential conflict, in both your proposals, and the ability to specifiy which padding gets priority, in your more advanced proposal, are the only things that the proposals have to offer in these cases.
There are lots of proposals about how to make padding better, and some of them have some merit, but most of them have problems that are inherent in the fact that broadcasters ton't hold to their schedules, and especially commercial broadcasters follow one program with another imediately, which makes it very difficult to capture complete recordings of everything that you'd be able to do if the broadcasters broadcast according to their schedule and had at least a little "play" between programs. The main purpose of the fiddling with the actual broadcast times and the direct flow of one program to another isn't to frustrate making recordings, but I'm sure that the broadcasters don't mind that it does.
The actual situation is slightly more complicated than what I've described: I've assumed that all three programs are on different services. If that's not the case, I can record everything, but one of the programs will be split over two recordings.
I do actually understand how padding works. :)
I think you and I have taken this as far as we can. I clearly cannot see problems in what you present as problems and you clearly cannot see my solution with the clarity that I see it.
I hope you haven't thought me being condescending, if so that was not my intent... I was merely trying to find some way of presenting to you what I see with total clarity yet you cannot see in the same way. I do not doubt you have a full understanding of padding, though clearly from a different perspective to my own, and if I have offended I offer my apologies.
Unless someone else contributes to this thread I think it will, sadly, fade away. So, as an alternative, I'm going to see if we can't stir up some support for ANY improved clash detection/reporting, even if it is just the way it is presented, by way of a simple poll. Hopefully, if that shows enough interest, perhaps we can get Ice to look at improving things... because it's pretty rubbish at the moment.
There's nothing wrong with what you've proposed. Warning about potential padding conflicts would be useful. It's just that there isn't usually much useful that can be done when they happen. Even adding priority ordering to padding still leaves you with one show of the two that won't be recorded fully. More tuners is really the only solution that works. You have that solution already :)
I think that there are interesting things that IceTV could be doing to help manage recordings across more than one device.
Quote from: prl on February 13, 2010, 10:44:01 PM
I think that there are interesting things that IceTV could be doing to help manage recordings across more than one device.
Sadly I doubt that we are in the majority and therefore would be poorly placed to push for that sort of upgrade, nice though it would be. The two device/four tuner solution is good but not something we would have considered had we not just kitted out the home theatre and got the DP-P2 as part of the deal.
Quote from: mtb on February 09, 2010, 12:19:12 AM
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?
Well, actually I do. ;D I am still using Toppy 5000 with TED/S and am not looking forward to the day when the Toppy dies and has to be replaced, :( because TED seems to do most of what you suggest. (even though there is basically no more support given for TED) I have been known to fiddle with padding to fix a clash, keeping fingers and toes crossed that I chose to remove the padding from the show that will actually finish on time for a change. This was a lot easier when it was likely that one of the programs clashing was ABC or SBS, more likely to be on time, these days choices are a lot more difficult. I definitely would like to be able to set padding for individual shows, according to what channel the show is on, time of day and how important it is to me, etc. I would also
love the idea of a striped RAID set of PVR.
I like all of your ideas, but I do think that it could only work if most of the work would need to be done by the user, not IceTV, basically the same way as TED/S works, leaving the user to decide if they are happy with the status quo, and don't want to (or don't feel confident in) setting anything more complex up. I think IceTV would have to raise their prices quite a bit if they were expected to provide support for this sort of set-up
Quote from: mtb on February 13, 2010, 10:36:51 PM
Unless someone else contributes to this thread I think it will, sadly, fade away. So, as an alternative, I'm going to see if we can't stir up some support for ANY improved clash detection/reporting, even if it is just the way it is presented, by way of a simple poll. Hopefully, if that shows enough interest, perhaps we can get Ice to look at improving things... because it's pretty rubbish at the moment.
I don't use IceTV's padding for my Toppy, but also use MCE as a backup device and find that 9 out of 10 times the padding I have set up in Ice just gets ignored and it uses MCE's padding, which, being about 5 minutes, nearly guarantees that I will miss the end of the program being recorded.
Quote from: prl on February 13, 2010, 10:44:01 PM
I think that there are interesting things that IceTV could be doing to help manage recordings across more than one device.
One thing that I think should be simple and don't quite understand why it can't be done, is to combine two shows if they are following on the same channel. If one wanted to separate them later, it should be easy to do. That way, you wouldn't have the problem of seeing the end of one show on the beginning of the other and the padding would only be needed at the beginning/end of the block of two or more shows.
PerlTGD, the open source alternative for the Topfield 5K that I run on my little SLUG hooked up to the 5K, does just about everything MTB is asking for, in about 2000 lines of perl code. And it supports combining shows (and giving them a combo name) and then uncombining and deleting one if you change the priorities if another clashing show gets in the way (there is a priority scheme from 1 to 10 to support "any show with higher priority will bump any show with lower priority if there is a tuner clash"). It properly supports deleting and adding timers on the PVR to achieve this also, something I am not sure Interactive does properly (quite often a show will move timeslots, and ICE doesn't seem to delete any timers it setup for you for the old timeslot. It does delete at times, so I know the delete will work when sent).
I ported it to the Wiz (using Eric Fry's timer setting engine, wizremote), but given I use ICE and am too lazy to release it formally :), it got about 1 person interested on the Wiz forums. But I always have these hopes that ICE interactive will become a bit more useful over time, and support a few more features like PerlTGD and TED/S has. It did get a pretty decent revamp a while ago with the better keyword options, and the better series options, but it still doesn't go far enough for me to 100% trust I will have the shows I definitely want on my Wiz HDD at the end of a busy week.
These last 2 weeks have been hell (beginning of ratings period I mean), I have spent a lot of time juggling keywords on the 5K and juggling interactive shows on the Wiz to try to make sure the 2 PVRs get everything I want. Now most of the best shows are on SD, I can be happy that falling back to the 5K is not such a bad thing (and my Yamaha amp does a much better job of upscaling the 5K to 1920x1080i than the Wiz does in upscaling SD material), but now I have to work with 2 devices to try to make sure I get everything (and once or twice I work with another, my mega-unreliable Windows7 media centre, which needs the USB tuner to be reconnected after a reboot from time to time, and the internal antenna that is hanging off doesn't always pull in a signal on every channel).
And I know that if I get another interactive capable device, I will still have the issues of juggling independent machines, even on the one Interactive interface! It would be good to be able to set some preliminary preferences like "I have 2 devices, 2 tuners each, allow clash overflow of device 1 to get recorded on device2, allow clash overflow on device 2 to get recorded on device 1"... and then also allow manual settings like now so you can distribute as you see fit amongst the two PVRs (but use colours to distinguish the multiple devices ICE!! Not silly pulldown menus, how can I tell a show is clashing or not at first glance if I only get to see half the picture at any one time!).
My ranting over ;-)
Just to throw in my 2 cents worth of musings here. Just to clarify before I go any further, am I right in understandingt that ICETV does NOT send out time slots, but rather a program ID? If so, it would then of course preclude asking ICVETV to simply add your preferred pre/post padding to a program to be recorded. I think that ICETV does work on program IDs at least on the Topfield 2400/7100+ PVRs, as when a timer is sent to the PVR and there is no EPG data for that time slot, an error message is sent back to ICETV by the PVR and no timer winds up being set at all. Gaps in EPG data are a no no and I think it's becoming clear to me from this that ICETV does not work unless you have data in your EPG. I wonder how well ICETV timers would work with FTA EPG data rather than ICETV EPG data?
Thus, again assuming this to be the modus operandi of how ICETV works interactively with PVRs, it leaves the user to sort out timer conflicts based on his/her padding settings. It's therefore of little use adding timer conflict flags on the ICETV web page - telling ICETV what your padding settings are is irrelevant as it uses/sends program IDs to the PVR and effectively makes the PVR create the timers.
Coming to the issue of using the one tuner for two consecutive programs on the same service, the 2400/7100HD+ handle that by ignoring the post padding on the first program, closing the file at the EPG's end time for that program, and starting the second program with its own file name and then adding post padding to it at the end. I find this way of doing things actually preferable to one continuous file concatinating the two programs ala the way JustEPG does it (even with both file names shown in the title).
What I would dearly like to see though is better handling of 2 devices on the web page. I've contacted Daniel of ICETV about it a couple of times, but so far with no action or hint of a solid commitment. Not sure how we can move forward with this thread and little will come out of it I think, unless we can come up with a fairly simple upgrade to the current way ICETV do things. Make the wish list over ambituous and we will wind up like the wish list for the BeyonWiz - so overwhelming that you just make people give up before they even start.
Quote from: JPP on February 14, 2010, 04:43:04 PM
Thus, again assuming this to be the modis operandi of how ICETV works interactively with PVRs, it leaves the user to sort out timer conflicts based on his/her padding settings. It's therefore of little use adding timer conflict flags on the ICETV web page - telling ICETV what your padding settings are is irrelevant as it uses/sends program IDs to the PVR and effectively makes the PVR create the timers.
I can't totally agree. At the moment, Ice gives essentially no indication of a conflict at all, unless it reports back an issue reported by the device (which all may not do). This would be far more useful to the user in avoiding clashes than them hoping they see them.
Since Ice do know when the programmes all start and end (they have the EPG data after all), it would be no hard task for them to clearly indicate a conflict has arisen e.g. if P1 start = P2 start = P3 start then error. If this is implemented then it is only a short way from including data about padding to improve that further.
All of this would be essential for multi-device handling to be of true benefit. There would be little point Ice knowing about your second device if it didn't use it because it didn't see the conflict that was going to happen in the padding but not according to the "pure" programme times.
If, as appears to be the case, Ice uses Id's for programming then I can now see how a single device's timers cannot be manipulated fully in the way I had hoped. However, with additional tuners available via other devices, it would be far easier to avoid conflicts if the padding on each device is known so that Ice could separate the timers on each device as far as necessary to minimise padding overlap. Sure, this can be done without but it would be more accurate with, and would allow for greater flexibility in user priority handling.
Quote from: JPP on February 14, 2010, 04:43:04 PM
Just to throw in my 2 cents worth of musings here. Just to clarify before I go any further, am I right in understandingt that ICETV does NOT send out time slots, but rather a program ID? ...
Timer entries on the Beyonwiz contain an IceTV 64-bit program id if IceTV is enabled, even on shows that were programmed on the Beyonwiz. For more details about what gets sent, we'd probably have to ask peteru, who designed the PIMP protocol that underlies IceTV. I don't think they contain the program id information from the FTA EPG, but I'm not sure.
PS: It's
modus operandi, not modis.
Quote from: prl on February 14, 2010, 07:11:30 PM
PS: It's modus operandi, not modis.
Cheez...too slow again. Time to put in the Peter spelling checker... :). Fixed it up your honour.
I think Peter is under an NDA. We've hinted, asked and even begged him outright, to tell us at least something about the protocol, but a stony silence from him and ICETV is what we've so far always been met with :'(.
Quote from: JPP on February 14, 2010, 07:52:32 PM
Quote from: prl on February 14, 2010, 07:11:30 PM
PS: It's modus operandi, not modis.
Cheez...too slow again. Time to put in the Peter spelling checker... :). Fixed it up your honour.
I think Peter is under an NDA. We've hinted, asked and even begged him outright, to tell us at least something about the protocol, but a stony silence from him and ICETV is what we've so far always been met with :'(.
:)
I think you're right about Peter being under an NDA, but he does sometimes give some hints about capability of the protocol.
Quote from: tonymy01 on February 14, 2010, 12:17:45 PM
It would be good to be able to set some preliminary preferences like "I have 2 devices, 2 tuners each, allow clash overflow of device 1 to get recorded on device2, allow clash overflow on device 2 to get recorded on device 1"... and then also allow manual settings like now so you can distribute as you see fit amongst the two PVRs (but use colours to distinguish the multiple devices ICE!! Not silly pulldown menus, how can I tell a show is clashing or not at first glance if I only get to see half the picture at any one time!).
My ranting over ;-)
Well, at least we're dreaming of the same thing! ;D Except you have more of a chance of your dream coming true than I do, - you know code! :( ::) :P
As I've whined and complained about in other threads I would love it to be like this.
* IceTV knows how many tuners I have. Either because it knows from what device I've selected in setup or I've told it.
* If it detects a possible clash (either through programming or from a show returning or moving) it sends an alert letting me know the details. Either the next time I log onto the site or an email alert.
That's it.
I've never really had a problem with clashing shows as I've kept an eye on it. But these new digital channels with their blocks of repeating shows have started to make it harder.
Plus given I've always got a backlog of taped shows I rarely watch live TV. So I'm starting to lose track of what shows are on what nights without looking it up. So I no longer have a feel for where clashes might occur.
Quote from: grahford on February 16, 2010, 01:38:27 PM
Plus given I've always got a backlog of taped shows I rarely watch live TV. So I'm starting to lose track of what shows are on what nights without looking it up. So I no longer have a feel for where clashes might occur.
Yep, same here. I have a pretty serious backlog at the moment, 620G arghhhh (420G Wiz, 200G 5K, mind you, some of this is movies I might watch one day).
Quote from: tonymy01 on February 16, 2010, 02:59:48 PM
Quote from: grahford on February 16, 2010, 01:38:27 PM
Plus given I've always got a backlog of taped shows I rarely watch live TV. So I'm starting to lose track of what shows are on what nights without looking it up. So I no longer have a feel for where clashes might occur.
Yep, same here. I have a pretty serious backlog at the moment, 620G arghhhh (420G Wiz, 200G 5K, mind you, some of this is movies I might watch one day).
Yeah, I think we all need treatment, go to one of those American rehab centers for addiction. ;D I keep recording shows, when the hard drives are full I burn them, yet still no one has invented more hours in the day, which would be the only way for me to ever catch up. I suppose, when I move into the nursing home, with no Toppy, etc, I may have time to catch up :-\ ;D Maybe I shouldn't even admit this, but I religiously tape the Bold & the Beautiful every day :-[ (my excuse is that I was laid out with glandular fever when it first came on and had nothing else to do, by the time I went back to work, I was addicted) then burn them, although I haven't actually watched an episode for years (except for the bits I see while burning it - which is probably enough to keep in touch with what's going on ::))