• 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.

'Drama' (Channel 20) not decrypting

peterworks

peterworks

Ye Olde Bowler
I have been recording Death in Paradise as a series for the last couple of weeks on Drama. Suddenly, as of the 2nd of this month, it cannot be decrypted. I deleted the program which failed on the 2nd.
I did a test this afternoon using one program from Drama and one from BBC1 SD. The BBC program decrypted fine but the Drama one did not.
I have attached the auto log, a screen print of the 'Queue' and the warning messages.
Any ideas please ?

I cannot see anyway to remove the auto-decrypt at folder level so the two programs keep retrying.

Capture04-08-2017-16.59.45.jpg Capture04-08-2017-17.00.25.jpg
 

Attachments

  • auto.log.txt
    271.7 KB · Views: 5
Trev said:
Freeview retune on 2nd got anything to do with it?
Click to expand...
Very unlikely.

You could try resetting the DLNA database via the Diag menu but it could be some recording glitch within the file that is causing decryption to fail.
Have you tried watching the programme - does it play OK?
 
I have the same problem - tried on 2 different boxes, both have the problem. I have Drama channel set to "padding" rather than "AR" in the multi-mode settings. I'll try changing it back to "AR" in case this is causing a problem.
 
Thanks MymsMan. I too tried it on my other box and had the same result. Thanks too to phit03 - nice to know I am not alone !
I have reset DLNA but to no avail though, strangely, 'decrypt in-place' works perfectly. This being the case I must assume the files themselves are fine.
I have temporarily removed recursive auto-decrypt to stop the continuous processing.
 
Hi - I have also been getting this problem with Drama, My5 and ITV3 programmes - only since the last few days - apart from the Freeview Retune, are there any Hummy packages which have recently been updated ?

Additionally, after reading the above again, I manually decrypted the My5 recording of Extreme Railways and it plays fine, but the undecrypted copy will not play - 'Scrambled or not available' - the same is not true of ITV3 and Drama recordings which did not auto-decrypt - the undecrypted copy played fine.
 
Last edited:
Yes, I came to the same conclusion with manual decryption working OK. I'm currently recording Sharpe on Drama with AR instead of the usual padding of 2 minutes either end to see if this works but don't see why it should make a difference. For now I'll manually decrypt Drama programs.
 
Just noticed that some of the entries for the decryption of the Drama programs in the "Queue" have "plugin failure" against them. Not sure what it means but may point to a problem.
 
These symptoms suggest some kind of change in the flags for these programmes. We had something like this (bad NTS files) before. Maybe autodecryption is trying to kick in before the NTS stripper has been at work? (I know there are bugs in this argument, but I'm just throwing some ideas into the arena.)
 
I can confirm that this problem seems to exist for all the suto-decrypted programs that I have recorded from Drama today.
The problem does not occur for programs processed by detectads in chase-run mode or decrypted with the browse opt+ option

I think it will need af123 to investigate why it appears to only affects auto-decrypt on Drama
 
It seems to be related to the hmt file: if you remove the original and then use sidecar to create a dummy hmt file automatic decryption works. I compared an original hmt file and one created using sidecar (after decryption) with a hex editor (binary difference) and could find no obvious reason for this problem.
 
MymsMan said:
I think it will need af123 to investigate why it appears to only affects auto-decrypt on Drama
Click to expand...

Please note it affected programmes from MY5 and ITV3 also for me (see above) and as Peterworks points out, these are all on COM4 MUX - Can this be relevant ?
 
Last edited by a moderator:
Anything is relevant when trying to establish a causal pattern. Drama has been tested, now the tests can be widened to include all COM4 services searching for counter-examples.
 
I have same problem. I found running fixencflags diagnostic found a few errant flags, which is unusual these days, but not sure it resolved the auto-decrypt problem with these recordings.
 
Another 'funny' which may or may not be relevant.
I ran 'decrypt in-place' on the 3 recordings that failed to decrypt using auto. I then ran the 'fixencflags' diagnostic and all 3 'lost' their DEC flag.
I ran 'decrypt in-place' again. They all appeared to decrypt and the DEC flag was reinstated.
 
I just copied some of my recodings to a usb then onto another box using the remote. They are unplayable. Giving the scrambled message. It seems to be the ones manually decrypted.
All were ITV3 or Drama.



Sent from my SM-G930F using Tapatalk
 
peterworks said:
Another 'funny' which may or may not be relevant.
I ran 'decrypt in-place' on the 3 recordings that failed to decrypt using auto. I then ran the 'fixencflags' diagnostic and all 3 'lost' their DEC flag.
I ran 'decrypt in-place' again. They all appeared to decrypt and the DEC flag was reinstated.
Click to expand...
I think it is likely to be relevant, a Drama recording that had been decrypted as part of detectads lost its DEC flag and then failed to to autodecrypt
 
After further testing, I can confirm that "problem" recordings recorded on HDR2 play from the USB stick in HDR1, and from the HDD in HDR1 when freshly copied in. The same recordings copied to HDD yesterday have become unplayable.

Presumably HDR1 is confused by a flag and is trying to decrypt them again with the wrong key and scrambling them up.

Sent from my SM-G930F using Tapatalk
 
After my playing around as per post #16 all 3 recordings are unplayable, ie, 'scrambled or channel unavailable'.
 
You must log in or register to reply here.
Back
Top