Recordings ending too soon

I've found 100 pages from 2012/2013 about this topic but none help.Apparently, to set up a buffer of a few minutes either side of a recording is not an easy upgrade, but in 7 years with nothing happening, surely people should be saying it's impossible.It's not on 1 channel, or 1 show, or even 1 day, it's literally all over the place every day.

Any sensible offerings to this problem would be great, because they always catch the start but I've not had any ending in 2 days now and while it's stated that you can 'catch up' on shows, it's out of order to expect customers to watch 99% of a show to then have to search for it each and every time too, just to watch the last few seconds or minutes.

Comments

We don't have any plans to add a buffer to YouView devices as we already use Accurate Recording which is also used by some of the main content providers. Can you please provide some examples of programmes along with the channel they were on which you find frequently have the start/end missing?

One fairly regular one is Sophy Ridge on Sunday on Sky News (233), 8.30-9.30 on Sundays. This morning the programme overran to 9.32 but the recording stopped at 9.29.

Another it often happens to is Law & Order, Special Victims Unit on 5 USA (21), more often with the 22:00 episodes.

And yes, sometimes Star Trek Voyager on Horror (70). Others too.

But @Ursa, there's a workaround I use, which is to record the repeat at 9am instead and also record ST TOS that follows it at 10am, which I don't watch itself but if the Voyager recording comes up a minute short then I've got that minute (less a one second or so gap) at the beginning of the TOS recording. :-)

(I do this with the morning repeat 'cos at 9-11 in the weekday morning I don't have any other recordings to conflict with....)

Hi @SchmikesDo you have any other examples of programmes on the BBC which this is happening with? If you can provide the programme name, channel and time if possible that'd be ideal. We can then set up some recording tests on our end to see if we experience the same issue here. Thanks,Sarah

Thanks @Schmikes. We've set these to record on our boxes so we can check to see if this happens at the weekend. Thanks,Sarah

Why just those BBC ones? As I say, a pretty regular one is Sophy Ridge on Sunday on Sky News (233), 8.30-9.30 on Sundays.

