Failed recordings on BBC3 HD and BBC4 HD

prpr

Well-Known Member
So, I attempted to record 2 things on both BBC3HD and BBC4HD on Friday.
All recordings appear to have worked and all the file sizes look normal.
Everything is auto-unprotected and auto-decrypted and the originals chucked away after 2 days.
Now I come to check them (3 days later!) and 1 recording on each channel gives "This channel is scrambled or not available". There are no complaints from any logs about decrypt failures etc.
The box is running 1.03.12 mod 2.23 and was retuned/rebooted last Monday.

Anyone got any ideas about why, or how to determine what it has recorded and won't play?

It's really exceedingly irritating how this stupid box sometimes fails to record at all, sometimes records but can't replay, and sometimes records and replays fine. This problem only afflicts BBC3HD and BBC4HD that I've found, never the 'proper' HD channels.
 
This seems to be a common but rare issue. The problem is finding a way to replicate the issue time & time again so that we can pass the detail on to Humax engineers.

Last reports I read are that it may be caused by a retune and the 1st recording on BBC3/4 which sounds like your scenario if this was your first record of BBC3/4.

Last time it happened to me, the failed recording was showing both Enc & Dec flags at the same time - but I had just upgraded the HDD and had not put auto-decrypt back on.
 
It was indeed the first recording on both channels since the retune. Thanks, that is useful info. to know and I can now test in a controlled manner. Will get back to you when I've done so.
 
Unfortunately I only found this thread after I had a failed recording on BBC4HD last night.

Good to know how to avoid it in future though.
 
I've just retuned my spare box and it is now showing this whilst still recording on both channels:

Screenshot.png

A test earlier on this afternoon with the equivalent kids' HD channels showed no problems.
 
Looks like what happened to me. If they refuse to play, then it again stacks up with the theory of the first record following a retune..


Sent from my iPad using Tapatalk
 
After the recordings finished, presumably auto-unprotect kicked in and removed the 'enc' flag but left the 'dec' one? What happens if you use the hmt tool to remove the 'dec' flag. Will it play and decrypt normally?
 
Yes, Auto-Unprotect removed the Enc flag. Removing the Dec flag manually made it playable again. Manually decrypting it at that point also succeeded.
Poking about with hmt yielded the following...

First recording:
HD,New,Limited Copies,Encrypted,

After unprotect:
HD,New,Unlimited Copies,

After removing Dec flag manually:
Raw file is encrypted on disk.
HD,New,Unlimited Copies,ODEncrypted,

After decryption:
HD,New,Unlimited Copies,


Second recording:
Raw file is encrypted on disk.
HD,New,Limited Copies,Encrypted,ODEncrypted,

After unprotect:
Raw file is encrypted on disk.
HD,New,Unlimited Copies,ODEncrypted,

After decryption:
HD,New,Unlimited Copies,

Aside from the terminology problem here, where 'Encrypted' means protected and 'ODEncrypted' means encrypted, it would seem to me like a possible workaround when auto-unprotecting could be:
Code:
if Encrypted then
{
  remove Encrypted flag
  if not ODEncrypted then
    set ODEncrypted flag
}
else
  do nothing
as you should never be able to have Encrypted set without ODEncrypted.
 
Duh, obviously that simplifies to:
Code:
if Encrypted then
{
  remove Encrypted flag
  set ODEncrypted flag
}

and it's a 1 line mod. in /mod/sbin/unprotect, although I'm not sure it actually tests for Encrypted specifically, which would make it a disaster if the ODEncrypted flag got set on somthing that was already unprotected and decrypted.
 
After the recordings finished, presumably auto-unprotect kicked in and removed the 'enc' flag but left the 'dec' one? What happens if you use the hmt tool to remove the 'dec' flag. Will it play and decrypt normally?

Where is the hmt tool? The last time I tried to record from BBC4 HD it failed, but I'm trying it again tonight. Might need it.


Sent from my iPad using Tapatalk
 
Thanks, no I didn't know.

I have found the package notes now.

One more numpty question (not able to experiment now). How do I navigate to the relevant directory in CL?


Sent from my iPad using Tapatalk
 
and it's a 1 line mod. in /mod/sbin/unprotect, although I'm not sure it actually tests for Encrypted specifically, which would make it a disaster if the ODEncrypted flag got set on somthing that was already unprotected and decrypted.
Turns into a 4 line mod.:
Code:
--- /mod/sbin/unprotect~
+++ /mod/sbin/unprotect
@@ -20,7 +20,10 @@
 {
 if hmt "$1" | grep -q "^Format:HD"; then
        # High definition
-       hmt -protect "$1"
+       if hmt "$1" | grep "^Flags:" | grep -q "Encrypted"; then
+               hmt -protect "$1"
+               hmt +encrypted "$1"
+       fi
 fi
 }

Test for real tonight at 19:00...
 
Does this explain why it is only BBC Three and Four HD that gives rise to problems?


Sent from my iPad using Tapatalk
 
One more numpty question (not able to experiment now). How do I navigate to the relevant directory in CL?
Use the cd command. For names with spaces in, you'll need either to use quotes around it all or to escape them using the \ key.
The Tab key comes in very handy for auto-completing as far as it can.
 
Last edited:
Use the cd command. You'll need to use either quotes around names with spaces in or escape them using the \ key.
The Tab key comes in very handy for auto-completing as far as it can.


Thanks. I used MS DOS 25 years ago, this seems familiar. Will give it a go later.


Sent from my iPad using Tapatalk
 
I have had what I think is the same issue on a standard definition channel a couple of weeks ago. I retuned two muxes to sort out the channel numbers of Quest and Quest+1. Then I set up several consecutive episodes of the same programme to record on Quest. When I got round to watching, the first episode gave the 'channel scrambled' error. In Web-If, all episodes had the 'Dec' icon. I looked in the deleted items folder for the original, but it was not there. In auto.log, there was no entry corresponding to the decryption of the first recording. I copied over a hmt file from one of the other episodes from the deleted items folder and renamed to match the 'scrambled' recording after moving the original. This enabled the file to play correctly. A few minutes later, the file was automatically decrypted successfully.

Does auto-unprotect scan the hmt files for both standard and high def recordings? If it does not scan standard def programmes then prpr's solution will only work for the high def ones.

Edit. From the code in prpr's message (no.14) it works on high def files only, but this could be changed.
 
Last edited:
Test for real tonight at 19:00...
Didn't work because the auto-unprotectd daemon is calling unprotect with the --skip-hmt option which bypasses the code I modified.
I wonder what the implications are of removing this bypass?...
I have had what I think is the same issue on a standard definition channel a couple of weeks ago.
I'm sure I've had this on maybe one occasion. It's not possible to fix this automatically the same way because there is no other flag to test to spot the error.
Does auto-unprotect scan the hmt files for both standard and high def recordings? If it does not scan standard def programmes then prpr's solution will only work for the high def ones.
I don't know what the daemon does. af123 will have to answer that one. I suspect it passes all recordings to unprotect as it would otherwise be pointless testing in there for HD as well.
 
Back
Top