Messages

Pop-up | Timer List | Red button

Set the Start Time and Duration and change the Recurrence to Daily.
Go down to Mode and use < > to change to View.
Go down to Accept and press OK.

I would suggest a duration of at least five minutes, perhaps ten.  The unit should now turn on daily at the required time to allow the updates to occur. 

One side effect that you might want to consider when choosing the time of day for the view timer, if you are watching the unit when the view timer ends it might turn off the device.  Admittedly we've only had the P2 for a few days but this is based on the behaviour of our S1 - I haven't nailed the exact circumstances but have seen this a number of times.  I would therefore recommend setting it about three in the morning if you don't want to risk this happening when you're watching during the day.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[not]

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!

Up until today we didn't have multiple Interactive capable devices, so the nuances and idiosyncrasies of scheduling across multiple devices were unknown to us - not any more!

The first thing that struck us was the requirement to have to repeatedly select the device to be used for each operation.  I appreciate that setting timers might be something that you need to stipulate a device for (though, now we have two BW, we can stream between so it isn't a problem) but I think that the TV Guide and My Upcoming Shows are in desperate need of an "All" device view, particularly since My Shows already has this feature.  Having to flick between devices to view the recordings set in TV Guide and My Upcoming Shows is akin to having to swap newspapers for each device to see what you've highlighted - it's positively arcane.

I would also like to see a default device setting, rather than it using the currently viewed device.  More than that, however, I should like to see options to use multiple devices to overcome scheduling issues i.e. you have a clash and it offers you a simple one-off "push to other device" function, or better still it does it for you.  I'd far prefer to have to use the other recorder to see a programme (as we have done with the old Toppy, recording manually), rather than miss it

It would be great if you could mark the shows you are not interested in as hidden, that way when you are browsing through the guide you will not see anything marked as hidden. ie I have no interest in 80% of the content on tv .

Hmm, interesting... I like that idea, though it might be better if it greyed out (and smaller font?) those titles rather than truly hiding them as the guide could become very difficult to generate/read.

Alternatively, I think just removing seven, nine and ten channels might achieve a similar result!

A simple way to regularly refresh the data while you are out/at work and the device is off is to set a daily repeating non-recording timer to turn it on for about five minutes, perhaps at midday or mid afternoon, so you can programme remotely, confident it will refresh its EPG and timer data then go back to power saving mode until required to wake and record.

[might]

So if someone thinks that it would be too hard/messy to solve 100% of the problem by removing or substituting all special characters then surely it would help meet user needs to just deal with the colon. And it may be that the solution to at least this part of the problem does not have to involve software development at all - just ask whoever it is that types in the colon not to.

Ok, for such attributes as "Movie:" or "Sport:" which are 'value added' to the EPG there could be grounds to say that the EPG should not include the ":" character because it might cause problem on some devices, but only the ones which use the show name as file name and use the more limited file systems.  Nonetheless, you are still left with the issue of how to deal with scenario where the actual program name includes a character which is illegal on some potential target file system but not necessarily on the one on which the file is recorded/created;  to list the program name incorrectly will cause far more headaches for the majority of users (many of whom may not ever copy the files off their devices) than the occasional bad character appeaing for the minority who do and for whom there is a relatively simple workaround.

For those devices which use the show name in an unmodified form for the filename - for the sake of clarity, perhaps - there will always be the opportunity for some obscure character to get in there;  screen writers seem to be becoming more creative all the time with show names, just wait for the first episode of $@^*?<>!= {(c) mtb 2009} to appear.

This is not really an Ice issue, if anything it is an issue you should take up with the PVR manufacturer since it is their choice how they name the files.

I've had a reply from CompNow. They said a condition of the competition was that you had to go to a CompNow store to collect the prize (should you be lucky enough to win), and have your photo taken for publicity. neither of these are in the Competition Terms and Conditions. My question about not being able to supply a non-NSW or Vic address wasn't answered. I've replied requesting clarification.

I think that both CompNow and IceTV should be a lot clearer about the entry requirements for the competition.

CompNow could be in a lot of trouble over that since they are running the competition.  If it isn't in the T&C then, legally, they cannot make these "new" conditions stick and the competition is therefore open to all comers - otherwise they can be done for misrepresentation. 

[Any time]

When setting a Series recording from the TV Guide, the time options are Any time or This time only, but when adjusting the recording, the drop-down shows Any time and all 5 minute time slots from midnight to midnight.

While I can understand the reasoning behind this I just wonder if it might be better to include a time range option as well, either as two drop-downs (from and to) or even a series of preset bands (e.g. midnight-6am, 6am-noon, noon-6pm, 6pm-midnight).

I only ask as my wife wants me to record the last showing of a particular show that appears multiple times per day - setting by the exact hour/minute seems prone to fail over time, if the show were to wander a little.

I simply added my state to the postcode field.

I also saw the bit about the newsletters.  Fortunately, since I own my domain, I create an email address for each site I register on - if I don't want to receive emails from them (and can't stop it the correct way) I can simple filter or drop the email address... problem solved.

Seems the competition is only open to NSW or VIC residents, either that or the website has a problem - the State drop-down only shows NSW and VIC.

Closed protocol. Long-promised API not yet made available.

Sigh...

... Definitely is different though, Sam in the US version kind of slowly builds a report with the team, where as in the UK version he is always battling DS Ray Carling and certainly Gene to a lesser amount.

According to an article I read recently, the writer/creator of the UK series has pretty much disowned the US series.  Seems the premature end of the UK Life on Mars was brought about by the lead actor John Simm) not wanting to do a third series.  Seems they are about to film a third series of Ashes to Ashes, which is promised to be the last and which will tie off many of the loose ends in both series.

[This show matched the Keyword Favourite: "the simpsons" -treehouse]

You should now be able to see which Keyword Recording or Keyword Favourite was used to schedule a show.  When you see the and icons, click the show to open it, and you'll see a line like this:

  This show matched the Keyword Favourite: "the simpsons" -treehouse

And the keywords will be linked to the matching entry on your My Shows page.

For series recordings, you'll see something similar, with a link to the series recording entry on your My Shows page:

  This show is part of a series recording.

Give it a try.

Thanks,
Russell

It's excellent, really excellent, works like a charm.  I know it's pushing it a bit... any chance of including it in the RSS feed?  Not the link, just the text would do.

Donuts, or fully enclosed?

Fully coloured red circle, not doughnut..  ;)

That would be a jam donut, as opposed to a ring donut then?