Failed Recording of New BBC Four HD Channel

As it seems to be totally random, could weather conditions at the time the recording ended be another consideration. Before the switchover our digital signal was very sensitive to the weather because we are not in direct sight of the transmitter, and are in the shadow of a few hills / mountains. kView attachment 907

When a programme is recorded after it has started it takes 30s for it to appear in the media list. The HDR then will calculate its (estimated) duration presumably based on the current network time and scheduled finish. If that recording is stopped(e.g. after 2 minutes) when it is finalised the true programme duration is then calculated (again using the network time). What if due to the lie of the land and the weather the HDR was unable to get a network time when the recording finished and thus assigns the end time the (exact) same time as the start time. The attached is a screen shot of a failed recording of Osec duration.
In that case the corruption in the .nts/.hmt file could be one simple field, and amenable to repair?
 
That was on Friday night, but on Saturday night I had three failed BBC FOUR HD recordings.

I've had a couple of flips as well. One of them I had just been using the HDR as usual. In the morning it was failing CBBC HD and a couple of hours earlier recording BBC3 HD OK. Then come later in the day CBBC HD was OK and come 7 o'clock BBC3 HD was failing. I hadn’t changed any settings or retuned at all

On a different HDR which was consistently failing CBBC HD and recording BBC3HD OK I made a deliberate effort to switch it round through juggling with the manual tuning. A few minutes later a 1 minute recording for CBBC HD was now OK When BBC3 HD came back up that had also switched.
I did make notes of what I did tuning wise but I don't think the specifics matter as I have not been able to switch back. I suspect it was just a retune that flipped it as repeating the exercise in reverse makes no difference.

I've now got 3 HDRs that all fail on BBC3 HD and are OK on CBBC HD. (1.02.20, 1.02.29/32 and 1.03.06).

The transmitters I'm using are Sudbury, Crystal Palace and Sandy Heath. The manual retune for the PSB3 mux lists BBC3HD first and then CBBC HD. I'm wondering if this is indicative of the underlying way that these are setup to chare the same space.
 
This is reminiscent of the old AR problem where different people/boxes had a different experience even on the same service from the same transmitter.
 
All of my recordings from BBC4 HD were successful..

Could somebody who consistently gets failures monitor to see whether the .nts file is created at zero bytes and stays that way throughout the recording, or if it gets truncated when the recording stops? If the latter then it would be possible to develop a workaround.
 
All of my recordings from BBC4 HD were successful..

Could somebody who consistently gets failures monitor to see whether the .nts file is created at zero bytes and stays that way throughout the recording, or if it gets truncated when the recording stops? If the latter then it would be possible to develop a workaround.
Both episodes of The Bridge recorded successfully from BBC4 HD last night (Crystal Palace, 1.02.32). I have not tried BBC3 HD or the kiddies' programmes, which I don't use, but have not had a failure with BBC4 HD for some time now, so this issue is resolved as far as I am concerned - for the time being, at least. It remains mysterious though.
 
Both episodes of The Bridge recorded successfully from BBC4 HD last night (Crystal Palace, 1.02.32). I have not tried BBC3 HD or the kiddies' programmes, which I don't use, but have not had a failure with BBC4 HD for some time now, so this issue is resolved as far as I am concerned - for the time being, at least. It remains mysterious though.

Both my Bridges failed, on Winter Hill. I don't think I've had a successful BBC4 HD recording yet.

