The BBC EITs (Event Information Table schedule) and EITpf (present/following) or Now & Next) are derived directly from SID (Schedule Information for Digital) from which playout is derived. Therefore the times should be exact start/stop. As far as I know/remember the Beeb do not apply any padding. Other broadcasters aren't as good!

Humax could easily add extra time to these ones to give recording padding.

If Accurate Recording is implemented by Humax then (in terms of BBC channels) I'd imagine they'd take that from EITsch with last minute checks from EITpf.

I would not want any padding to be added. The object of Accurate Recording is surely to start the recording "accurately" at the hmm.. the start.
Humax can add it if they wish but don't want it on my Vestel which works very well on BBC and not too bad on ITV.

I assumed in your post #22 that you believe that the provision of auto padding is a requirement in order to be granted the Digital Tick. Maybe I misunderstood?

Colin

Yes, maybe I was a bit vague!

I had meant to say that they are allowed the choice of whether to or not!

As at the Humax V1.00.21 firmware, the Auto Padding settings (Recording's Start Time/End Time) are the switch for enabling/disabling Freeview Playback features.
If a different (new) switch were used (Global variable; Accurate Recording=enabled, disabled), then the padding settings could be allowed for events on non-compliant channels or on none.
So with AR enabled, scheduled events for which AR data is broadcast would use AR, others would use the padding settings and preset times.
With AR disabled, Series link and tracking could still be active, but now the scheduled times of all events would be subject to padding.
The difficulty would be devising an accurate way to determine whether each event should be AR or not - whatever causes display of the purple chain icon I guess.

Software *could* enable padding on AR events, providing no clashes with other recorded events occurs.

An example, as I think I gave elsewhere, is the current trend by the BBC of starting everything after the 6 O'Clock news, and up to the Eight O'Clock summary, early on weekdays. This is to fit in the eight, which is in fact, to be more accurate!, the 7 57 News Summary.

Thus "The One Show" starts at 1857:30 instead of the billed (and EPG and N & N) time of 7, and "Eastenders" (Tues & Thur) at 7 28 instead of a billed 7 30.

When setting the Humax these billed times are used on AR and the first minute or so is missed. Padding here would enable a earlier start to the recording.

I've emailed the beeb to ask why they are starting earlier than the advertised times. More alarming is that the EIT tables seem to also be "doctored".

Hardly in the spirit of Freeview Playback!

I don't think anybody disputes that it could be done. The problem is that the implementation turns out to be difficult to do and for a relatively old (in consumer electronic terms) product Humax opted not to proceed.

The whole point of AR in Freeview Playback is to accomodate those (relatively small) differences between billed time and the actual broadcast. That's why the PVR(9200) begins monitoring for EIT data upto 15 minutes prior to scheduled time.
Perhaps once the "next programme due soon/prepare to record" signal is received, the PVR could poll the EIT data for the selected channel more frequently.

Not a lot of point? As the beeb, at least, seem to be failing to follow what they put in EITpf!

I am a little disturbed by the many replies criticising the Hummy both here and on hummy.org.uk. As an "elder statesman" I have learned over the years that nothing is ever perfect and everyones interpretation of perfect is different.

True the Hummy has some shortcomings and there could be improvements. I for one would like to see the name of a recorded programme displayed before I hit the Delete key as I have deleted the wrong programme more than once. It would also be nice to have the Sky + feature that showed if a recording had been viewed.

That said, I think the Hummy works as well as can be expected and most of the problems stem from false data by the TV companies. A classic case of garbage in garbage out.

To those for whom the Hummy doesn't meet their exacting standards of 100% perfection I can only sympathise. I fear that you will live in perpetual and unfulfilled hope!!

I also fear that if Humax, despite their best efforts, continue to read negative reports, some of which IMHO are truly over the top, then they may well decide to bale out of further improvements and leave us to it.

People are mainly moaning about one thing - accurate recording. If I were Humax I'd be beavering away on a new update which lessens the importance of this broken feature. The first step towards this would be auto padding with series links.

No one expects 100% perfect software but adding such an enticing feature and then intertwining it in a death embrace with such a broken feature is snatching defeat from the jaws of victory. That's why a lot of people are so disappointed.

Set Torchwood to record last Wednesday, which it did OK even starting the recording just before the programme began. well done!! However, it decided to also record the repeat on Thursday as well. Thought it wasn't supposed to do that What's more the repeat started recording late. It certainly doesn't win them all.

Is there any way to view the Metadata signals to see what is being broadcast and when? That way it may be possible to see if it is the Humax failing to act promptly on the signals that are sent or if it is the signals that are being sent late. From comments made it sounds like it is the Humax not responding promptly enough, but who can tell?

I really cannot understand why this issue was not spotted by anyone doing the Beta Testing of the .20 / .21 software. Such a serious failing for the machine gives the impression that the software writers were rather lackadaisical in their approach to writing and testing it. Those who say they haven't had any problems with late starts and early finishes are either extremely fortunate of kidding themselves.

While it is probably nothing to do with it, I note that if one hops the regional BBC/ITV stations on a satellite receiver, the same programme can be at different points, sometimes many seconds adrift, compared to other regions. I presume the Freeview regional broadcasts would echo this disparity. If the metadata is sent centrally to all transmitters on block, this could make a huge difference causing the front running regions to miss programme starts and late running regions to have endings chopped off. However, unless one knows the principles as to how the metadata signals are originated this is purely conjecture, but food for thought.

There seems to be two versions of this "ability" ! I certainly found it wanted to record all instances. This could be a result of the Beeb giving all variants of Torchwood the same Series Link tag. Patently Wed and Thur versions need a different SL tag. Or do they? SL is about catching all instances of the programme as well as an individual weekly episode screening?


Yes, you just need a £20,000 analyser! Though those with Nebula type PC cards may be able to access some. It's all in the Service Information (SI) stream sent on each multiplex. Series link tags would be buried deep inside the headers. EPG (Event Information Table, schedules = (EITsch) and Now & Next (Event Information Tables, present/following = EITpf) have programme start/end detail.



Nor I, did Humax subject it to DTG testing? Though as I have said elsewhere the Beeb, for one, are also at fault in starting programmes earlier than the EPG and N & N entries - or even Radio Times.


The SI is added at the transmitter for DTT and at the uplink for DSAT. DCable usually uses UHF tuners to grab the DTT muxes for content but will add their own SI.

Whilst BBC Nations completely generate their own muxes, including SI, BBC Regions all use a sustaining feed sent out in star distribution fashion. The delays through this are negligible.

You can do this on a Topfield with the appropraite TAP.

The Toppy actually displays the SI table content?

Best ask that in the Toppy forum...

When WEEKDAY repeat was introduced (in version .08?), one poster criticised the way that it worked -- on a Wednesday he had made a reservation for the following Monday and set it to WEEKDAY repeat, and had expected the Thursday and Friday broadcasts of the CURRENT WEEK to be recorded too (i.e. prior to the scheduled recording). This person was roundly sat on by everyone else who thought that the Hummy worked correctly (including me).

Well, now with series link that person gets his way! On Wednesday of last week I made a series link reservation starting today (Monday). I chose today because the editions broadcast last week were repeats which I did not want to record. I was startled to find that the Hummy recorded them anyway! Not what I had expected.

Mmm, strange stuff this "series link".

-- from CyberSimian in the UK

The Sony PVR works in the same way, over christmas at my parents house there was a film clashing with the scheduled autotracking of Eastenders, I tried to remove the Eastenders reservation, swap it to the BBC3 showing and the setup Eastenders as series link for the following day, but when you add the series link on the Sony it also activates it for any days earlier in the week.

I don't know if there are any PVRs using freeview playback working any different

It looks like the Series Link tag is applied to ALL the programmes, for example Torchwood. broadcast in the week.


Whether this is because there is no way of differentiating between each repeat or because broadcasters haven't thought to is another question.

So, for me at least, SL is useless if there is more than one instance of a programme per week.

I must dig out my ETSIs....

I've been informed that Torchwood has been ID'ed properly... i.e. if you set up the SR timer for the main showing on BBC2 it should record subsequent BBC2 programmes only, likewise if you set it up for the repeats...

Situations where you and others have found it recorded the showings that you didn't expect would be when the box had to chose an alternative (because of recording clashes) or maybe due to user error in scheduling the right SR item...

An example where a broadcaster applied the same ID to all the episodes would be the Friends series (the last time I tested this anyway)...

I contacted ITV last night after Dancing on Ice, the skate off failed to record fully (last 3 or 4 minutes - i.e. the result, was cut off). I have received a very informative reply which may answer some other peoples problems and may cause them to stop laying the blame at HUMAX!

Thank you for your email
We are currently using 'real time triggering' on ITV3 but the facility has yet to be introduced on ITV1.
The information below will give you an overview of the system as well as projected introduction dates for our other channels.
We're sorry to hear you missed the final minutes of the programme. It will be repeated in the daytime on ITV1 next Saturday and ITV2 next Sunday.
Once again, thank you for taking the trouble to contact ITV.
Regards,
Duty Office
ds

ACCURATE EPG CHANGES

The new breed of Personal Video Recorders (PVR) now coming onto the
market under the Freeview Playback banner rely on the roll-over of the
EPG now and next display (next programme becomes current programme) to
trigger the start of recordings.

To the great annoyance of viewers, programme billed times can differ
from actual times to the extent that beginnings or ends of programmes
can be clipped. To reduce this effect, the now and next display for ITV
programmes has, for the past few months, been rolling over according to
the actual scheduled start times rather than the billed times.

We are now in position to allow the programme playout system to trigger
the now and next roll over. This gives the highest level of accuracy and
allows for severe overruns that might be caused by extended sports
events or news programmes, or delayed starts that might be caused by
inserted news flashes for example.

From Monday 14th January 2008, the ITV3 EPG will operate in this way and
the roll-over will happen at the start of the commercial break prior to
the programme. In this way, there will be more than adequate time for
the recording mechanism to start up and recordings will always begin
with a commercial break.

ITV2 will change to playout triggering on February 6th with ITV1 and
ITV4 planned to follow later in the month.

You might expect itv to want you to record the adverts! but at least it's a sort of auto padding.

I don't get the "rollover" of N & N - mentioned several times. Granted they're making sure you record the ads, it all sounds a bit too close for comfort!

The N & N (EITpf) tables already contain the precise programme start time or should, I think, according to the ETSI spec. So I guess the itv Duty Office is using the term rollover to really mean the time contained in EITpf.

Hopefully the BBC will switch to the same system, i.e. metadata based on completion of previous prog to set the start of current prog.

Crafty ITV
This means that if the billed times are roughly adhered to, viewers scheduling programmes from a mix of broadcasters will have some last-minute clashes, where BBC One recordings start and end within a minute of a half-hour, and ITV recordings will start and end three-four minutes before the half-hour.

i.e. what you get with Autopadding.

Hi


We are using autopaddng and when I checked with the family regarding ITV Skate Off was recording in it's entirety, however a friend who's gone for the 21 update did complain of losing the last few minutes on AR and they missed the result completely and had to check it on the Internet.


AR is in use on ITV1 has been for some time, perhaps it is still experimental or only in certain regions.


The ads have to be recorded though at some point, the only way to not record them is for the ad's to have their own Now and Next entry, which of course is way to complicated to happen. Currently the ad's are at the end as the Now/Next changes on ITV the moment the program starts and so the stop signal is simply the next program changing to Now at it's start, meaning the ad's are captured at the end.

Moving this to the middle somewhere gives a bit of extra time for PVRs to pick up Now/Next changes and start recording, which is needed in the Humax's case as it can take 30 seconds to register! It also means the sponsorship message isn't cut off as well and you get less overrun at the end of the program as it will stop recording half way through the ad's, as that is when the Next program becomes the Now.

Personally though I don't think accurate recording will ever be as reliable as simply having auto padding, and the system should never have been spec'd in the first place like this. It costs money for the TV companies to introduce it, causes complaints when it doesn't work, and a lot of channels will never support it.

Tracking major schedule changes by having the EPG up to date and the PVR consulting that to update any programs you have set (as it already does) and then allowing people to apply their own padding values is all that was ever needed.

Regards

Phil