AR on a per-recording or per-service basis

Good point. I am concerned whether converting a padding schedule to AR by making padding zero really triggers the AR tracking response (maybe we can tell after the event whether the box woke up 15 mins early?), you are concerned whether converting an AR schedule to padding creates something where the padding can get lopped off and not cause a conflict. That's what these initial trials should reveal, try it and see. It's easier to test your case than mine.
 
Black Hole said:
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!
Click to expand...

The version of webif that's going up now will show the actual start/end times versus the scheduled ones. An AR recording will not start exactly on the scheduled time whereas a zero-padded one will. It isn't actually possibly to create a zero-padded non-AR recording, one end must be padded.

ar.png
 
grahamlthompson said:
You can convert a series or accurate recording reservation to a padded manual timer merely by editing the start/end times which at a guess is what's happening here.
Click to expand...

It's a valid concern, but that isn't what is happening here. The start/end times are not touched, nor is any of the series link information, I just adjust the per-recording padding/AR flag.

That's all that the Humax software does when you either disable all padding in the menu, or enable it.
 
af123 said:
It's a valid concern, but that isn't what is happening here. The start/end times are not touched, nor is any of the series link information, I just adjust the per-recording padding/AR flag.

That's all that the Humax software does when you either disable all padding in the menu, or enable it.
Click to expand...

I so hope you are correct

However the only way to be sure is

Make sure one tuner is fully commited and set sequential recordings on the differnt channels to ensure that the changeover corresponds to the scheduled times

That the next occurence of same series CRID and a different prog CRID appears in the same folder as the previous recording.
 
Last night's batch were a complete success (BBC2 and C4). Even from the resulting file names I could tell that the recordings did not start at the scheduled time, but the forensic detail provided via the WebIF media browser confirms it. Weatherview has been rescheduled for tonight (also as an AR), so worries about breaking a series link are unfounded.

More testing to go, but if anybody is waiting for some positive indications before joining the beta set I say the litmus is blue!
 
Maybe I should have said the litmus is red (my chemistry is a little rusty). Depends what the desired result is, so let's say blue is good... and hope it's not a false positive!
 
All my tests so far have been successful - perhaps it is time to start compiling a list of trustworthy AR channels (or untrustworthy, whichever is shorter!). I have never had a problem with AR on any channel that I record but I understand that Five is regarded as suspect. Is anyone in a position to advise on the others?
 
af123 said:
All my tests so far have been successful - perhaps it is time to start compiling a list of trustworthy AR channels (or untrustworthy, whichever is shorter!). I have never had a problem with AR on any channel that I record but I understand that Five is regarded as suspect. Is anyone in a position to advise on the others?
Click to expand...

Someone may be able to clarify that also, it certainly was poor but may be better now. It is the 'lesser' channels in general that do a poor job with meta-data etc.
 
I would be inclined to have a channel white-list the user can click in the WebIF. They can then be cautious or not as they like.
 
Black Hole said:
I would be inclined to have a channel white-list the user can click in the WebIF. They can then be cautious or not as they like.
Click to expand...
I agree (well, black or white-list depending on the approach) but it should contain some defaults so that most people can install and forget.
 
TBH, 99% of the time I record from the main channels (1-5) and obviously their HD variants. So far, and I am talking many months of use now, I have not had a single recording fail. I use AR and always have done.

Just out of interest, my Topfield 5810 (with MyStuff and associated TAPs) has had the odd 'run on recording' but only on Channel 5. I believe that was caused by the fact Channel 5 have a short news update just before the hour. Having said that, my HDR has copped with all Channel 5 recordings. Perhaps the Humax implementation of AR is superior to the Topfield.
 
Not much help at the moment as it's off air till after Xmas.

Channel 5

The lunchtime edition of neighbours set with a series reservation following a series record of home and away (both AR) invariably chops off the beginning of neighbours.
 
As far as I am concerned, the white list would be BBC1, BBC2, BBC1 HD, BBC HD, ITV1, C4. I suppose BBC3 & 4 could be included too. Not sure about ITV2/3/4. I know C5 has a problem, and I wouldn't want The Gadget Show or Fifth Gear going missing - if all else fails there's iPlayer for the Beeb, but recovering from a failed C5 recording means resorting to PC.

We do not need to risk AR for channels which do not broadcast live events - their schedules are always within the minute, and if I don't have to compensate for live variations any more I can reduce the padding (and the storage space it takes up).
 
I'm thinking through the design for this feature which will be an extra package. It needs to be install and forget for most people and work for those who predominantly prefer AR and also those who favour padding.

This is just typing out loud to gather thoughts and gauge interest.

As an AR user, I would just like a small list of channels for which I'd like to use padding.
A padding user would probably just like a small list of channels for which they'd like to use AR.
A user who doesn't know what AR and padding are just wants things to record properly.

One option is to implement a channel list, then have the user choose one of:

-> Convert recordings on these channels to AR.
-> Convert recordings on these channels to Padding (enter values).
-> Convert recordings on channels not in this list to AR.
-> Convert recordings on channels not in this list to Padding (enter values).

On installation, the package could decide what to do based on the current recording mode.

Actually, the second two options only apply to people who have the boxes in the wrong mode to start with..

Am I making this too complicated?
 
I think it is. I know it will ruffle some feathers, but I don't see why people who want to use this feature should be educated how to use it. I also don't see any need to set padding values in the package - just insist they are set in the main options so it is a one-way conversion from padding to AR, instead of your package having to accommodate all the different variations. Keep it simple - easier to write, easier to test, easier to maintain, and make people use it one way - after all, it will still do what they want. This will upset the dyed-in-the-wool AR users to start with, but the prize is so good nobody's going to boycott it. In fact, once this is announced on AVForums we can expect an avalanche of new users (and no doubt loads more memebers :( ). Is an avid AR user who wants to cure the delinquent channels going to worry that AR is created by a background process instead of in the padding settings? OK, so don't use it then.

As a control panel for the background process in the WebIF just list the available channels and have a tick box against each to choose whether to force AR for that channel.

If I might suggest: you could also have a non-auto WebIF option for single recordings/series (like the experimental RS interface). It would switch padding to AR, or if already AR have a radio button pop-up asking what padding to apply. Presumably this will also be available through the RS.

If I might also suggest: you could detect whether a periodic wake-up is scheduled either in the programming or the timer on/off, and warn if there is not the obligatory 20 mins at some point in the day. I know it might not be needed for pure AR, but once we start mixing that up better safe than sorry.
 
Maybe it would be interesting to find out how many people actually use padding instead of the default AR? I think that they will be in the minority. I have always used AR, and have found it to be extremely reliable on the channels that I tend to record, and therefore would prefer to stick with it, but would like the option to select a few channels to use padding on, what could be simpler than that?
 
I don't think you have tried it yet, but the experimental RS Gui prompts you for padding values if you try and convert something from AR to Padded. After you have done it once, it remembers the padding settings you used last time.

You're right, making it a one-way process would simplify things and anyone that doesn't want to use it is under no obligation. However, for some reason, I'm very reluctant to globally enable padding on my box and I want a system that can selectively apply padding to channels that routinely lose bits of programmes with AR rather than the other way around. One issue is that this whole conversion process is going to have to happen at boot time (just like current web scheduling) so if you set something to record in the very near future then it will use the default settings on your box which may be a consideration.

It might have to be adaptive based on whether the box is set to AR or Padding. Handling boxes which change from one to the other would be an additional challenge however.

I like the idea of a list of channels with tick boxes, or maybe something like:

select_list.JPG


? which I'm sure has a name..
 
You must log in or register to reply here.
Back
Top