• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

DEC Flag set but recording still encrypted

H

HarveyB

Active Member
I'm sure this was covered somewhere but I can't find it.
I have a recording (Odyssey from 16 Aug) which I recorded from BBC 2 SD.
I know I haven't decrypted it but the DEC Flag/Icon is showing on WEBif.
The recording just shows blank screen when I try to play.
The file size is correct for 45 min program.
I have run fixencflags but no effect.

Any ideas?
Would upsetting DEC flag help, if so how?

I'm running cf 3.03, fw 1.03.12, latest WEBif (1.2.4..) and all packages up to date.

EDIT: I did have to run fix disk on 17 Aug to fix a pending sector problem (that occurred on 16th) so that may have caused the initial problem, I suppose.
 
Last edited:
You can get some info. on a recording by running hmt from a telnet command line e.g.

Code: 
humax# hmt /media/My\ Video/Titanic1953_20140430_1540.hmt
Format:SD
Title:Titanic1953
ITitle:Titanic
Channel:15 (Film4)
Folder:/mnt/hd2/My Video/
Filename:Titanic1953_20140430_1540
Genre:Film (16)
EPG:(1953) Drama. An unhappily married aristocrat (Barbara Stanwyck) fatefully boards the doomed liner at Cherbourg, having taken her two children away from her husband (Clifton Webb).  [S]
Raw file is encrypted on disk.

Recording Status: Valid (OK)
Flags: SD,Unlimited Copies,ODEncrypted,
Copy count:0

Scheduled start:1398872400 (Wed Apr 30 16:40:00 2014)
Scheduled duration:6900
Recording start:1398872447 (Wed Apr 30 16:40:47 2014)
Recording end:1398879321 (Wed Apr 30 18:35:21 2014)
Duration:6874
Stored duration:6869
Play resumes at:6543 seconds in.
Timezone offset:3600

Service ID (SID):8385
Event ID:17535
Transport Stream ID (TSID):8198
Originating Network ID (ONID):9018
Programme Map Table PID (PMTPID):1500
Video PID:1501
Audio PID:1502
Bookmarks:0 =
humax#

Notes on hmt in the WiKi HERE
 
If you ran the 'fixencflags' diagnostic from Web-If, try again from Telnet. This diagnostic should be able to remove the false 'Dec' flag, making the file playable. If it still fails, an easy way to fix it is to use the Sidecar package to create a new hmt file: this takes just a few seconds.
You could alternatively use the hmt tool to reset the flag (see above) or manually edit the hmt file with a hex editor.
 
I'm not a Linux user, but know a few basic commands, however, having navigated to /mod/webif/lib/bin when I enter fixencflags it says not found. Though it is listed in ls.
I assume this is something to do with the developer language.
So what command do I use please?

EDIT: sorry, you can ignore this, I just found it in wiki:
Code: 
diag fixencflags

Didn't fix it though, so will try regenerating sidecars.

Ps. hmt did not show file as encrypted in output.
 
Last edited:
You can run a diagnostic from the telnet menu, just choose the diagnostic option.
From the command line, type

diag fixencflags
 
Fixencflags did not make any difference whether run from Maintenance menu or telnet.
I regenerated HMT file now it has both DEC flag and shrink icon next to it, so I seem to be going in the wrong direction!

Not to worry, I'll try and edit HMT file, when I find appropriate flags.
But I have pulled it off iPlayer just in case.
 
HarveyB said:
Would upsetting DEC flag help, if so how?
Click to expand...
From the perspective of someone who can't use CF (I have a 2000T) - my answer to this is Yes (based on experience).
If the DEC flag is based on the contents of .hmt file location 0x028e then, if the flag says it is decrypted, the Humax doesn't try to decrypt the file when playing - so if the file really is encrypted it wont work. If the file really is decrypted but the flag says it's encrypted it also wont work.
If you can find Raydon's .hmt file description (sorry can't remember where it is), and look up location 0x028e - it would seem that setting this to 0x01 should tell the Humax the programme is encrypted. That might be worth a try.
 
Sounds odd. I wonder if there is some corruption in the ts file? Thinking about it, Sidecar needs a decrypted ts file to create the nts. Is the same true for the hmt? Apologies if I have given you shonky advice. I heard it said that frying bacon in the early hours after an evening of drinking is a bad idea: posting on forums is too. OK you can use the HMT tool from Telnet:

Code: 
cd /media/"My Video"

hmt +encrypted filename.hmt

hmt -shrunk filename.hmt
This assumes that the file in question is in the My Video folder. I usually temporarily rename recordings to something short using Web-If so I don't have to type long filenames in the command line.
If it still doesn't play, try decrypting the file and recreating the hmt again with Sidecar.
 
Creating a new HMT file generated a new one with today's date in time stamp.

I decided to rectify this by editing the start and end time stamps (offset 0x0280 & 0x284).
I was successful but during the process discovered that the Hex values are stored in reverse order.
Example:
Date/time of 16/08/2015 21:02 yields Epoch date 1439758920
This yields Hex 55 D0 FA 48.
But is stored in bytes 00 to 03 of offset 0x0280 as 48 FA D0 55.

The same applies to end time stamp (0x0284).

Can somebody update the HMT File Format on Wiki to show 0x44332211 in column 3 for these two field please.
As I stated earlier I'm not a Linux user so don't know whether this is normal for storing such fields - seems odd to me but my programming days were spent on PL/I and COBOL .... so what would I know!
 
Your programming experience in high level languages presumably didn't take you down to how the data was actually stored in RAM. It's nothing unusual to have the least significant byte first - that's called "little-endian". Some processors do it that way, other processors are big-endian. It doesn't matter to the processor (as long as you conform to its requirements), it's just less convenient for humans* to read. Little-endian is, I believe, a little more efficient for arithmetical operations in 8-bit processors.

It's nothing to do with Linux as such - although the implementation of Linux for any particular processor will have to adopt that processor's storage conventions, otherwise there will be a lot of efficiency lost while byte orders get swapped around.

IIRC, there are even processors where the byte order is configurable.

* Or, at least, the section of the human population that read left to right and/or put the most significant digit on the left.
 
Last edited:
HarveyB said:
Creating a new HMT file generated a new one with today's date in time stamp.
Click to expand...
I think, because the ts file was still encrypted at the time, that Sidecar just created a basic hmt file. If you have decrypted the file, but not cropped or shrunk it, Sidecar should now create one with the correct timestamps and synopsis data. You could back up the current hmt file and try creating a new one again.
 
BH.
Unfortunately, it was virtually impossible to write complex commercial programs without encountering numerous dumps.
My experience was mainly on large IBM mainframes and I doubt anybody managed to work on such without encountering at least one "OC4" failure.
The dreaded "protection exception" ....

Perhaps that's why I had the misunderstanding, they were big endien.
 
HarveyB - Sidecar only runs on decrypted ts files. If the file is encrypted (ODencrypted), the option in Web-If is greyed out. If you use the hmt tool to make it seem decrypted, you get the option to run Sidecar but it gives you an error message and doesn't work when you try and run it. It does seem likely that the encryption state of your original file was set incorrectly in the ts file as well as the hmt file.
 
I did suggest a mod. to sidecar to generate a dummy .hmt file if the .ts file is found to be encrypted, just to allow decryption to occur, but it hasn't apparently found favour with the developer...
 
You must log in or register to reply here.
Back
Top