Timer Padding & Joining schedules

[wimpy]

Could ICETVE look at putting in timer padding and have the timers join if there on the same channel after each other eg.  Like it did with TEDS for topfields.
As if you want to watch a show that’s after your first recording the last thing you want to see the end of the first program. All different platforms handle timer padding differently. So if it was done at the ICETV end it would make the product work the same for all and be able to check timer conflicts.

Yes I was just wanting the same functionality as TEDS has for this, no matter where the data comes from. This would make using ICETV with what ever hardware you have behave the same. This would not have to be hard codded in, but give you the option to use it. And after talking to the Beyonwiz support line, it was my impression that it would have to be and ICETV function? Does anyone know if there are applications that could be written to run on the beyonwiz? Like what the topfields used to have?

[tonymy01]

TEDS has nothing to do with ICE (well, John gave it the ability to use an ICE subscription to get the EPG XML data only).
Regards

[prl]

TEDS has nothing to do with ICE (well, John gave it the ability to use an ICE subscription to get the EPG XML data only).
Regards

I think wimpy just wanted the same functionality as TEDS has for this, no matter where the data comes from.

[Gary]

Combining consecutive timers would be a great addition to functionality.

[tonymy01]

Yeah, I interpretted his "Like it did with TEDS" to mean "Like ICE did with TEDs"... ICE wouldn't have a clue what TEDS was really (well, I am sure they have heard it in passing of course)...  but re-reading I suppose it could mean "Like combining timers did with TEDs".   I think combining timers is probably a good idea, and some kind of timer priority system too.
Regards

[futzle]

Could ICETVE look at putting in timer padding and have the timers join if there on the same channel after each other eg.  Like it did with TEDS for topfields.
As if you want to watch a show that’s after your first recording the last thing you want to see the end of the first program. All different platforms handle timer padding differently. So if it was done at the ICETV end it would make the product work the same for all and be able to check timer conflicts.

I don't see this as IceTV's responsibility.  I think IceTV staff are on record as feeling the same way.  Here's why:

Every PVR has different capabilities with respect to concurrent timers.  Some can record one timer at a time, some can record several channels if they are multiplexed on the same frequency.  Some have two tuners all the time, some have two tuners only when you aren't watching something previously recorded.  Some can have a timer finishing and another starting on a different channel at the same time, some need a minute in between to get themselves in order (TF5000s differ in this depending on which firmware they are running!).

With this kind of complexity, I'm not surprised that IceTV pushes the problem down to the PVR (or its proxy, as TEDS is).  What I *would* like to see is an addition to the IceTV Interactive API where a PVR could mark a recording as "not going to happen" because the PVR knows it can't fulfill the combination of concurrent timers (or because the hard disk is full, or ...).  At least the user will know there's a problem when they next log into IceTV Interactive.


Edited: What I *would* like to see is EyeTV implementing the feature in prl's message.

[prl]

...What I *would* like to see is an addition to the IceTV Interactive API where a PVR could mark a recording as "not going to happen" because the PVR knows it can't fulfill the combination of concurrent timers (or because the hard disk is full, or ...).  At least the user will know there's a problem when they next log into IceTV Interactive.

It does, at least for timer conflicts. You get a against the timer. I'm not sure that many PVRs are capable of telling IceTV that a recording will overfill the disk.

[Daniel Hall at IceTV]

...What I *would* like to see is an addition to the IceTV Interactive API where a PVR could mark a recording as "not going to happen" because the PVR knows it can't fulfill the combination of concurrent timers (or because the hard disk is full, or ...).  At least the user will know there's a problem when they next log into IceTV Interactive.

It does, at least for timer conflicts. You get a against the timer. I'm not sure that many PVRs are capable of telling IceTV that a recording will overfill the disk.

Actually the error message icon that shows up is for any error that is received from an Interactive device, not all devices correctly identify the reason for the failure though, for the ones that do though we are trying to have to this information be reflected in the website.

[j s]

Actually the error message icon that shows up is for any error that is received from an Interactive device, not all devices correctly identify the reason for the failure though, for the ones that do though we are trying to have to this information be reflected in the website.

I have also seen instances where Interactive has successfully created a timer on a BW then later flags an error, presumably trying to set the same timer again which naturally fails because it already exists.

[grahford]

The lack of consecutive scheduling is a killer for my wife.  She only lasted a week on our 4400 before she gave up recording individual shows and started manually setting the timer to record blocks of shows.

I'm actually on the forum now at her request to see if there is a way to do it with icetv (we only got it yesterday with our new topfield).  If it can't be done she is going to go back to updating the timer manually each week with a paper tv guide :(

[mtb]

Could ICETVE look at putting in timer padding

Just revisiting this thread it occured to me that this could become difficult to maintain on devices which also have padding built in, such as the beyonwiz, or via local software such as TED/s.  You would have greater opportunity for timer clashing if the Ice schedule adds some time and then the device/software does the same, making the timer excessively long.  If you don't enable padding on the device then manual recordings will not be padded, but if you do enable it you have issues with excessive length timers - neither is ideal.

Unless Ice are to able to cater for device padding on an individual device-type/customer basis and adjust timer lengths to cater for (any) local adjustment as well as server padding, in a simple to understand manner, then server-side padding will be very hard to implement.

[Gary]

I agree - I don't think it should pad but I would like better ways of prioritising which timers get created and joining consecutive ones.

[Marc]

How would you expect a device to name and tag a joined timer?

[Gary]

How would you expect a device to name and tag a joined timer?

I was thinking that IceTV could do that by recognising that there were consecutive timers to create and in its place sending a single timer for the combined length and named in combination as well, eg House+NCIS or something like that.

Obviously it needs to be a setting that users can choose to have that as a default or not, etc.

[Marc]

I'm not avoiding the question, but this does feel like something that might be better handled by the PVR itself. Only the PVR will know how many free tuners it has, if padding can be applied in full and exactly where conflicts lie (I assume the purpose of combining timers is to free up a tuner so it can be used for other things).

Is this something that you (wimpy, gary) would like to see happen automatically all the time? Or only as a special case where you decide when to combine timers?