Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - mtb

Pages: [1] 2 3 ... 11
IceTV EPG Content / Re: Covert Affairs - Monday October 18th
« on: October 19, 2010, 02:08:40 AM »
Could you please note the message above the post editor
Please note: these forums are not constantly monitored by IceTV Support Staff.
and ensure to send this corrective information via the Contact Us page as directed - do not rely on posting EPG corrections here.

Clearly Ice were not aware of this and only set a single episode timer, looks like I'm on download duty to get the missed middle section (the timer had finished before we realised)!

IceTV EPG Content / Re: Channel 31
« on: October 14, 2010, 07:25:41 PM »
WestTV (Perth Ch31) is now appearing in the EPG on our beyonwiz, via Ice.  Nice one folks.

I had previously communicated with both WestTV and Ice and understood it to be a "simple" case of WestTV getting the data to Ice in a suitable format for Ice to use, clearly this has now occurred or Ice have started compiling it themselves as suggested by Mitch.

The only hole remaining for us is that WestTV does not yet appear as one of the channels in Interactive, so we cannot yet schedule programmes via the site.

Getting there though....

Smart Recording on Android / Re: Feedback for Android app.
« on: September 28, 2010, 01:01:51 PM »
First up, sorry but I don't think this is beta quality, it's more of an alpha or late proof of concept... there are too many missing features.  You seem to have fallen for the Microsoft approach of pushing out an incomplete product and letting the users do the testing for you.  This is certainly how I felt about the first version you released and the second one is only a small improvement on that - just my personal opinion as a developer with twenty(mumble) years at the keyboard.

Ok, with that out of the way, a number of issues and comments...


Sign up: Selected Existing Member, entered credentials and press Login, entered a name for the device and pressed Approve, pressed Back as instructed - the app. simply exits.  Checked web site and device is listed.  Tried to run app. again, it wants me to select New or Existing again, entered credentials and press Login, didn't enter a name for the device and pressed Approve, pressed Back, it exits again.  There are now two device Tokens listed on the site, one without an identity.  Try running the app. again, it finally loads.  Have tried this a couple of times and had mixed results.

Sign up: device shows the New/Existing Member screen, Back button just redisplays the same screen again and again instead of exiting.

Tried running the app. without a data connection - it appears that if the data is old, it displays a none too helpful error dialog (certainly doesn't explain that it can't get data).

Schedule a programme from the device with no data connection.  The app. doesn't give any obvious indication whether it has or has not been able to schedule the programme, no error or warning... the programme simply doesn't schedule (as checked on the website).  It doesn't seen to cache the request either as restoring the connection and scheduling something else doesn't cause both to schedule.

Deleted Token from website, app. was still able to run and set programmes - very poor from a security point of view.


Popup (long-press) menu on a programme, with quick record/delete options, would be VERY useful.

Time-bars between programmes should include the day and date, not relying on the filter at the bottom.

Programme entries have a lot of wasted space which could display (user optional?) additional info. (end times/duration, repeat).

Displaying start (and end) times for programmes and hiding time bars between programmes as an alternative display style would save on a lot of wasted space.

Scroll buttons do not scroll beyond current selected day but are not disabled when limit reached.  Need to be able to scroll over date boundaries (more than an hour) in one continuous scroll, not have to stop, change filter, then restart.

Channel filter also needs Networks as well as channels.

Recording a series, the Network filter should also include Channels!  This is again inconsistent with the Channel filter which is used for filtering but is probably because the web site is equally inconsistent.

Time option in series recording dialog operates differently to the web site, only offers time(s) of the show on the current day whereas web site offers list of five minute intervals - both should offer the same, preferably a user configurable time range or at least hourly slots.

How about an all devices button? - the same applies to the web site.

I too have found, when looking at data late in the evening after nine/ten, that the day/date seems to get out of step, but then I've also seen this on the main website.  Seems to get confused by the time zone here in Perth.  I guess I'm just used to it!

Cancelling recordings is not obvious or consistent - selecting the "Episode queued to record" entry is obscure - there should be an explicit option (in the previously mentioned popup menu too).  The approach seems to vary according to if it is a series or single recording.

Deleting a recording doesn't remove the icon from the guide.

Refresh button is needed desperately.

Home screen icon order seems confused - things like Store should be near the bottom and My Week, My Shows should be higher.

Smart Recording website and General questions / Re: Junk Show Filter
« on: February 14, 2010, 06:54:21 PM »
I do that already... by hiding Seven, Nine and Ten!

Seriously though, while the idea has some merit, it would be far more difficult to select the data and render the guide leaving holes everywhere than it is to simply add an icon.  I do sometimes simply filter down onto one channel or Network to make browsing a little easier but usually I just search as I already have an idea what I'm looking for.

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.

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.

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.

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.  

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.

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?

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.

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

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.

So you're agreeing with me then :)
No, because, as I said, with a prioritising system, you could have a controllable, predictable outcome defined in a rule set.

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

...there's nothing you can do to prevent part of some show you wanted being lost.
If you've defined such a situation, then you're stuffed whatever... and have to arrange something else, assuming you realise!  But what if you don't?  Wouldn't you like the opportunity to receive some warning of such a problem?

The only solution in these cases is to use another tuner.
If my system were configured to use multiple devices for overflowing and there was a spare tuner on another device then it would cope.

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

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



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

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

That's a matter of interpretation of what Ice is about...
Quote from: IceTV about page
IceTV makes recording and managing your TV shows simpler and smarter - you’ll never miss a show again.

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.

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

What if I set up some recordings, Ice makes sure there are no clashes, then someone else in the household sets a timer on the PVR between when I set up IceTV and the PVR synchronises with Ice?
...and that is different to your current situation in what way?  How do you currently deal with this?  If you don't know it's happened then something will stuff up, if you do then you work around it (if you can) or someone's recording bites the dust.  At least with my approach the original timers would likely not have been in conflict, before the human mucked it up.

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

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

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

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

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

As formulae, this could be represented as...

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

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

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

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

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

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

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!

Pages: [1] 2 3 ... 11