Padded recordings swapped to AR failed

ian_j

Member
We use padding -5 and +5 and have never had an issue until I started using De-Dup.
Files started having the next or previous programs details as the filename so I decided to move them to AR in the hope that would solve it.
Unfortunately in the last 24 hours we have had 4 missed recordings, all four had 0 minutes recording time.
Anything I can do to find out why they failed or anything to ensure they record in future?
All recordings were on The Food Network and of Diners, Drive-Ins and Dives.

Edit:

Just added some more episodes but when I tried to change them from Padded to AR the box reset but they are still shown as padded, and the reboot reminder has gone.
 
Last edited:
I don't know why but it does not work if you do it that way. If you have padding as default and then change individual recordings to AR they will fail with 'failed to track' errors. If you have AR as default and change some recordings to padding it is fine. You could set AR as the default and install the multimode package to change some of the channels to padding: that works.
I don't know if it is possible to have padding as the 'default' and change selected recordings to AR. One thing I have not tried is to set the default to AR then install multimode and add all channels to the padding list. This might work. You might then be able to make AR work on selected recordings, but keep padding as the default.
 
Bum :-(

I'd rather not do that as a high % of our recordings are on the radio and AR recordings failed more times than they succeeded.

DDD is the only series where I need to de-dup the folder.
 
It's not a problem to have AR as the default, multimode lets you define services which should automatically be padded.
 
It's not a problem to have AR as the default, multimode lets you define services which should automatically be padded.

I removed all DDD from the schedule.
I've installed multimode & set channel 41 (food Network) to Convert to AR:

2015 12 20 - Humax HDR Fox T2 - Multimode.png

I've added in the DDD again but they are still showing as padded recorings, what am I missing?
 
Done a reboot?

However regardless of that, did you not read MET's advice in post 2?

Yep I read it, but I wondered why the option is shown on the WebIF context menu if it doesn't work.
And there is no mention of it not working on the Wiki.
 
Just answered my own question, reboot.
There has to be a reboot to enable any custom firmware manipulation of the recording schedule. Setting up a recording which multimode will ultimately convert to auto-padding (or AR), but for which there will be no reboot between setting it and it being actioned, will result in the recording being made with AR (or auto-padding).

I wondered why the option is shown on the WebIF context menu if it doesn't work.
And there is no mention of it not working on the Wiki.
The intention of multimode was to convert to auto-padding for services which are unreliable with AR, using AR as the default. This is the sensible way around. MET has indicated that using auto-padding as the default and using multimode to convert to AR results in failed recordings (despite multimode being able to operate in that way), and you can't rely on this being known at the time things were written. The possibility is there, but (according to MET) it doesn't work out in practice. This is something to look into and find out why.
 
Last edited:
Back
Top