Auto padding

Channels DVR Server
#1

I’ve had this thought knocking around in my head for a while, and thought I’d bring it up here.

As we all know, sometimes shows start early and/or end late. We have the padding controls to start recording early and end late.

But why should my tiny human brain have to think about these things? If there were resources (i.e. tuners) available, it seems like the DVR could automatically add padding around shows it’s recording. And it would know it started (say) 5 minutes early - so when I go to watch the recording, perhaps the play head is automatically queued to 5 minutes, and I can back up if I need to.

Anyway - I know there are potential problems with this approach. But, you guys (devs) have said you want to build a DVR without all the baggage that DVRs have had in the past, so figuring out a way to ease the pain of padding might be an opportunity!

2 Likes
#2

The broadcast networks generally have a very specific schedule and programs start and stop when the are supposed to. The only time I have ever had to use padding was woth live sports events. If I added default padding to my recordings, then I would have useless irrelevant segments before and after my recordings. And my tuners would be tied up and be unavailable for a subsequent recording if i had it scheduled. So i think padding is awful and I avoid it like the plague. I dont even think default padding should be an option.

I think the people who have channels that have inaccurate guide schedules are a small fringe group with some pretty bizzare stations.

Aside for sporting events or live events (the reason for padding), it is possible that users with issues of innacurate schedules may be pulling the wrong guide data.

#3

Not true in the general case. Just as an example, the Big Bang Theory here starts about 90 seconds before scheduled. And this is in a major market (Denver), on a major NBC/ABC/CBS sort of network.

In my original note, I said “if there were resources (i.e. tuners) available” - if you had something else scheduled, then it’s obviously not “available” in this context.

I did not suggest “default padding”, and I also suggested having the playhead automatically cue to the scheduled start time; it would just have a few minutes recorded before that (if it was possible), so you can go backwards if you need to.

In any case, perhaps your schedule is more accurate than other peoples’ schedules, and you don’t need this. Some of us would find it useful.

#4

I have some recordings that are 1 hr 3 min long, some that are 32 mins long. Somehow, the guide knows exactly how long the programs run and if they will start slightly before or after the traditional hour / half-hour mark.

I just think the ultimate solution for stations that don’t work with the guide should be to find a way to fix the inaccurate data for these erring stations, rather than compensating by recording buffers.

But I do see how your suggestion could indirectly fix the symptoms in cases where guide data is faulty. But make the buffer invisible to the user. Unneeded tuners just record all the time. Allow the option to go into the buffer after the fact… that tuner wasn’t needed at that time anyway, so it just kept recording. If it turns out that Big Bang Theory started 90 seconds off-schedule, user can add this from the previously recorded video.

#5

In the UK we have a great system called “Accurate Recording”, or the more technical term of EIT p/f (Event Information Table present/following). The DVR schedules programmes via the guide data as usual but then monitors the channel near the time of the scheduled start and only starts recording the moment the EIT p/f data switches programmes. Likewise near the end of the programme it will automatically extend the recording until the EIT p/f data switches to the next programme. Naturally for this to work it requires the broadcaster to send the correct data, but most of the major channels are pretty good about it.

I’m not sure if a similar system exists with ATSC or is used in the US/Canada, but I’m really hoping Channels supports EIT p/f when DVR is available for the UK and other DVB-T/T2 countries.

1 Like
#6

That EIT thing sounds like a great way to do it.

It does sound like there should be a way to get better guide data though and even this wouldn’t be needed. I live in the middle of a city and pull in 55 channels with an antenna. I only watch the HD channels, though, which total 18. On these channels, I have only once experienced a program that started or ended at the wrong time. It was for a movie that was scheduled for 2 hours but ran for 2 hours 30 minutes. That was a very unusual guide error, though. Other than this one occurrence, the schedule works great. So I only use the buffer for live sports. And it makes me wonder what kind of channels people are getting where the shows don’t start at the time they are supposed to. Maybe there is a better guide or they are pulling the channel/program information for the wrong affiliate station.

#7

This is a pretty great idea, then you could get rid of padding UI altogether and I wouldn’t have to think about it. Cueing the play head to the right spot is a great idea. This idea is basically like cameras that have the sports mode that take pictures before and after you press the shutter button.

#8

I’m not a beta user, but I have two-cents on this subject, please forgive any ignorance that I show.

I would vote for the ability to pad, both start and stop, and make it completely optional for those who detest the concept. The one driving force for adding time to the end of a recording is for sporting events, such as football games that end in a tie and go into overtime, etc.

There is another “type” of padding that might no longer be an issue - it is when a station has a different notion of time than the rest of the world. I faced this problem with a cable company that had one channel that was always about 30-40 seconds late, and other one equally early. At the time, I suggested that the DVR be able to “skew” the time on a channel by channel basis. User could tell it to offset the clock by a number of seconds/minutes to allow for the error. I realize from some of the messages, that the problem could be with the programming source, or that the station should make corrections, however, … good luck making that happen.

I had suggested a system like the UK’s EIT, “sweeting the deal” by pointing out that the signals would also include some commercial material (hoping they would not figure out that software DVRs could skip over it). An “EIT” system is absolutely the way to go. The protocol could be extended to include the channel’s programming, making such services obsolete. I’d guess it would take YEARS to get such a system in place the US.

Again, just my two-cents on the subject.

1 Like