AR on a per-recording or per-service basis

Black Hole

May contain traces of nut
(Edit: To cut to the chase and skip initial discussion, see here: https://hummy.tv/forum/threads/ar-on-a-per-recording-or-per-service-basis.959/page-7#post-12532)

The old AR v Padding enmities have opened up in "the other place" again, and suggestions (again) that it would be nice to be able to select on a per-recording basis rather than all one or all the other.

I am wondering, with the increased state of knowledge since this was last aired, whether anything has been spotted in the database that would make it amenable to customised tweaking? As far as I know, it's a global parameter which affects all programmes scheduled to be recorded, at the time they are actually recorded (though heaven knows what happens if you switch the setting while something is being recorded).
 
Last edited:
The scheduling database contains pre and post padding values for each entry in there. If you change the global parameter, then it updates every row in the schedule table to reflect the new values, regardless of the current value,

It should be perfectly possible to mix padding/AR on a per recording basis but I've never tested it and they're are quite a few interactions that would need investigating. It would also be possible to have a batch process that disabled AR on specific services that are known to have problems with it.
 
:) This sounds like new territory for the BYTs to explore, as if they didn't have enough to do!
 
In my opinion, the way to tackle this would be to have padding by default (set according to preference on the menus), and then the background process tweaks the setting to AR for a list of trustworthy services.
 
I would suggest AR by default, with the option to set padding for unreliable channels if required.
 
Yes, maybe that would be nice, but I think it would be easier to implement the other way round, and probably easier to test.
 
That's really subjective! I use AR and have never had a problem, and for testing I would pick specific recordings and convert them to padded...

I'll come up with a way of toggling the flag on a recording, then both sets of people will be able to contribute to the testing.
 
If you change AR to padding, you would also need to specify how much padding. Changing padding to AR only means getting rid of whatever padding there is.

I'm not being partisan about this.
 
I did a quick test on a recording that was scheduled to run this morning on BBC2. I use AR so it would usually have woken up 15 minutes before and kicked off around the scheduled time - here's the HMT info from a previous recording in this series:

Code:
Box wakeup time: Sun Dec 18 06:15:01 GMT 2011
Scheduled start:1324189800 (Sun Dec 18 06:30:00 2011)
Scheduled duration:900
Recording start:1324189938 (Sun Dec 18 06:32:18 2011)
Recording end:1324190630 (Sun Dec 18 06:43:50 2011)
Box sleep time: Sun Dec 18 06:44:01 GMT 2011

I added padding to just this specific scheduled entry - 300 seconds before and 240 afterwards and this morning's recording looks like:

Code:
Box wakeup time: Mon Dec 19 06:25:01 GMT 2011
Scheduled start:1324276200 (Mon Dec 19 06:30:00 2011)
Scheduled duration:900
Recording start:1324275901 (Mon Dec 19 06:25:01 2011)
Recording end:1324277338 (Mon Dec 19 06:48:58 2011)
Box sleep time: Mon Dec 19 06:49:01 GMT 2011
 
The latest version of the rs package adds support for toggling the recording mode of a scheduled recording between AR and Padding. It's experimental so it is only visible to those who were originally beta testers (+ Black Hole)*

This should let us do some testing to see whether the idea of using mixed modes is feasible. If it proves to be, then we can discuss the best way to make use of it (such as having a list of trusted channels that get flagged to use AR).

If you don't update the rs package then you will notice that all of your recordings in the RS portal have an AR icon against them regardless of whether you use AR on your device. If you have upgraded, then the icons will accurately reflect your device following the next schedule upload.

* - Anyone else who wants to join in with the testing is welcome.
 
:) - For my next test, while leaving the box in AR mode, I've set up a recording for a series on ITV4 and converted it to padding (5m pre, 2m post) to see what happens. I'm particularly interested in what will happen when the next episode is scheduled.
 
OK, I've switched a few non-critical recordings over to AR (including the nighly Weatherview) - we'll see how it gets on!
 
If it proves to be, then we can discuss the best way to make use of it (such as having a list of trusted channels that get flagged to use AR).

I think channels would definitely be the way forward. I mainly watch BBC content and never miss a start or end, where AR fails is channel 5 etc who have always messed up series recording, a.r. etc. Using channels keeps the implementation simple from a user perspective, per-recording would have a greater user overhead.
 
OK, I've switched a few non-critical recordings over to AR (including the nighly Weatherview) - we'll see how it gets on!
My initial tests have been successful - I'll update the webif later to make it easier to tell what happened with a recording.
 
:) - For my next test, while leaving the box in AR mode, I've set up a recording for a series on ITV4 and converted it to padding (5m pre, 2m post) to see what happens. I'm particularly interested in what will happen when the next episode is scheduled.

Anybody looking at this needs to distinguish auto padding from a simple conversion to a manual recording.

Auto padding drops padding between consecutive recordings when the same tuner is used - two consecutive manual ones don't

Auto padding retains series recording.
 
How will we tell whether a recording has ended up true AR, and not auto-padding with zero padding? We need a test subject that gets transmitted at the wrong time!
 
Back
Top