And another is Law & Order, Special Victims Unit on 5 USA (21), although they run an awful lot of episodes of that -- 3/4 every day (repeats of repeats, and I don't record them all!) -- so I don't know if you'd want to record all of them :-) Still, since my previous post I've had it lose the last minute or so of the L&W SVU episodes on Sun 22.55, Mon 22.00, and Wed 23.00 & 23.55.

Accurate Recordings is a system set up which relies on the broadcaster to send signals for the start/end times to their programmes. When the signal is received, from the broadcaster, the box starts the recording and then ends it when it receives the next signal.

Not all broadcasters choose to use this method so we need to rely on the data they have provided for the start/end times of the content. Unfortunately this is not always accurate as programmes can overrun (quite common with sports or news based content) or the programme may not have been scheduled correctly, if this happens and the broadcaster has not updated the data we receive from them, it can cause the recording to become clipped at the start/end or even fail on some occasions.

Since the BBC use Accurate Recording, it's quite unusual for clipped recordings to occur so we need to investigate it a bit more to attempt to recreate the issue and investigate further.

We will set these other channels up to test as well but since they do not use Accurate Recording, it's a bit more tricky for us to work out whether it's because they do not have Accurate Recording or if it's for another reason which could also be affecting channels such as the BBC.

I'll update here once I have a bit more information to share on this investigation.

I continue to get recordings ending too soon fairly regularly (although I haven't had Sophy Ridge on Sunday do so since I last posted).

Law & Order, Special Victims Unit on 5 USA (21) is a frequent one, but also Pointless Celebrities on BBC1 (1) last Saturday, Age of the Image on BBC4 (9) on Monday, and Peston on ITV (3) on Wednesday all stopped recording a minute or two before the end.

I now have proof that this problem is not a result of broadcasters' start/end signals, at least not in all cases.

I have two DN372Ts and I have set up both to series record Law & Order, Special Victims Unit on 5 USA (21), and the recordings start and end at different times on the two boxes.

For example, with the 10pm episode last night, on one box (A) it started recording 15 seconds before the start of the actual programme and recorded for 55m50s, finishing recording 1m12s before the end of the programme (so losing that much of the end).

Whereas on the other box (B) it started recording 38 seconds after the start of the actual
programme (so losing the beginning), and recorded for 58m07s, although the programme itself finished at 56m13s (so continuing to record for 1m54s after the end of the programme).

So, box B started recording 53 seconds later than box A and finished recording 3 minutes and 6 seconds later than box A. Box A lost the end of the programme and box B lost the beginning.

Both boxes are on 72.48.87 / 3.6.162 and both are getting their signal from the same transmitter (Crystal Palace).

Over the past few months I have noticed that for example I am losing the last minutes of recordings! For example Belgravia on ITV. I have also noticed that the BBC news recordings carry on well into the regional news and then the regional news finishes too early. What is going on and how can this new problem (with me anyway) be corrected?

I'm also on Crystal Palace and I am still getting clipped recordings, as per my 10th of March post which demonstrates that it's nothing to do with broadcasters' start/end signals, and I get them on the "big 5" and their offshoot channels. It happens frequently enough that I've given up logging them.

Different programmes endings may be clipped for different reasons, but my 10th of March post above where two DN372Ts both receiving from the same transmitter start and finish recording the same programme at different times shows that there's clearly a bug in YouView.

@meyou2> I now have proof that this problem is not a result of broadcasters' start/end signals, at least not in all cases.

>I have two DN372Ts and I have set up both to series record Law & Order, Special Victims Unit on 5 USA (21), and the recordings start and end at different times on the two boxes.

If the same transmitter is being used for both devices, then possibilities could be clock resolution, in other words do they display the same time, on my box (DN370T) it only displays the time to the minute, I cant see seconds displayed anywhere. The device does get the time from the TV signal though because it shows the right time when its been un plugged but it could also get the time from a time server if its connected to the internet. Are both boxes connected to the internet? I dont know what time resolution is transmitted over the TV signal there is a possible suggestion a time signal may be broadcast on ITV according to 3.58 here:https://www.ofcom.org.uk/__data/assets/pdf_file/0023/62663/broadcast-TV-technical-codes.pdfIt was published in 2016 so things might have changed and it might be refering to analog, I've only cursory scanned the doc looking for the word "time".

I know from playing around with RaspberryPi's they have no battery powered time source, like say a computer and work on a best guess of what the time is if it cant synch with a time server, but you could leave a Rpi off for weeks and it will think it was only a day later since it was switched off.

I do like the Garter Hype Cycle, its quite illuminating, but anyway, without breaking into the box, looking at the chips on the circuit board to work out what possible capabilities it has, its hard to say for sure just how the time and program start/finished is handled exactly, which could explain the "tolerances" you see in program durations. Now if anyone has taken their HD out and looked at the linux librarys installed and configuration, it might be possible to work out just how its handling the program start and finishes.

As its open source, you are free to reverse engine all you like and you are free to fork the Youview setup as well to do your own, but most companies dont like you knowing that.

In fact, by Youview not providing any modified source code, they would be in breach of some licences, because some licences only allow you to keep modified source code if its for internal use only.

Anyway thats my understanding of open source licences, differences occur depending on what licence is in play, but the MIT licence gives the most freedom, others can be more restrictive.

The engineers manual to break into a box without breaking various plastic tabs would be useful for getting inside to look at the components, see what are jellybean, what are not, then work out whats required to fix things, using the right to repair laws, so Youview besides providing the previous FW, could you also supply an engineers manual for the DN370T or do I need to go to TalkTalk to get that as they supplied it?

There’s a broadcast flag that tells the box when it should switch the recording of a broadcast on or off, and an identifier called a CRID that tells it which programme it is talking about.

The box responds to the present/following flags as broadcast, irregardless of what it thinks the time is; when I had a bug in my YouView box that made it think it was January 2000, it still recorded every programme I had scheduled by responding to these flags, no matter how unlikely it thought that they were being sent at what it erroneously though the time and date was.

The present/following flags for each Freeview channel are sent out on every Freeview channel, so your box knows, say, that a Channel Four event trigger has just been sent, even if its tuners are currently on channels 1 and 32, so it can notify you, or switch to recording it, if you have chosen one of these options.

There’s a small exception for boxes in deep sleep, which rely on the internal clock/calendar to wake up in time to spot an expected event trigger, and so can miss things if that clock/calendar is wrong. But any box that stays more awake, as most do, don’t care what their clock/calendars say, at least not for this purpose.

Obviously, this system requires the broadcasters to send these triggers at the right time, and not just at the planned time if programmes run over, and the ‘big 5’ are much better at this than the ‘minnows‘. And, amazingly, Freeview don’t require channels to operate this system (Accurate Recording) to any particular standard of accuracy. (Or even to operate it all, which makes a bit of a nonsense of YouView’s sole reliance on it; though most operate it to some extent at least).

And it also requires the boxes to detect these flags correctly and act on them in a timely fashion, and not to miss them or to imagine them when they aren’t there. Which the software, firmware, or hardware sometimes fails to do, hence the current spate of issues.

I have a low opinion of people who press the Disagree button instead of engaging in reasoned debate.

I have an even lower opinion of YouView’s continued policy of letting such people hide behind the cloak of anonymity.

Re:ITYM ‘Gartner’.Yeah but its written as Garter in the PDF, its a typo but this is the wiki link explaining it:https://en.wikipedia.org/wiki/Hype_cycleAlways amazed at how much Gartner research and projects come true in the tech world.

Re:why not just read the published standards, such as:-

Search engines, my " Eli Pariser: Beware online "filter bubbles" is different to yours, so I cant access some data when I'm looking for it and then that can cause problems later on, especially if a search engine directs you to a malicious coding example/how to setup a server post. Its really quite clever how people can insert backdoors unwittingly. Thomas Pynchon springs to mind "If they can get you asking the wrong questions, they don't have to worry about answers." as search engines could be useful tools for getting backdoors put in place. I often do things wrong to find out what behaviours occur and then you can start to get insights into the code.

common service, e.g. first half of a football match, News Flash, first part of an entertainment show.""TDT Time and Date Table", "TOT Time Offset Table", "UTC Universal Time, Co-ordinated""3) Event Information Table (EIT):
- the EIT contains data concerning events or programmes such as event name, start time,
duration, etc.;
- the use of different descriptors allows the transmission of different kinds of event information
e.g. for different service types.""Time and Date Table (TDT):
- the TDT gives information relating to the present time and date. This information is given in a
separate table due to the frequent updating of this information.""Time Offset Table (TOT):
- the TOT gives information relating to the present time and date and local time offset.
This information is given in a separate table due to the frequent updating of the time
information."

So on the surface, ie cursory glance, it would suggest one time data is broadcast to all, Sarah's posts suggest there might be difference between transmitters, that gives a possible clue into how the TV broadcast network is setup, which would seem plausible when considering the local regional news that does occur, but might not be the case.One thing that does cross my mind, could someone introduce some code into a Youview box that reacts differently when certain programs are recorded. In other words, could I make someones Youview box play up when they try to record say C4 news @ 7pm and on the plus 1 channel an hour later?

Either way it does seem odd some recordings work and others dont, plus since I've posted, despite the box having not been online, my recordings have worked. Another way to communicate with the device perhaps? The Aerial in and out could possibly be used as a low frequency low baud rate/data transmission rate device, because Long Wave radio signals can be bounced around the planet. Basically the lower the frequency, the less power needed to cover a greater distance, but lower frequency's also have lower baud rates, but you probably already know this. Basic Physics putting aside atmospheric interference.

Re: And it also requires the boxes to detect these flags correctly and act on them in a timely fashion, and not to miss them or to imagine them when they aren’t there.

When I think of the problems I've had trying to get the box to record a program from the EPG, and how variable it is at responding by displaying a red R icon next to the program, I do sometimes wonder if we are seeing some sort of low level threading issue, assuming the cpu is a multi core cpu. If a core stalls, it could miss a flag being set and then depending on how its coded, that could then cause other problems elsewhere in the code.

I had to fix this problem for a company when the first of the dual core CPU's started appearing. Basically software runs like clockwork on a single core cpu, but once multi core cpu's appear, some parts of a program can run faster or slower than an another program running on a different core, and if they dont use Mutual Exclusion, Critical Sections and other methods to get threads/programs(processes) running on a different core to synchronise, you can start to see random problems and lags that way.

Again without seeing the code its hard to say for sure, but its a possibility which could explain some of the problems being experienced. The fastest fix is to bind all programs to one core, in effect creating a single core cpu, like the old days and then see if that reduces or removes the problems.

There’s a broadcast flag that tells the box when it should switch the recording of a broadcast on or off, and an identifier called a CRID that tells it which programme it is talking about.::

And it also requires the boxes to detect these flags correctly and act on them in a timely fashion, and not to miss them or to imagine them when they aren’t there. Which the software, firmware, or hardware sometimes fails to do, hence the current spate of issues.

@Roy, I can't find either CRID or content reference identifier in that document. Maybe some different terminology there?

That aside, do you know what the relationship is (if any indeed) between the present/following flags and the on-screen current programme info? I.e. the popup you get that tells you what the current programme is when you press the Info button.

I ask because, as I described here and the posts that follow, in every case of Failed to Record and Partially Recorded failures that I've been able to check on, what has happened is that the box has started to record before the programme has started according to the Info popup (and then immediately failed). E.g. it'll try to record Channel 4 News while the Info popup is still saying Hollyoaks is on. Indeed, sometimes by up to a minute or so before Info says Channel 4 News.

This happens even if I'm already watching 4, so it's not that it's getting a badly timed start flag from another mux (well, I suppose it could be using whatever the other tuner is tuned to, even though the tuner it'll use is already on the channel to be recorded....)

