Playing program and suddenly went Black - ! The channel is scrambled or not available
- Thread starter petrev
- Start date
Black Hole
May contain traces of nut
Proposed solution:
Decrypt/Autodecrypt keeps a history of recently decrypted files, including the checksum of the decrypted file (IIRC that is already being generated). When a file comes up as a candidate (by scan or OPT+ command) it is compared with the history, and if there is a match the checksum of the candidate is checked against the stored checksum. If the checksums match, set the hmt file back to "decrypted".
I was worried about how this affects the Enc flag and Auto-unprotect, but I guess it will just come along and clear the flag again?
Decrypt/Autodecrypt keeps a history of recently decrypted files, including the checksum of the decrypted file (IIRC that is already being generated). When a file comes up as a candidate (by scan or OPT+ command) it is compared with the history, and if there is a match the checksum of the candidate is checked against the stored checksum. If the checksums match, set the hmt file back to "decrypted".
I was worried about how this affects the Enc flag and Auto-unprotect, but I guess it will just come along and clear the flag again?
Black Hole
May contain traces of nut
It would be. The file has been decrypted, but the Humax playback thinks it isn't. There would probably be another decrypt pass later (which then ruined the file).
Not according to the auto.log - Only one Decrypt shown (the log shows a check pass is started every 10 miutes)
Sequence as posted above - Playing during Decrypt is OK but if playback is stopped and then restarted (just after decrypt has finished) the new file is immediately Black. Playing during Decrypt is of the original file and as soon as playback is stopped the files are moved and the new playback is of the now moved-in Black decrypted file (my guess).
Sequence as posted above - Playing during Decrypt is OK but if playback is stopped and then restarted (just after decrypt has finished) the new file is immediately Black. Playing during Decrypt is of the original file and as soon as playback is stopped the files are moved and the new playback is of the now moved-in Black decrypted file (my guess).
Black Hole
May contain traces of nut
The hypothesis above is that the resumed pause plays the new decrypted file as if it were encrypted, hence the "scrambled" message. An encrypted file played as if it were decrypted also gets "scrambled", only due to a mis-match in the status flag, but if a decrypted file is decrypted again the result will be useless.
However, I can't make your observation fit this hypothesis.
I have an idea: if the encryption is symmetrical, passing a double-decrypted file through decryption again should restore it, or setting the flag should make it playable.
However, I can't make your observation fit this hypothesis.
I have an idea: if the encryption is symmetrical, passing a double-decrypted file through decryption again should restore it, or setting the flag should make it playable.
It is not a resumed Pause - It is a file played during decryption process - then stopped (after Decryption has finished) - then restarted (Black) - I seem to remember the Resume-point is not set so this must be the swapped-in Decrypted file.
Sequence of events:
Record a program.
Wait for Decryption to start.
Play the program while it is Decrypting.
Stop Playback after Decrypt has finished.
Wait a few seconds.
Play again - Black
Sequence of events:
Record a program.
Wait for Decryption to start.
Play the program while it is Decrypting.
Stop Playback after Decrypt has finished.
Wait a few seconds.
Play again - Black
Black Hole
May contain traces of nut
So it doesn't say "This channel is scrambled or unavailable" as well as being black then?
Black Hole
May contain traces of nut
I thought I would have a data-gathering play.
After I had watched tonight's recording of Wales Today (after decryption, by network mount) I turned off Recursive Auto-Decrypt on HDR3. I then hmt +encrypted file.ts (why does this use the .ts in its parameters, not .hmt?), and the WebIF media browser showed the Dec icon gone.
What then surprised me is that both HDR1 and HDR3 played the file normally, when I would have expected both to pick up that the file was not decrypted and try to decrypt it in playback.
Then in the HDR3 WebIF the OPT+ Decrypt option was available, so I ran it and got this:
Confused 
After I had watched tonight's recording of Wales Today (after decryption, by network mount) I turned off Recursive Auto-Decrypt on HDR3. I then hmt +encrypted file.ts (why does this use the .ts in its parameters, not .hmt?), and the WebIF media browser showed the Dec icon gone.
What then surprised me is that both HDR1 and HDR3 played the file normally, when I would have expected both to pick up that the file was not decrypted and try to decrypt it in playback.
Then in the HDR3 WebIF the OPT+ Decrypt option was available, so I ran it and got this:
Code:
Processing BBC Wales Today_20130402_1829
Moving recording to /media/My Video/[NEWS]/_original
Runtime Error: execute.jim:52: error copying "/media/My Video/[NEWS]/BBC Wales Today_20130402_1829.ts.decrypting" to "/media/My Video/[NEWS]/BBC Wales Today_20130402_1829.ts": file already exists
in procedure 'file' called at file "execute.jim", line 52
The hmt command will take either the .hmt or .ts as the argument, or the plain recording file name without an extension.