I don't work for Humax and hence no spokeman for them. Your best bet is to ask them. And while you are at it, ask every other FP PVR maker why they haven't implemented SR+AP, as well...

I suspect (a) Humax have committed to FP facilities, and this has not only over ran the deadline but over spent the budget, (b) AP+SR is not a FP spec, (c) AP+SR has never been on the top 10 wishlist (Humax at one stage were committed to fulfilling this, then switched over to FP), (d) the 9200T can't be 're-wired' to do it with ease, (e) making it run Linux at its core is to radical and costly! (f) the engineers have other commitments, (g) no other FP box currently on the market can out perform the 9200T, (h) the 9200T is getting replaced, (i) TiVo is not a competitor . My list can go on... but they are just my suspicions... which can be right but most probably not!

One big issue is the dynamic start times of SL/AR.

I've been using my new Hummy for the last two weeks and the series link seems adequate. It does sometimes lose half a minute here and there but it doesn't make much difference. I'll still be relying on my Sky+ and using the Hummy as a backup or for overflow but Hummy series link is a helluva lot better than without. It's good enough to let you break the schedule dependency and watch what you want when you want.

This makes things difficult (but not impossible) if you want auto-padding at the start of a recording. (The Humax would have to start recording well in advance of the scheduled start of the programme, and then throw away all but the last few minutes when the now/next data indicated the start of the programme.)

Auto-padding at the end of a recording should be much simpler to implement - no clairvoyance required! If Humax allowed SL/AR together with autopadding at the end, it would probably be enough for many people. (Before .21 came along, I was padding 3 minutes at the end, but not at the beginning, on the basis that it is much more annoying to lose the last few minutes of a programme than to lose the first few minutes.)

Even better, would be for the broadcasters to get their act together and transmit accurate data .

It would be very simple to start recording with padding in advance of the original scheduled transmission time, and so what if a bit extra is recorded. No clairvoyance required for this. I don't even want AR, all I want is SL plus being sure I get both ends of the program. AR is almost an irrelevancy if you have autopadding.

Autopadding is the irrelevance it causes conflicts...

It doesn't cause conflicts that I care about. Until very recently I lived with a single tuner system with Series Link and autopadding. A dual tuner system is infinitely less likely to cause conflicts. Anyway, that's my choice, I don't have to enable padding if I think there will be a conflict, I don't enable it for that recording. 99.9% of the time for my viewing habits it's not an issue. You are seeing problems that don't exist, you are making excuses for poor coding.

I agree with tdenson: series-link and autopadding would be great. "Accurate Recording" is pretty much irrelevant unless the broadcasters transmit accurate data!

I think one of the main reasons why we don't have AP and SR on the Humax is, as son_t already surmised, the fact that it wasn't in the FP specifications. Humax were concentrating on getting their software FP certified so that their new black & silver 9200Ts could be marketed as such. As it turned out, FP has been a bit of a damp squib and it would have been better (for us) had Humax ignored FP and produced software that was 'better' than the FP spec and therefore unable to be certified as FP compliant. I (mostly) blame the muppets that came up with the FP standards in the first place!

Having said that, I still maintain that the commercial channels are really missing a beat by not getting their acts together and sending the start and end triggers a minute before and after each program and charging a premium for those advert slots. You're not going to FF to quickly or Ad skip too far ahead as it will take longer to find the beginning of the programme than to just watch 1 minute of adverts.

It does cause conflicts that I care about...

FP is the way forward and the broadcasters are following.

But you wouldn't have to use it, whereas I can't even have the option.

I've read a lot of emotive and irrelevant conceptual and techie arguments about this that really don't add any value to the debate.

The simple fact is, there are thousands of ways in which you could define what logic should be used in determining when a recording should start and stop. For every person on this planet, every single one of them will have a different idea. Get used to that, point number one.

Point number two, if you are trying to base the logic on when recordings are made based BOTH on published 'planned' broadcast times and dynamic 'actual' broadcast times, and those dynamic times sometimes are, and sometimes are not, notified to the receiver by broadcasters AT or AROUND that time, what exactly do you expect the box to do? Apply some sort of psychic sixth-sense to work out whether the published or latest-received (or not at all) dynamic times are used? Assume the user has padded manually to avoid this, or that the user mis-set the box and the time settings should be corrected? Assume the broadcaster is always going to get their metadata wrong? Or assume they are going to mostly get it right?

I would love any of the complainants on here to draft a flowchart in Powerpoint or Visio and upload it to this thread so that we can all see the simple logic they think can be brought into play here. I'm sure many systems architects would love to see it.

What I can't understand is that options exist on the Hummy to turn Autopadding on or off and the ability to pad manually. Or use neither and put yourself at the mercy of the data the broadcasters transmit. YOU HAVE THAT OPTION. What more can they possibly give you? You would complain more if there was NO option and you were tied to the box making only one allowable decision for you, with you having no power to override it.

How can an "Accurate Recording" possibly be used along with Autopadding? If you set the Autopadding to '5 mins early', how can the box possibly know in advance that a dynamically-altered start time is going to be transmitted in exactly 5 minutes' time? Again, you're expecting clairvoyancy to come into play here. If you were to just think about it logically for any more than 3 seconds, you'd see that it's impossible.