Thats a fairly old standard that I referred to there; the first one I came across to make the point to @CriminalsRunTheWorld that a surprising amount of this stuff is freely available to read, and does not have to be deduced from chip behaviour.

Once you know that present/following is a toggle, with the dual purpose of letting recorders of the current programme know that they should stop, and recorders of the upcoming program know that they should start; and that this toggle is sent on every broadcast channel, not just the one that the programme changeover is actually happening on; you can construct all sorts of scenarios for failed recording, like the box seeing the first p/f it gets and starting recording, and then seeing a second instance of that p/f, thinking it is different, and so turning off again, instead of just ignoring the duplicate.

And so on. Not, of course, that the YouView code would fall into such an elementary trap, but we can posit more subtle variants.

Re the Info popup, the box is going to prioritise getting the recording going, which it can do pretty instantaneously, and not be able to refresh the popup until it has at least fetched the new thumbnail, and the broadcast text with it, and then overlaid that with the YouView metadata.

So I would expect a lag between the recording starting and the popup refreshing. Whether that should be a whole minute, though, I’m not so sure.

But it would be interesting to monitor this behaviour on recordings that work OK, to see if you see the same or different on those.

I have a low opinion of people who press the Disagree button instead of engaging in reasoned debate.

I have an even lower opinion of YouView’s continued policy of letting such people hide behind the cloak of anonymity.

