I take it with SKY+ that SKY do all the hard work, not the broadcaster?

You don't get something for nothing I guess?!

There are certainly issues with broadcaster support, but why exactly do you think the specification for Freeview Playback is "half baked" ?

What technical reasons are there for that?

The real issue with Accurate Recording is that some broadcasters do NOT stick to the schedules. C4 and Five programmes are usually consistent if not mirroring the scheduled times exactly.
As part of FP2 is Automatic Tracking which updates the event timers as the EPG data changes during the day, surely it would be sufficient to make sure the full EPG matches the times the programmes WILL start.
ie. If there's a film scheduled to start at 21:00 and the broadcaster is aware that with adverts and other messages it will eventually start at 21:04, then the EPG should reflect that 21:04 is the start time and auto tracking will update the event timer.
I think that whatever the stage EPG carousel is at when changed times are registered, it should be possible to insert late changes into the carousel up to a few seconds before the originally scheduled time.

No technical reason - as I've not read them - as I don't have access to them.

They seem to have been written on the fly and that they seem to have been constantly changing. But I guess they are 'stable' now...

The fact that the FP is defined but the reality is that not many of the broadcasters seem able to provide the facilities it requires. Wouldn't you set up the facilities first - being able to provide the facilities adequately before publishing the FP specs and promoting it?

I'm really glad that Humax released something. They should be pushing out new versions for testing on a regular basis.

The problem with reporting bugs to Humax is that it's not easy to know which they now know of and which they don't. And I've reported several bugs over the years and have never had acknowledgement nor have the bugs been fixed!

Ian

That is why you ought to post bugs and feedback on Hummy.org.uk and not here or to Humax UK...

Thanks for the compliment...

Broadcasters addressing the quality of the data they supply.

Adding extra layers of complexity to a simple system is not the answer.

You can use padding for the channels do not supply FP meta data.

I thought using padding, auto or manual, causes problems in v20?

It gives problems in V.15 too, so what is new?

Hi

You are not over coming the short comings with your suggestions, just highlighting the short comings we are trying to work around


Not going to happen. PDC was never that reliable for the same reasons accurate recording will not be, the TV companies get no revenue from it but added expense to implement and keep it running. How do you force every channel to implement it? What happens if the TV channels experimenting with it now decide to drop it all together in the future?

Do we even need accurate recording? Auto EPG tracking and a few minutes auto padding will catch more recordings accurately than the current attempt at accurate recording, and that would work for all channels equally well without added expense or new equipment required. This is here with us now, it just needs Humax to allow us to add auto padding but still keep the other Freeview Playback extras such as auto EPG tracking and series link.


This isn't a simple system, it's very complicated, if it were simple as you suggest we would not be having this conversation as accurate recording would be working 100% reliably for every channel, and delivered on time for last Christmas not this.

By turning it off the complexity is then gone and it doesn't matter how unreliable accurate recording is, we are not affected by it. If the TV companies lose interest in supporting accurate recording, at least we would be able to use automatic padding while still getting the benefits of series link and EPG tracking.


And how are we as Humax's customers going to know which channels these are? Your average customer will have no idea what "meta data" is and you accuse me of making things more complex

Besides auto padding is the request, not manual padding which is adding complexity isn't it, having to manually adjust start and end times even if you have managed to find out which channels support accurate recording or not? That's adding complexity and more ways for things to go wrong.

Using manual padding or auto padding disables series link, EPG tracking and alternative instance recommendations, even though the setting isn't anything about those features, just about recording start and stop times! This means the weakest link in the system can't be removed without sacrificing the lot.

Are you suggesting that Humax can not come up with a better solution other than turning off all Freeview Playback features when a customer finds accurate recording is nothing of the sort and wants to use the well tested and proved method of a few minutes auto padding?

Regards

Phil

I can't say I experienced problems with autopadding when I used v15.

I am pleased for you; unfortunately others are not so lucky.

I'm aware of that, and I agree it's not so good.

There must be a common denominator why some people have had problems and others not. Or it could just be I haven't been doing the same things to get similar results as those who have experienced problems with autopadding in v15.

We'll probably never know now as I'm on v20.

For those of you who want to know how the broadcast side of AR / SL works have a look at http://www.bbc.co.uk/rd/projects/eca/index.shtml

Cheers for this. Still under 'research and development'... hmm.

I thought these technical innovations have already been defined in the FP specs and are currently being implemented?

Because it was written by BBC R+D, where and why would you expect them to move it to on their site?

To the half-baked Freeview Playback pages

I'm just trying to give backing to my previous 'half-baked' statements above

First of all, as a Mac user I haven't been able to try v.20 for myself (and I'm quite happy to wait til January), but my feeling is that autopadding is probably a more reliable feature than accurate recording - which can lead to unexpected clashes.

