Author Topic: Padding, clashes and multiple devices - how it could be!  (Read 10304 times)

Offline mtb

  • Senior Member
  • ****
  • Posts: 152
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #15 on: February 13, 2010, 12:25:53 AM »
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.
Beyonwiz DP-P2, Epson EH-TW5500, Pioneer VSXLX52 & BDP-320, Screen Technics 100” screen, WD Live TV x2, 6Tb NAS (Linux)
Beyonwiz DP-S1, VIERA TH-42PA60A
HTC Desire (rooted) Froyo
Topfield 5000MP

Offline prl

  • Guru
  • *****
  • Posts: 3140
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #16 on: February 13, 2010, 09:25:14 AM »
All the comments in my last post addressed difficulties in your simplified version. It even says so in the post.
Peter
Beyonwiz T4 in-use
Beyonwiz T2, T3 & T4 for testing

Offline mtb

  • Senior Member
  • ****
  • Posts: 152
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #17 on: February 13, 2010, 02:39:28 PM »
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.  
Quote
The 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.
« Last Edit: February 13, 2010, 02:41:48 PM by mtb »

Offline prl

  • Guru
  • *****
  • Posts: 3140
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #18 on: February 13, 2010, 04:17:50 PM »
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.

Offline mtb

  • Senior Member
  • ****
  • Posts: 152
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #19 on: February 13, 2010, 06:46:20 PM »
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.  

Quote
Whether 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.

Quote
Whether 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?

Quote
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.
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.
« Last Edit: February 13, 2010, 06:54:15 PM by mtb »

Offline prl

  • Guru
  • *****
  • Posts: 3140
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #20 on: February 13, 2010, 07:31:47 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. :)

Offline mtb

  • Senior Member
  • ****
  • Posts: 152
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #21 on: February 13, 2010, 10:36:51 PM »
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.
« Last Edit: February 13, 2010, 10:39:04 PM by mtb »

Offline prl

  • Guru
  • *****
  • Posts: 3140
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #22 on: February 13, 2010, 10:44:01 PM »
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.

Offline mtb

  • Senior Member
  • ****
  • Posts: 152
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #23 on: February 14, 2010, 12:51:49 AM »
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.

Offline csutak40

  • Guru
  • *****
  • Posts: 1096
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #24 on: February 14, 2010, 02:58:00 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
Cheers,
Judy
Windows 7 Media Center; Last Update Feb 20 2006; Beyonwiz T4, T2

Offline csutak40

  • Guru
  • *****
  • Posts: 1096
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #25 on: February 14, 2010, 03:10:53 AM »

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.

Offline csutak40

  • Guru
  • *****
  • Posts: 1096
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #26 on: February 14, 2010, 03:18:14 AM »
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.

Offline tonymy01

  • Guru
  • *****
  • Posts: 740
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #27 on: February 14, 2010, 12:17:45 PM »
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 ;-)
Regards
Tony

Beyonwiz DP-S1 & Topfield 5K (using PerlTGD to upload ICE EPG/timers for the 5K, normal ICE interactive for the Wiz).

Offline JPP

  • Guru
  • *****
  • Posts: 386
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #28 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? 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.
« Last Edit: February 14, 2010, 07:37:55 PM by JPP »
Phil.
Beyonwiz T2, DVDO Duo Video Processor

Offline mtb

  • Senior Member
  • ****
  • Posts: 152
    • View Profile
Re: Padding, clashes and multiple devices - how it could be!
« Reply #29 on: February 14, 2010, 05:25:31 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.
« Last Edit: February 14, 2010, 06:46:34 PM by mtb »


Share via facebook Share via twitter