Re the Info popup, the box is going to prioritise getting the recording going, which it can do pretty instantaneously, and not be able to refresh the popup until it has at least fetched the new thumbnail, and the broadcast text with it, and then overlaid that with the YouView metadata.

Re the Info popup, (a) what thumbnail? The only graphic on my Info popup (DN372T) is the channel logo graphic, and I'd imagine surely those are all prefetched.

(b) the text isn't the broadcast text for the programme from the Freeview EPG (unless there's no internet connection); it's supplied by YouView (a pet gripe of mine, 'cos the two are often different). However, getting that (if it too isn't already prefetched) must be almost instant 'cos, after all, you can flick forward in the guide to any programme on any channel in the next week and press Info and the popup comes up more or less immediately.

I too have had issues with Belgravia on ITV (HD) losing the last few minutes or so. This is on a Panasonic HWT150 so not just a Youview issue.

I also recorded Belgravia on ITV HD using accurate recording on a Humax HDR-Fox T2 (ie an non Youview device) on Sunday (Crystal Palace transmitter). The programme had a few minutes late start but accurate recording handled that - the ending was lost as the recording ending coincided with the EPG timing. So I suspect the issue was due to the "start signals" for the following programme incorrectly still occuring at the EPG time rather than when it actually started.

I also recorded the same episode of Belgravia last night when it was repeated on ITV HD on the same device and found that I again the programme started later than the guide but that again was handled by Accurate Recording BUT again the recording ended several minutes early indeed recording less than the Sunday recording. Again the recording ending coincided with the EPG guide start time of the following programme.

Hi all,Just to update on this issue. We've aware of this happening on non-YouView devices as well and as a result are investigating a potential regional issue with the now & next data causing recording failures and clipped/short recordings. I'll update once I have anything new to share. Thanks,Sarah