Only for the broadcasters ... The 9200T side is simple.

Workarounds to a defined system.

Who says they don't loose interest in supplying the meta data & anyway not everyone supplies it.

Its obvious just by looking at the EPG.

No ... as the functionality already exits there's nothing to add.

Thats the FP2 functionality!

Why should they add workarounds to their implemented functionality (FP2) to address the issues of third parties.

Why not if it means better customer satisfaction leading to stronger sales?

Padding around scheduled broadcast times was implemented in the first place to fix failures of broadcasters to work to a defined system - i.e., the published schedule

If broadcasters can't (or won't) broadcast AR data accurately then the solution that would most suitably meet customer requirements would be to implement an AR system with auto-padding (or maybe auto-padding of published broadcast times with series linking included).

Auto and manual padding already exist.

Workarounds to FP2 is stupid and unnecessary functionality creap.

The following document might help to explain some of the variations between published and actual times:

Fitting in the 90 second summary at 8pm means some changes to the schedule to stop later programmes over-running. It's being done by cutting the 6- 7pm newshour by 30", half from regional news, half from network

The 6.30pm programme will be 15” shorter from now on. The programme finish time will therefore be: 18.56:30" - a total running time of 27' 45" (the 6 will finish at 18.28.45")

I can't check at the moment, but does the EPG now include the BBC1 8pm summary as a separate item? It'll be interesting to see what AR does.

As has been said many times before, autopadding is fine until faced with a conflict, and that's when it would be helpful if programmes didn't stray outside their published slots.

I don't see what's "stupid" about addressing a real-world problem with an enhancement which would overcome a serious shortcoming in the implementation of the specification.

Why do you have such strong objections to extending the functionality to improve how things work? I thought one of the main reasons for having forums such as this one was to discuss what we'd like to see in terms of new functionality (or as you call it, "functionality creap")?.

This isn't a case of "if it ain't broke don't fix it". Anyone who's tried AR knows that it is broke and it needs fixing!

Hi


I can't understand why we need a 90 second news slot. You can check all the latest news in around 60 seconds by pressing RED, something the BBC keep telling us about, and it can be done at our leisure.

What is also more incredible is they gain the extra time by cutting it from other news programs. Surely the time could be gained by reducing the amount of trailers the BBC show during programs?

Is the BBC run by clowns? The amount of resources that must go into just producing a 90 second news slot surely can not make it worthwhile?

Back on topic, it will be interesting to see if this shows in the EPG and just how they cope with accurate recording around it. Wonder if it comes up with series link

Regards

Phil

What's so difficult about the Humax using AR if the data's available and automatically falling back to AP if it's not?

I'd love to know what the FP2 specs actually say about stations that don't broadcast AR data (link anyone?).

I suspect, without a shread of evidence, that Humax's inablility to have both is more due to a hardware limitation (ie short on memory) that a "cast in stone" FP2 spec.

Unless all stations include AR data, the inability to have both makes AR near enough useless.

John.

I thought it was more a business decision. Humax can keep sellling the 9200 as a "new" Freeview Playback machine. To do this they need to implement the Playback spec, they do not need to integrate Playback with Auto-Padding.

It costs money for Humax to update the software. They have presumably calculated that the cost of implementing Playback and Auto-Padding is more than the profits from any extra hardware sales they would make.

Hi


Just a note that there is no accurate recording data. No new data is transmitted for accurate recording.

To implement accurate recording, the PVR looks at the Now/Next data that we have always had, and if it sees the program to record appear as the "Now" program it records, and stops when the program is no longer shown as being on Now.

Traditionally the Now/Next data just changed automatically with the time, and still does for many channels.

To make accurate recording accurate, the Now/Next data that was up to now automated, has to be separated out by the TV companies and updated in real time so that it changes when the program actually starts. This costs a lot of money and requires new equipment and processes, so most channels will leave Now and Next just automated based on the time due to the cost and complexity of making it accurate. It will never be accurate for the majority of channels.

The other snag is the PVR doesn't know if the Now/Next data is accurate or not on any particular channel and just follows it blindly. So a recording on a channel that doesn't support accurate recording for 8:00pm to 8:30pm will record from 8 to 8:30 on the dot as that is when the Now/Next data changes over. Essentially it's recording without any padding.

There is no memory constraint on the Humax stopping us from using padding in place of accurate recording while still getting series link, it's just plain tunnel sightedness and lack of real world testing. Remember they are Korean programmers that will have never have used the Humax on our real TV system. Factor in Freeview Playback being a UK thing (so just our market) and you can see why they have overlooked the option or not gone to the trouble of autopadding on Freeview Playback.


Yep completely agree. The Freeview Playback people should have really put some more thought in to this. Really we don't need accurate recording at all, just the EPG kept up to date and the option to pad a recording is all that is necessary. Of course accurate recording started off as a way to market and compete against the likes of Sky+, but now you will be hard pressed to see a mention of this on the Freeview Playback website, probably because it would be misleading considering it's problematic (still experimental at the moment) and poorly supported by the channels on Freeview, not to mention the lack of hardware that supports it.

Regards

Phil

Are you sure about that? Presumably the Humax has some memory for storing and operating the software. I have no idea how much memory the software is stored in (2Mb, 4Mb, 256Mb) or operates in. Presumably at some point you could not keep adding to the software as you would come up to this limit.

I have no idea whether the current software requires 5% or 95% of the available memory but I would be almost certain that there is a limit.

It also not likely to produce a device with a huge amount of redundancy built in. I would guess that the initial software used over 50% of the space. Otherwise you would save a few pence per model and have half the memory installed.

Hi


Autopadding is already in the firmware, why should any more space be needed to use functionality already there?

Regards

Phil

Start recording at Scheduled Time - Pre-Padding OR when N&N data changes whichever is earlier;

Stop recording when Scheduled Time + Post-Padding is reached AND when N&N data changes at end + Post-Padding is reached AND when N&N data changed at start + Programme Length + Post-Padding is reached. ie whichever is latest. A sanity check for stopping runaway recordings is needed here though for those cases where the N&N data does not change at the end though.

Simple. Add in user-defined prioritisation for dropping padding and clashing timers and tiz done.

Because it adds unnecessary complexity... which will cause unnecessary conflict resolution issues.

Functionality creep is creating unnecessary workarounds for issues than can be addressed by addressing the real issue ... the meta data.

Have you phoned Humax and informed them of you desires?

YES ... very simple ...

Hi


Hopefully Humax (and other manufacturers) will see the light. Maybe once everyone is upgraded over the air on the 9200, and a reset to defaults puts recording preferences to On-time and 150,000 people start using accurate recording, find it isn't as reliable as auto-padding, then switch back to auto padding and find they lose all the extra functionality they've been waiting for so complain to Humax, maybe this will give Humax a push in the right direction.

You mention run-away recordings, this is already in the Freeview Playback spec (something like it stops 2 hours after the scheduled end time, or is suppose to), so that would not need to be added, making it simpler still.

Regards

Phil

Sounds like you own a Toppy

@ PhilipL - Thanks for the useful info about where the software actually gets its info from. It does explain the difficulty in differentiating between AR and N&N - there isn't any!

My observation/comment about memory was based on the Digihome PVR80 boxes. Someone unofficially released a twin-record versionof the software which worked well except the EPG was reduced to about 2 days because the new software needed the extra memory. The inference being that the anount of "spare" memory is tight in these boxes.

However, it's a pity someone can't persuade Humax to switch to using the same software company as the Digihome uses... UK based and a superb example of how software should be written! (http://www.cabot.co.uk) (Screenshots)

John.

You are having a laugh. The newer Vestel clones/rebadged PVRs are terrible and buggy (so I've been told) and some of the boxes that have Freeview Playback features are so broken that they are unusable!

I've been informed that when the FPG2 facilities were implemented on some of these Vestels, not only did autopadding not get implemented but they removed the repeat timer option!

I'm afraid you've set yourself up to be knocked over! Would those people moaning about the lack of facilities on the Hummy please consider the alternatives! I think we are rather fortunate...