Failed BBC3 and BBC4 SD Records

Private61

Member
Hi,

In the past week just over, the lastest today (19-04-2014), recordings from BBC3 and BBC4 SD have failed. One stated it was scrambled (BBC4), another said no AV (BBC3) and others just fail to play on the Humax iteslf.

Also noted that the recording for Snog Mary, BBC3, 19-05-2014 at 19:00 using padding, showed in the WebIf as being decrypted before it had even stopped recording. Autouncrypted had been turn off before this recording had taken place and a manual retune of channel 22 (all SD BBC's channel) on the Belmont transmitter done.

The file shows a blank for the thumbnail, slow initial processing on play then fails with no message or the one of the two "no AV" or "Scrambled". Copying to USB no improvement, cannot manual decrypt (see Snog Mary).

All works OK on a second FoxT2.

System 1 (Faulty) - HDR FoxT2 (500GB) firmware 1.03.12, customer firmware 2.22, WebIf 1.0.13-1 (also same with 1.0.12)
System 2 (Working) - HDR FoxT2 (500GB) firmware 1.03.06, customer firmware 2.21, WebIf 1.0.13-1 (also same with 1.0.12)

Any one else had problems like this or any one can advice, so far I've only found posts about BBC3 and BBC4 HD, yes I am still using the SD service for now.

My next move is to reset System 1 and set it up to match System 2 incase a recent change or developing problem is occuring with 1.03.12.

Thanks for any help offered
 
Do you have generally successful recordings from other services (ie the problem is confined to the recordings you reported), or are these the only recordings you made in the period?
 
Odd, Winter Hill transmission fine on BBC3HD/4HD last night, recorded/played back the wonderful Coren Mitchell and Barely Legal Drivers without issue. although the last couple of weeks, Ripping Yarns recordings have shown a .TS extension, rather than a .ts, anyone shed light on this?. Cannot edit the .TS files on Videoredo...
 
The same happened to me a couple of weeks ago with Only Connect on BBC4HD. A sporadic fault has been reported on this forum, a few times, whereby the hummy is believed to temporarily lose its decryption keys. After rebooting the box is back to normal, but any recordings made during this period are scrambled. I assumed this fault caused the problem, but perhaps not? All all users with problems on 1.03.12 software? If anyone still has a scrambled recording and it has gone through the auto-decryption process, could they delete the sidecar files and try playing the naked TS file.
 
On my failed recording the file had the decrypted icon
2edpb2s.png
showing, even though the program was still recording.

I don't have auto-decrypt set on the Humax.
 
That is strange because AFAIK, decryption only takes place when the recording is complete and not during.
 
Do you have generally successful recordings from other services (ie the problem is confined to the recordings you reported), or are these the only recordings you made in the period?

I have had many other successfull records from BBC1, BBC2, ITV1, Drama inparticular. As I type I am testing recordings from BBC's children channels as I believe they share the same frequency before I remove all firmware and start afresh.

Update
The BBC's childrens programmes recorded successfully.
 
My failed file also has the DEC icon like ian_j but I do not have auto decryption switched on.




Sent from my iPhone using Tapatalk
 
Deleting the sidecar files result in "Cannot support this file format"

I made a copy though for further analysis.


Sent from my iPhone using Tapatalk
 
My failed file also has the DEC icon like ian_j but I do not have auto decryption switched on.
Are you on 1.03.12 firmware? The others reporting this are. I wonder if it's a new bug? The presence of the Dec flag indicates that something has altered the .hmt file, but it is a mystery why this has happened.
 
Yes I am on 1.03.12. This bug seems to have been around for a while but it it may be quite rare.

I'm just copying the files off my box to my laptop to examine them further.


Sent from my iPhone using Tapatalk
 
Hi, Update after reverting the offending Humax to Firmware 1.03.06(a) and Customer Firmware 2.21.

Two recordings produced, one on BBC3 (SD) and a second on BBC4 (SD), autodecryprt off and padding used.

Both seem to play fine and copied to computer and played on there OK, so the fault may be fixed. I will re-instate autodecrypt and go back to my normal procedures and see what happens, if I have further problems I bring everyone up to date.

As an aside, when installing 1.03.06 and then re-tuning I felt that something flickered by and may be there was a conflict with a local transmitter, just a “what was that” no real evidence during retune. I normally erase all duplicate channels and avoid using the local transmitter as it has a limited service.

I think that the real cause could be settings in the firmware/customer firmware but I hadn’t made any changes for a while before the problem occurred, so I’m wondering if theirs a fault in 1.03.12 which develops over time and hit BBC3 and then a few days later BBC4. I had recordings on each often but spotted the BBC4 problem nearly a week after BBC3.

Hope this helps others, any further comments or suggestions welcomed.
 
Deleting the sidecar files result in "Cannot support this file format"
I thought that deleting the sidecars would be a long shot, but I was wondering if this problem is in any way related to the NTS bug that firmware version 1.03.12 was designed to fix. In that case, deletion of the sidecars after decryption allowed the recordings to be played. The error message you got when you tried to play the file without sidecars indicates that the file is not decrypted: how could it be if you did not have autodecrypt set up? The appearance of the Dec flag though means that the HMT file has been altered or corrupted in some fashion; how this has happened is unknown.
There are a few cases reported now, all from machines with 1.03.12 installed. The problem does seem similar to a previously known fault, believed to relate to a decryption key error. This fault though was quite rare, which makes me think that the changes made in 1.03.12 either make the fault more likely to occur, or it is a new bug entirely.
 
I think it IS corruption on the .hmt as it shows both ENC & DEC flags at the same time..


Sent from my iPhone using Tapatalk
 
Is this the same as the OP though? He was talking about StDef, but the topic seems to have drifted onto HiDef.

Just seen that Barry has managed to replicate the bug last night and will be speaking with Humax today..
Was the bug reported on MyHumax, or has it been harvested from here? If from here, it should be responded to on here.
 
Back
Top