SiHa
Member
First. My apologies if this is the second time you're reading this. I posted about this last night, but I'll be buggered if I can find it today. I searched all my posts and it just isn't there.
Anyway, here goes...
Last night I discovered that if you click on the 'De-Duplicate / Tidy this folder' in the Webif, and then attempt to download a recording, it isn't decrypted as it is sent.
A little experimenting found this: In the .hmt field for the recording there is a field that stores the original filename of the recording. The de-duplicate script does not modify this field, and so the decryption breaks.
If I simply paste in the new filename, say "1_13_Doctor_Who_Spiders_From_Mars" over the original filename, "Doctor_Who_221011_1945" in the .hmt file (padding/deleting spaces as necessary to preserve the structure), it works again.
I'm sure there's a post here somewhere (by Raydon?) with the .hmt file structure, but I can't find it, and haven't got a hex-editor installed at home. So I'm going by the foxsat structure found here http://foxsatdisk.wikispaces.com/.hmt+file+format
It seems to be the block that starts @0x0021
Also whilst experimenting, I discovered that if the programme name generated by de-dup is shorter than the original (@0x0222?) then the remainder of the old programme name is left over:
Original Name Stored @0x0222 "Fifi and the Flowertots"
New Name "Fifi Takes Charge"
New data stored "Fifi Takes Charge rtots"
I'd have a stab at amending the script myself, but my perl/python (or whatever) skills are somewhat limited.
@af123, I assume the de-dup script is yours..?
BTW, If you simply start the file playing on the Hummy after the de-dup run, the .hmt file is regenerated and the file will then decrypt and download as before.
Also, when the decryption breaks, the .ts downloads with the correct filename as opposed to "nnn.ts". Odd.
Anyway, here goes...
Last night I discovered that if you click on the 'De-Duplicate / Tidy this folder' in the Webif, and then attempt to download a recording, it isn't decrypted as it is sent.
A little experimenting found this: In the .hmt field for the recording there is a field that stores the original filename of the recording. The de-duplicate script does not modify this field, and so the decryption breaks.
If I simply paste in the new filename, say "1_13_Doctor_Who_Spiders_From_Mars" over the original filename, "Doctor_Who_221011_1945" in the .hmt file (padding/deleting spaces as necessary to preserve the structure), it works again.
I'm sure there's a post here somewhere (by Raydon?) with the .hmt file structure, but I can't find it, and haven't got a hex-editor installed at home. So I'm going by the foxsat structure found here http://foxsatdisk.wikispaces.com/.hmt+file+format
It seems to be the block that starts @0x0021
Also whilst experimenting, I discovered that if the programme name generated by de-dup is shorter than the original (@0x0222?) then the remainder of the old programme name is left over:
Original Name Stored @0x0222 "Fifi and the Flowertots"
New Name "Fifi Takes Charge"
New data stored "Fifi Takes Charge rtots"
I'd have a stab at amending the script myself, but my perl/python (or whatever) skills are somewhat limited.
@af123, I assume the de-dup script is yours..?
BTW, If you simply start the file playing on the Hummy after the de-dup run, the .hmt file is regenerated and the file will then decrypt and download as before.
Also, when the decryption breaks, the .ts downloads with the correct filename as opposed to "nnn.ts". Odd.