The only way around it would be if broadcasters ALSO transmitted a code that said 'the programme MAY or MAY NOT start transmission in 5 minutes' time' - aswell as the codes that say when it actually IS going to be transmitted.

Until the broadcasters get their act together, why not just use Autopadding alone, and leave it at that?

Let's get something into perspective.

The DVB spec, which has been out since the early 90s in its basic form, lays down very clear ways for the broadcasters to signal not only programme start and end times but also changes to it.

The relevant table in the Service Information (SI) stream is the Event Information Table present/following (EITpf). The DVB spec says this should be repeated in the SI flow at a minimum rate of 20 secs.

The Digital Tick/Freeview Playback spec requires manufacturers to : "In standby, a recorder shall monitor the EITp/f sufficiently frequently and for sufficient duration to allow a programme to be recorded successfully even when the start time is brought forward by up to ten minutes and the schedule information is updated at least 5 minutes before the new start time."

So a mechanism exists from the STB/PVR to get a change within a maximum of 5 minutes before a programme start. Programmes, in the main, are highly unlikely to change start times within less than 5 minutes before.

The information is there for the PVR to get, and action the precise programme start time well beforehand.

Not necessary. As said many times already here the logic required is already demonstrated by both V+ and Tivo.

Again, you are not listening. I have said many times I cannot live without Series Link. If I pad, I lose Series Link - do you understand that ?
The reason I cannot live without Series Link is because I have had it fo 8 years and am completely sold on the "set and forget" operation it brings. I never consult program listings. I travel a lot and am not in a position to make changes to my planned recording schedules if the broadcasters decide to move my favourite program. I would rather miss bits of programs than miss whole programs, but why should I have to even miss bits. To me the logic of not allowing both padding and Series Link is fundamentally flawed.

Neither of which use the Freeview EPG and FP.

Which is something you will never have with FP.

You can have that with a Topfield PVR.

I hate to jump in on this, but technically this is a trivial problem.

Humax already buffers channels, so it can simply be buffering the channel from 5 minutes before scheduled start time, if the start signal is received later than scheduled start time you simply delete everything earlier than 5 minutes in buffer. The same at the end of program, you would record 5 minutes after the stop signal.

Similarly, there is no technical reason why autopadding couldn't be applied to consecutive programs. These blocks could be shared between both programs, the overlap would only be deleted when the 2nd program was deleted. Again, technically this is not difficult, but this doesn't mean commercially its worth pursuing for Humax.

I don't know whether Humax are reluctant to invest development time in developing these 'clever' solutions for fear of the time it would take to develop/test, or if they feel this would be confusing to users, who might prefer a simpler (but more predictable) behaviour.

I don't even need 3 seconds to see the blindingly obvious logic of buffering it - as pointed out by jblackmore above. I suggest you spend longer than 3 seconds thinking about it.

IF the broadcasters sent all the data in the EITpf table and IF the Humax used it properly there wouldn't need to be any padding, etc.

EITpf table not only contains the precise 32 bit (I think - loads of numbers, though!) start time but also a "running" flag a "starting in and a few seconds" flag amongst other data.

Assuming this is sent by the broadcaster, and it is rare for a programme start time to be changed seconds before, then it's not rocket science for the Humax to be started precisely on time. after all it will use the time data tables to set its internal clock.

The BBC have said that this start time will be at the last trail before the programme, and itv that their start time will be at the beginning of the ad break before.

I am in discussion with Humax as to why programme recordings miss seconds off the start, when in Series Link. They reckon on a test with two 9200Ts, one with SL one without, both started at the same time. But then they also state that only 47 out of 80 recordings started correctly!

Bit of lateral thinking here - I don't suppose it's possible for a user to mis-set the Humax clock to be fast by a few seconds is it ? This would solve the problem in a lot of cases, obviously with a danger of losing the end, but the end doesn't seem to be that tight.

The Humax clock is set from the broadcast signal, no manual adjustment is possible (I did use that trick with VCRs [not possible on those whose clocks are set from broadcast data] but only by about thirty seconds).
Even if the Humax clock was deliberately wrong, that wouldn't change the recording start time compared to the programme start, it would still be triggered from the AR signal.


Three seconds? There's a Panasonic HiDef camcorder which was on QVC recently, they made a point of it (optionally) continually buffering in memory the last three seconds of footage so that when the shutter/recording button is pressed you don't miss anything (provided it wasn't pointing at your feet at the time).

Maybe Humax could do the same with a thirty second buffer.

I have a Casio camera which does exactly that as well. It's great for children/animals waiting for them to perform. Don't know why every manufacturer doesn't do it.

My Casio Digital Camera does that apparently though I've never put it to the test.

Colin

Edit:- OOOPs -> tdenson. I thought I'd done a duplicate post there. I must learn to check ahead before posting.

The flaw in this suggestion is that the 9200 can only record two simultaneous streams. So if two programs finish at 20:00 and two more start at the same time there is no capacity to pre buffer.