HOWEVER, using the guide in post #239 a couple of pages back I have successfully 'fixed' them. Yay!
One question arising from that (apologies as it's a bit OT): I used the CFW to send the series recordings to a fixed folder and having checked these two were actually broken I set the folder to auto-decrypt and then did the necessary. If I now leave the folder as it is then it will presumably decrypt all future Bridges as well. If they are broken, that is obviously what I need, but if any are not broken will this cause any problems? (I think the answer is probably 'no', but I feel I should check - just in case :oops: )
 
Could somebody who consistently gets failures monitor to see whether the .nts file is created at zero bytes and stays that way throughout the recording, .

Here is one recording at present and the nts file is at zero bytes.tmp_Screenshot_2014-01-05-15-10-10~2-1299606095.jpg
 
but if any are not broken will this cause any problems? (I think the answer is probably 'no', but I feel I should check - just in case :oops: )
Many (most?) of us routinely decrypt everything (automatically) because of the added flexibility in what you can do with it afterwards.

There is just an ever-so-slight risk that something cocks up during the decryption pass that makes it through the post-decryption checks so that the original copy gets removed leaving a corrupted version in its place. Even then, if you have undelete installed (and enough free disk space to run the waste basket) the original can still be rescued if you notice the problem in time.
 
Here is one recording at present and the nts file is at zero bytes.
The point was to monitor the files while they were in the process of creation, using FTP or Telnet, to see if the .nts is empty throughout or only becomes empty at the end. I don't know whether this is also possible through the WebIF media browser.
 
The point was to monitor the files while they were in the process of creation, using FTP or Telnet, to see if the .nts is empty throughout or only becomes empty at the end. I don't know whether this is also possible through the WebIF media browser.
That was a screenshottmp_Screenshot_2014-01-05-16-01-40~2-1299606095.jpg of webif during a recording. here is another less than a few minutes into another impending failed recording.
Interestingly when the recording is finished the end time and duration of the recording on webif is correct. When you try to play the recording on the HDR the next time you check the webif the end time is shown the same as the start time and the webif duration shows up as 0secs. I don't know if this will shed more light on the problem. I don't tend to watch HD channels.
 
Here is what webif tells us a few minutes into a failed recording.

tmp_Screenshot_2014-01-05-16-01-40~22092883501.jpg
When the recording is finished before attempting to play it.

And finally after trying to play it and getting the 'recordings less than 30 seconds won't be stored' error.

Note the duration of the file changes on the webif only after the attempt to play the recording. on the box the duration of the recording is 0secs throughout.

I did try to see what happens at 31 secs (I.e. when recording appears on the media list), but got distracted!
 

Attachments

  • tmp_Screenshot_2014-01-05-16-41-37~2412234138.jpg
    tmp_Screenshot_2014-01-05-16-41-37~2412234138.jpg
    123.9 KB · Views: 10
  • tmp_Screenshot_2014-01-05-16-56-29~2832985578.jpg
    tmp_Screenshot_2014-01-05-16-56-29~2832985578.jpg
    74.2 KB · Views: 10
All of my recordings from BBC4 HD were successful..

Could somebody who consistently gets failures monitor to see whether the .nts file is created at zero bytes and stays that way throughout the recording, or if it gets truncated when the recording stops? If the latter then it would be possible to develop a workaround.
If you could tell me how to do that I will.

Also if you are getting BBC4 HD then CBeebies HD will most likely fail, if my 3 HDRs on 3 different softwares ans using 3 different transmiteers is anything to go by.
 
luke : If you could tell me how to do that I will.
Border has demonstrated in #268, #271 and #273 that "the .nts file is created at zero bytes* and stays that way throughout the recording"

*or at the very least soon after creation and before recording ends
 
I have successfully recorded CbeebiesHD, CBBCHD, BBC3HD and BBC4HD, after a few failures, on my HD and HDR from Emley Moor.

Currently I am "resting" recording BBC3HD whilst continuing to record The Bridge II on BBC4HD.

Here is my record for BBC3HD and BBC4 HD so far. Failed recordings in Red; successful in Green. Times are mixture of as-set and as-recorded but that is not significant.

Martin
 

Attachments

  • BBC3HD and BBC4HD Recordings on HD Fox-T2.pdf
    37.3 KB · Views: 6
  • BBC3HD and BBC4HD Recordings on HDR Fox-T2.pdf
    37.3 KB · Views: 4
Today HDR2 (watching BBC1 HD) had multiple failed recordings on CBBC HD yet HDR1 recorded one successfully (Edit this recording was a failed recording on HDR2). (HDR1 was watching BBC1 nonHD). I only tried one recording on HDR1. Both boxes recording BBC3 HD successfully tonight.

Both boxes on same transmitter. Does that suggest electrical interference within the home or some settings on the box that are different?


Previous failed recordings on HDR1 and HDR2 on BBC3 HD on different days, and we don't get BBC4 HD yet.
 
If they are during the recording, how the heck does it know the end time?
From my limited understanding and reading the forums when a recording is started a HMT file is created that stores this type of detail. When the initial HMT file is created it may estimate the file duration, obviously this is not always going to be the recordings duration (e.g. when the recording is stopped manually or when a recording conflict occurs). So when the recording is first accessed or indexed perhaps then the final duration is calculated.
 
That doesn't add up though. Your screenshot in post 271 shows a capture which is only 48MB into a recording that should be about 1.5GB - roughly a minute in. I don't know where it could have got an end time of 1627 from, the scheduled end is 1625 and it started at the scheduled time of (more or less) 1600 - unless you have -0 +2mins padding set??
 
Back
Top