AR recording problem?

[MontysEvilTwin]

My scheduled recordings of the Bridge (2 episodes) on BBC Four HD (Sutton Coldfield transmitter) both failed last night. At first I thought I had fallen foul of the new HD channel bug, but the only files created were the two 'hmt' files, no 'nts' files (not even empty ones) or 'ts' files were saved. My default setup is padded recordings, but I set these as AR using Web-If. Has anybody seen this before?

I also have access to another HDR-Fox in a different location (Oxford transmitter). The same programmes were set to record on BBC Four (not HD) with AR. As far as I can tell (by logging into the RS server) the same thing has happened on this machine. So the problem is not related to the transmitter or an individual machine and occurred on both the standard def. channel and its hi- def counterpart.

 

[af123]

Only having a .hmt file means that the box didn't see the AR signal in the EPG data while it was watching for it - assuming everything else is right it would usually mean that the programme wasn't broadcast or the box is receiving multiplexes from multiple transmitters.

 

[Brian]

Is that the same as the failed to track error?

 

[MontysEvilTwin]

Attempting to play one of the files gives the message 'Recording failed: unable to track programme'. It is weird as the programmes were definitely broadcast, and it seems that the same thing happened on two machines. Could the fact that the Hummies use padding by default, but these recordings were set up to use AR (one using Web-If, one using the RS server) have caused a problem? I presume that other people recorded these programmes OK with AR as I have not seen other posts complaining about failures.

 

[MikeSh]

It's a long shot but were you set up for The Bridge or The Bridge II? If the former (though not sure how you'd have got there) then the result you got might be expected.
TBII worked fine for timings using AR on Winter Hill (but mine failed with the zero length feature.

 

[MontysEvilTwin]

Definitely the Bridge II, the series link is still in my planner. Next weekend I am also going to record with padding to see what happens.

 

[Greecian]

My scheduled recordings of the Bridge (2 episodes) on BBC Four HD (Sutton Coldfield transmitter) both failed last night. At first I thought I had fallen foul of the new HD channel bug, but the only files created were the two 'hmt' files, no 'nts' files (not even empty ones) or 'ts' files were saved. My default setup is padded recordings, but I set these as AR using Web-If. Has anybody seen this before?

I also have access to another HDR-Fox in a different location (Oxford transmitter). The same programmes were set to record on BBC Four (not HD) with AR. As far as I can tell (by logging into the RS server) the same thing has happened on this machine. So the problem is not related to the transmitter or an individual machine and occurred on both the standard def. channel and its hi- def counterpart.

Both episodes recorded on one of my HDRT2's in HD OK from the Crystal Palace transmitter.

I haven't recorded much on BBC4 HD & BBC3 HD lately , but no '0 minutes' failures for the last week or so.

Gerry

 

[MontysEvilTwin]

Below are edited excerpts of e-mails from rs@hummypkg.org.uk:

Device: HDR2 (device on Sutton Coldfield transmitter - HD recording)
At least one failed recording has been detected in your
media library. The following recording(s) failed:

/The Bridge II/The Bridge II_20140104_2100
/The Bridge II/The Bridge II_20140104_2200

Device: Humax (remote device on Oxford transmitter - SD recording)
At least one failed recording has been detected in your
media library. The following recording(s) failed:

/The Bridge II/The Bridge II_20140104_2200
/The Bridge II/The Bridge II_20140104_2100

Each device is only tuned to one transmitter: no '800' channels on either. Both are on 1.03.06 firmware (CF: HDR2 = 2.20, Humax = 2.19). I am stumped, I can only think that this is a problem to do with the recordings being set up as AR on machines with padding as default? Has this been reported before? Is there a better explanation?

 

[MontysEvilTwin]

This is what happened when recording the Bridge II this week. On the box where I got failures with BBC Four HD last week, I changed from AR back to padding (default setting) and I left the SD recording set up on the remote HDR unchanged (BBC Four, AR) I set up additional AR series recordings on my other HDR (BBC Four HD).

Humax (device on Sutton Coldfield transmitter - HD recording - AR)
Both failed, no TS/ NTS files saved, zero length HTM
HDR2 (device on Sutton Coldfield transmitter - HD recording - padding)
Both successful
Humax (remote device on Oxford transmitter - SD recording - AR)
Both failed, no TS/ NTS files saved, zero length HTM

So the problem is not machine specific, or a HD channel issue and has occurred with two different transmitters. AR seems to be the culprit, but I know of other people who have recorded these programmes fine with AR. It could be the combination of using AR on a machine which is set up for padding as default, but this has worked for me recently on the same channel without issue. I am stumped, I think I may have to abandon AR recording: if it is not reliable it is no use to me.

 

[jxp]

... I am stumped, I can only think that this is a problem to do with the recordings being set up as AR on machines with padding as default? Has this been reported before? Is there a better explanation?

I also have my Humax set to padding by default. When I tried to set a single program to use AR (there were two consecutive episodes broadcast together) 5 out of the 6 recordings resulted in a "Failed to track" error. I've never tried AR again since.

 

[MontysEvilTwin]

This is what happened when recording the Bridge II this weekend:

HDR1 (device on Sutton Coldfield transmitter - HD recording - AR: default setting = padding): Both failed, no TS/ NTS files saved, zero length HTM
HDR2 (device on Sutton Coldfield transmitter - HD recording - padding):
Both successful
HDR3 (device on Sutton Coldfield transmitter - HD recording - AR: default setting = AR):
Both successful

Recording failure seems to occur when using AR on a machine where the default setting is padding. I have used this feature before successfully so I don't know why it is a problem now. Is it an issue with adjacent, series-linked recordings?