Queued Tasks: decrypt Already decrypted

S

SunnysideUK

Member
I've an oddity that I've not seen before.
I have a series recording for Planet Earth II on BBC4 HD (LCN:106). I post process the recordings once they've been decrypted but yesterdays episode 4 listed as already decrypted. I posted it to decript again but same came up. Here I expect the process looks as the Decrypted flag and bases its decisions on that.
I renamed the file, cropped it (& re-generate the .NTS to get the bookmarks to place correctly, etc) and then used the never tried before Webif: Decryption (direct, slower), but with the same effect.

Previous day and today's recordings processed normally as seen in the image below.

Planet Earth Queue - Decryption 2.PNG


Q. Short of downloading the 2GiB file and seeing if it will play on my laptop, how can I determine it is actually decrypted (I think it can't be)?
 
SunnysideUK said:
how can I determine it is actually decrypted
Click to expand...
You can do it from a command prompt with the stripts utility using the -E option. A result of 1 means it's encrypted and 0 means it isn't. You can modify the flags with the hmt utility.
 
Thank you. Result is 0,
Although I don't understand how it can be from the Queue Task entries and timing as it attempted decryption ~16 seconds after recording finished.
 
SunnysideUK said:
Q. Short of downloading the 2GiB file and seeing if it will play on my laptop, how can I determine it is actually decrypted (I think it can't be)?
Click to expand...
You wont be able to generate thumbnails if it is actually encrypted - use the webif bookmarks option - set a random bookmark - click Generate Thumbnails
1706910671768.png
 
There are couple of oddities
  1. Why was the episode recorded on the 30th not submitted for decryption for almost 24 hours?
  2. The episode for the 31st didn't actually put the already decrypted status message until 20:06 which is adequate time for decryption to have completed. Perhaps there was a glitch at the end of decryption that caused it to restart and it then found it was actually decrypted. I think it retries if the decrypted file length differs from the original
Try posting the section of auto.log for the period
 
You can also run diag fixencflags to fix files where the hmt encryption flag differs from the actual recording
 
You must log in or register to reply here.
Back
Top