My question is - Do any of the more technically-minded out there know if there is a good reason why it hs to be bundled with the other Playback 2 features or is it just the Humax implementation which restricts it this way?

I don't see any technical reason why either Automatic Tracking or Series Link cannot be enabled individually. Those both work by referring to data in the Full EPG whereas Accurate Recording on it's own uses the codes hidden in the Now/Next data.

Humax explained this in a post on Hummy.org.uk: http://www.hummy.org.uk/invison/inde...ndpost&p=27178

I don't think there are any technical problems implementing anything in conjunction with Freeview Playback* (including autopadding) but there are limitations with the 9200T's hardware specs and for Humax to do it.

Let's take one example and see what mess we can get into, say let us attempt to implement AP+AT+SR... imagine what sort of checks you will have to get the box to make when a user schedule 4 SR programmes to record at the same time... you have to take into account of all the autopadding overlaps and also the changes with AT (which are done on the fly) and also the SR aspects (programme changes/alternatives, etc)... An attempt to discuss such a problem was done on AV Forums (there are some very technical people over there ) but it resulted into nothing...

As you can see the above is a nightmare... and the technical problem you will have to account for, straight away is, (a) the processing power of the PVR's CPU**, and (b) the amount of time the PVR has to be 'active' for it to run the routines...***

Anyway, one of the attractions of proper FP metatadata means that with AT you don't need AP. Now unless you want to spend money on new hardware with can provide AP+AT+SR**** then the best best is to put pressure on the 'FP group' to get all broadcasters to sort out the metadata and also make sure it is 'accurate'. I am sure if you want to spend £400+ on a PVR based on a PC/Linux platform*****, it will be able to do all you want - even burn the recorded programme on a DVD for you... but first you have to find the maker and with the appropriate software...

BTW, these are just my views/opinions and may well turn out hightly inaccurate and might be wrong... but I'm having a go explaining... which is fun

--
*Providing you have full access to the technical specs and that you can interpret them accurately and that they do not change
**Imagine the load on the CPU when you are chaseplaying or watching a recording and the 4 scheduled SR programmes example above needs to be sorted...
*** Do you think the current hardware in the 9200T is capable of doing this? When the box goes into standby - everything is off (except the fan!). Maybe there is a technical reason why it is not possible for the box to go into 'active standby'...
****Currently, its hard to find a PVR that has AP+AT+SR, and why is this? Makers are stearing well clear of it due to the problem I'm trying to point out here... i.e. the complexity of such an implementation and the currently hardware platform most PVRs are based on is not powerful enough. The Toppy might be able to solve some of the problems with such an implementation (as I have said on here, I think the Toppy is the most advanced PVR on the market due to its TAP extension) but again that will have hardware limitation, and we currently have no prove that it can solve these problem effectively...
*****Most programmers think these sort of issues is trivial since they are still wearing their 'PC programming' hats. I would challenge them to try writing the sort of ideas they have first in assembler and then trying the same thing on a 'chipset' platform - i.e. firmware coding. Then see how complex the coding has to get...

Hi


I think you are making it more complex then it is.

To implement auto padding with FP just needs the Humax, at the time of the recording, to not start based on the Now/Next data but start recording based on the time minus padding, and continues until the end time plus padding. It already knows how to do this. Conflict resolution, as it does now with auto-padding, just ignores the padding values, they only get added at the time of the recording if tuners allow. So auto padding doesn't add any more complication.

Everything else stays the same. Series record works in the same way, conflict resolution works the same, EPG tracking works the same. Auto padding or accurate recording only comes into play when the recording starts happening, it has no involvement in any other action or function.

In version 15 due to a bug (with no rush to fix it on Humax's part) it's almost there already as it ignores the start signal, starting on the exact time rather than using the Now/Next data.

I think Humax will have run out of money now to spend any more on the box to implement customer suggestions, hence it is unlikely from here on in anything more than what is absolutely required to keep the Freeview Playback logo on the thing will be done. It's a shame as all those extra features may end up not being used as customer's turn on padding due to the umpteenth accurate recording failure, and so lose the other features.

Regards

Phil

Maybe so, but personally I think this hardware has many years of useful revenue left especially with DSO upon us.
I think the 320Gb model will eventually become standard at around the price of the 160Gb currently, and maybe 500Gb as the "Premium" alternative.
So I wouldn't consider further firmware developement as wasted resources.

Hi


Of course it isn't wasted. However Humax will have other products for other markets they will need to launch or also continue development on and can't drop everything to just concentrate on the 9200 series indefinitely. They will have limited resources and those resources will be sought after.

Remember that Freeview Playback is just the UK market place, and it's already months and months behind schedule. Once they have done the minimum required for the logo the resources will be moved to other areas.

Regards

Phil

I don't intend to overcome the issue should be addressed... data quality.

Irrelevant ... they can forget about if they like ... we can all go back to padding.