• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Decrypt Failed - File In Use

Black Hole

May contain traces of nut
I've been getting warnings for several days as soon as I start the WebIF for HDR3 about a file which would not decrypt, each time the auto process tries to run it (every 10 minutes - the warnings are rather in-your-face, but that's OK as long as they don't turn up too often). When I looked into it, the recording looks OK, indexed etc, so I tried a manual decrypt on it and was told the file is in use.

I can think of no reason for this. The file shows the new flag in the SUI, so I couldn't have played it. I clicked OK and there was no resume option. I played it and stopped it properly, still no luck with the manual decrypt. Then I happened to try again - and the decrypt started OK (and completed). I should stop getting warnings now, but what the problem was is another mystery.
 
The in-use check looks to see whether anything else on the system has that file open for reading or writing. I wonder what the problem was!
 
The in-use check looks to see whether anything else on the system has that file open for reading or writing. I wonder what the problem was!
I'm getting them as well. Started on Tuesday when I was away - messages about "failed to decrypt" and similar. Was on 2.17 then and changing to 2.18 hasn't improved it.
The notify log is really annoying in that it seems to trample over other things on screen e.g. the drop down main selection menu thingy which makes it very difficult to use and sometimes it writes over its own Acknowledge button.
 
No failures today, but there's something weird with this:
19/07/2013 20:40 - DECRYPT: /media/My Video/...
19/07/2013 20:40 - DLNA: http: //127.0.0.1:9000/web/media/128.TS
19/07/2013 20:50 - DECRYPT: /media/My Video/...
19/07/2013 20:50 - DLNA: http: //127.0.0.1:9000/web/media/128.TS
19/07/2013 20:51 - Removing/binning old copy.

Why did this run twice and why didn't it remove/bin in the first place?

And this on a remote box:
19/07/2013 21:10 - DECRYPT: /media/My Video/...
19/07/2013 21:10 - DLNA: http: //127.0.0.1:9000/web/media/6905.TS
19/07/2013 21:17 - DECRYPT: /media/My Video/...
19/07/2013 21:17 - DLNA: http: //127.0.0.1:9000/web/media/6907.TS
19/07/2013 21:20 - Removing/binning old copy.
 
I've just got back from being away for a week, and discovered that my Auto-Decrypt has not been working

18/7/2013 04:35 - /media/My Video/The Net_20130717_1958.ts - auto decrypt failed
19/7/2013 04:35 - /media/My Video/The Net_20130717_1958.ts - auto decrypt failed
20/7/2013 04:35 - /media/My Video/The Net_20130717_1958.ts - auto decrypt failed
21/7/2013 04:35 - /media/My Video/The Net_20130717_1958.ts - auto decrypt failed
22/7/2013 04:35 - /media/My Video/The Net_20130717_1958.ts - auto decrypt failed

I was able to decrypt it manually - but other files have been reporting the same problem

Is this a problem or will it go away, like the summer heat ?

I'm on

Web interface version: 1.0.3
Custom firmware version: 2.15 (build 1504)
Humax Version: 1.02.29

I will check now to see if anything has auto-decrypted since 18th July - any comments would be appreciated
 
Your auto.log may contain additional useful information. Can you have a look?
 
Here's another one which took two goes to decrypt (6905.TS):
Code:
19/07/2013 21:10 -  DECRYPT: /media/My Video/Proms on Four_ Friday Night at the____20130719_1930
19/07/2013 21:10 -  DLNA: http://127.0.0.1:9000/web/media/6905.TS
19/07/2013 21:17 -  DECRYPT: /media/My Video/Gardeners' World/Gardeners' World_20130719_2030
19/07/2013 21:17 -  DLNA: http://127.0.0.1:9000/web/media/6907.TS
19/07/2013 21:20 -  Removing/binning old copy.
19/07/2013 21:20 - Done... 885.96 MiB in 143.507 seconds - 6.17 MiB/s
19/07/2013 22:10 -  DECRYPT: /media/My Video/The Mating Game - Natural World Special_20130719_2101
19/07/2013 22:10 -  DLNA: http://127.0.0.1:9000/web/media/6911.TS
19/07/2013 22:14 -  Removing/binning old copy.
19/07/2013 22:14 - Done... 1.67 GiB in 264.026 seconds - 6.49 MiB/s
19/07/2013 22:30 -  DECRYPT: /media/My Video/Proms on Four_ Friday Night at the____20130719_1930
19/07/2013 22:30 -  DLNA: http://127.0.0.1:9000/web/media/6905.TS
19/07/2013 22:37 -  Removing/binning old copy.
19/07/2013 22:37 - Done... 2.61 GiB in 432.319 seconds - 6.19 MiB/s
and another:
Code:
19/07/2013 20:40 -  DECRYPT: /media/My Video/EastEnders/EastEnders_20130719_2000
19/07/2013 20:40 -  DLNA: http://127.0.0.1:9000/web/media/128.TS
19/07/2013 20:50 -  DECRYPT: /media/My Video/EastEnders/EastEnders_20130719_2000
19/07/2013 20:50 -  DLNA: http://127.0.0.1:9000/web/media/128.TS
19/07/2013 20:51 -  Removing/binning old copy.
19/07/2013 20:51 - Done... 778.82 MiB in 114.763 seconds - 6.79 MiB/s
 
Those ones look like something went wrong with the download from the DLNA server - if anyone is still getting occurrences, could you turn up the debug level on the automatic processing on the settings page?
 
"file did not decrypt properly" in auto.log and "auto-decrypt failed" in notify.log

Manually decrypting from the Web-If's Opt+ menu apparently works fine (incidentally, status reports Playing not Decrypting when you do this!), but "stripts -E" reports 1 for both the original and the apparently decrypted file.

I tried increasing the (-d 1) debug level on stripts, but it just sulks and does nothing useful.
 
stripts says:
-d [level] Set debug level​
but specifying a debug level causes nothing to work. Leaving the level parameter out produces some debug output. It would be nice if it worked properly and told you what the usable range of level was supposed to be...

Anyway, attached is the output from a remote box - no idea if the decrypted file plays OK or not, or it's just a reporting error with stripts, or something else.
 

Attachments

That seems to be the root of the problem, that stripts still thinks it's encrypted (or at least, not decrypted) so for safety it aborts. I'll look to see if stripts has some useful debug level..
 
Could you post the full output of hmt against that recording please? I have a suspicion...
 
Huh? It's 1766 bytes. What else would it register as?

Of more interest is why does it say Views: 0 when it has been viewed a non-zero amount of times? Is that related to the forum s/w upgrade this morning I wonder?
 
The view counters are updated by a batch job that runs every hour on the half hour by default..
 
Oh yes, my mistake, bad night! I didn't twig that 40-odd lines of average 40 characters each would be 1600... Doh!
 
@prpr - could you try stripts 1.2.2 on that decrypted file and see if it's any better? Thanks.
 
Back
Top