• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Failed Recording of New BBC Four HD Channel

af123 said:
Have you tried the new .nts along with the original .ts?

You could also try removing the sidecar files leaving just the .ts and see if that plays.
Click to expand...
I have just tried removing the sidecar files from my recording, and it now plays.
 
Could it be the shrink or decrypt processes which are breaking it or have you seen the problem with standard recordings?
 
I don't use shrink, so am not sure about that.

I tried replacing the HMT file, but that broke it again. After removing it again, the recording plays again.
 
While shrink rewrites the .nts, decryption does not so it is unlikely that the problem is caused by decryption.
 
There have been reports of similar failed recordings from users without custom firmware, so CF is unlikely to be responsible.
 
I wonder what the technical difference is between the successful and failed recordings? Indeed, between those and the other HD channels that record OK. There must be a difference in the data surely?
 
Wallace said:
I wonder what the technical difference is between the successful and failed recordings? Indeed, between those and the other HD channels that record OK. There must be a difference in the data surely?
Click to expand...
I would have thought there must be a difference. The question is whether the data is within the parameters of the relevant specification in which case the problem is down to Humax or violating the specification in which case the problem is down to the broadcaster. Of course it may be that it is something where the specification can be interpreted in more than one way in which case it gets messy.
 
It's very curious. These observations imply that the sidecar files are not simply created on the fly but depend on some specific data that accompanies the broadcast TS stream, which is somehow causes a variety of problems on these new HiDef channels.

Is AV2HDR supposed to work with HiDef? The sound stream will be AAC I think.
 
brian said:
There have been reports of similar failed recordings from users without custom firmware, so CF is unlikely to be responsible.
Click to expand...
Barry over on myhumax.org has reported recording failures HERE and said he is using a 'later firmware' so it's unlikely he is running the CFW as well
 
Greecian said:
Well, Well, Well.....:( :(
I've got two of these boxes, one is approx two years old running standard software 1.02.28, loader a7.30 , the other is about a month old running standard software 1.02.29 loader a7.33 . Both boxes were set to record BBC 4HD @ 19.00 & 20.00 tonight (it was an error I'm getting on a bit :() ....... The older box recorded OK, the new box didn't! It failed with the 30 second error message. ........Problem with the 1.02.29 software?

Edit: I've set up both boxes to record identical programmes later tonight on BBC3 HD & BBC4 HD. I'll update tomorrow what happens

Gerry
Click to expand...

Below are the results of my test last night:-

OLD BOX

BBC3 HD (AR recording) 22.25 The Revolution.......... Failed recording, '0' minutes
BBC4 HD (AR recording) 22.00 Arena......Successful recording.

NEW BOX

BBC3 HD (AR recording) 22.25 The Revolution..........Successful recording.
BBC4 HD (AR recording) 22.00 Arena......Successful recording.

No pattern there then! :( :(.

Gerry
 
Ezra Pound said:
If anyone is still having problems recording any of the new HD channels, I think it would help narrow down the cause if they all reported the same data e.g.

New or old hardware ( horizontal or vertical UHF connectors) Old
Which Firmware Version 1.02.29
Which CFW Version 2.13
AR or Padding used AR
Instant, Manual or schedule recording etc. Scheduled
Which TV transmitter was used Sandy Heath
Which TV channel was recorded BBC4HD
Name of TV programme Lou Reed Remembered
Obviously whether the recording was successful or not One unsuccessful, one successful
Click to expand...

Last night at 9:01 I noticed that Lou Reed Remembered (the first programme I've recorded off BBC4HD) had started to record (alongside Homeland), but hadn't appeared in the library after 5 minutes. The EPG and Info showed it was recording, pressing Stop gave it as an option to cancel. When it had finished it showed as 0 min and gave the '..shorter than 30 seconds...' message. I scheduled the 03:00 repeat and that has worked fine.

The earlier recording has a 0 byte NTS file, the later is 5.9M.

Differences between 1st and 2nd attempts:
I was watching a recording the 1st time.
There was another (HD) recording in progress the 1st time.
The box was in standby the 2nd time.

Hope that helps.
 
Results of tests on HDR Fox-T2 (1.02.28), HD Fox-T2 (1.02.28), Tvonics HD500 (latest software) all tuned to Emley Moor and using AR.

Programmes scheduled:

a. BBC3HD 22:00 Family Guy
b. BBC3HD 22:25 New: The Revolution will be televised (consecutive recording to above)
c. BBC4HD 00:30 Ziggy Stardust and the Spiders from Mars
d. BBC4HD Lou Reed Remembered

Results

All 3 units recorded show the programmes in their libraries.

HDR Fox-T2 shows 0 min for the length of every recording and thus will not play any.

HD Fox-T2 plays the two BBC3HD programmes but shows 0 min for the BBC4HD programmes so will not play.

Tvonics HD500 shows and plays all 4 programmes correctly.

Subsequent Action

Deleted the BBC4HD Ziggy Stardust recording from the HD Fox-T2. This released 2Gb of storage on the HDD.

Preliminary Conclusions

The programmes are being recorded but there are inconsistent problems with the Humax's subsequent cataloguing of the recordings.

There does not appear to be a problem with the actual broadcast.

Martin
 
MartinOnline said:
The programmes are being recorded but there are inconsistent problems with the Humax's subsequent cataloguing of the recordings.
Click to expand...
The Humax writes the .nts file out at the same time as the recording so I don't think this is related to cataloguing. An interesting observation would be whether the .nts file is zero bytes all the way through the recording or if it is growing in the normal way and then somehow being truncated at the end. I would guess at the former.
 
Greecian said:
I used AR both times, i.e unsuccessfully initially & now successfully on BBC 4 HD. Box is HDR Fox T2 1TB and transmitter is Crystal Palace.

Gerry
Click to expand...
I used auto-padding with both the original failed recordings and the later successful ones (also Crystal Palace). I wonder if this is a red herring because if it was relevant it would affect recordings on other channels too, such as BBC2 HD, where there has not been a problem. I think it's time for the BBC to come clean and confess what has been happening!

Or might this be a Humax issue after all?
 
slotph said:
I used auto-padding with both the original failed recordings and the later successful ones (also Crystal Palace). I wonder if this is a red herring because if it was relevant it would affect recordings on other channels too, such as BBC2 HD, where there has not been a problem. I think it's time for the BBC to come clean and confess what has been happening!

Or might this be a Humax issue after all?
Click to expand...

Yes, padding v AR appears to be a red herring in this case, but when there are recording failures it is one of the "usual suspects" to be rounded up. At the time I didn't know about the existence of sizeable .ts files not playing because of sidecar file errors.

On the face of the information currently available (I do not have a COM7 feed to play myself - Mendip isn't due until July and I get Wenvoe from a relay which will never carry COM7) this appears to be an incompatibility between the BBC and Humax - who is actually at fault we cannot say at present, but if recorders from other manufacturers are not having the same problem we can hazard a guess. That the original HiDef services have not shown the same problem (ever!) indicates there is something different about the COM7 services, although why not all services on COM7 are affected is another mystery.

It could be that the BBC engineers have decided to trial using some previously unused feature of the broadcast data stream, or stop using something that they think isn't necessary (saving bandwidth), but doubt is cast on this one because of the report that two HDR-FOXes set to record identical programmes achieved different results.

It is all very peculiar, and with my engineering hat on I am watching the reports and trying to form an hypothesis to explain them all - unsuccessfully so far.
 
You must log in or register to reply here.
Back
Top