Decrypting HD recordings not working

[ejstubbs]

My HDR-FOX T2 is not decrypting HD recordings using the WebIF OPT+ menu function. The recordings are unprotected (auto-unprotect is enabled and the recordings do not have the ENC flag showing) and have the DLNA indexed flag showing. When I select the decrypt function the decrpyption gets going and runs for a while, then suddenly jumps to 100% but without showing the result box. Going back to the media list the recording doesn't have the DEC flag showing, and there's no original in the _originals folder. However, FTP does reveal a xxxxxxx.ts.decrypting file skulking about in the My Video folder.

I have a feeling that this has been discussed before, but I've had no luck tracking down any earlier threads on the subject.

UPDATE: I have now successfully decrypted an HD recording of a 30 minute programme. I now seem to remember that previous discussions did mention limits on the duration (or size?) of recordings that the DLNA server could handle. So does this mean that I would need to split the recordings up, decrypt them, and then stitch them back together again? If that's the case then copying the recordings to my USB HDD would probably be easier.

FURTHER UPDATE: I've just realised that my _originals folder does contain the original of an HD recording that I successfully decrypted a while back (the decrypted recording isn't on the box any more). That recording was 61 minutes long and 2.32 GiB in size. Today I have been unable to decrypt an HD recording which is 59 minutes long and 2.48GiB in size, which suggests that if anything is the issue, it's size of the file not the duration of the recording.

 

[MymsMan]

AFAIK there are no size limits on decryption - certainly 4 hr is fine

Check that the Content sharing option is on in Humax settings - that is the most common cause of failure and can be enforced using the boot-settings package

Post the contents of auto.log (diagnostic menu) for the period it was failing to show what it was really complaining about

 

[Black Hole]

When I select the decrypt function the decrpyption gets going and runs for a while, then suddenly jumps to 100% but without showing the result box.

I have also seen this, but on my loaned-out unit when auto-decrypt had not been set up properly and the user was manually decrypting same as you. No idea what causes it, there seems to be a bug somewhere.

You will do better by ticking the file selection box then queuing the decrypt (bottom of the page), or just auto-decrypting.

 

[ejstubbs]

Check that the Content sharing option is on in Humax settings - that is the most common cause of failure and can be enforced using the boot-settings package

Checked, and confirmed enabled.

Post the contents of auto.log (diagnostic menu) for the period it was failing to show what it was really complaining about

Doesn't seem to be anything relevant showing:

01/01/2020 04:20:02 - Scanning media for flags...
01/01/2020 04:20:02 - Scan completed (0.216 seconds)
01/01/2020 04:20:02 - Active flags:
01/01/2020 04:20:02 - No expire flags in filesystem, suppressing scan.
01/01/2020 04:20:02 - No dedup flags in filesystem, suppressing scan.
01/01/2020 04:20:02 - No decrypt flags in filesystem, suppressing scan.
01/01/2020 04:20:02 - No shrink flags in filesystem, suppressing scan.
01/01/2020 04:20:02 - No mp3 flags in filesystem, suppressing scan.
01/01/2020 04:20:02 - No mpg flags in filesystem, suppressing scan.
01/01/2020 04:20:02 - Auto processing completed in 0.8 seconds.
01/01/2020 04:30:02 - Scanning media for flags...
01/01/2020 04:30:02 - Scan completed (0.216 seconds)
01/01/2020 04:30:02 - Active flags:
01/01/2020 04:30:02 - No expire flags in filesystem, suppressing scan.
01/01/2020 04:30:02 - No dedup flags in filesystem, suppressing scan.
01/01/2020 04:30:02 - No decrypt flags in filesystem, suppressing scan.
01/01/2020 04:30:02 - No shrink flags in filesystem, suppressing scan.
01/01/2020 04:30:02 - No mp3 flags in filesystem, suppressing scan.
01/01/2020 04:30:02 - No mpg flags in filesystem, suppressing scan.
01/01/2020 04:30:02 - Auto processing completed in 0.366 seconds.
01/01/2020 04:40:02 - Scanning media for flags...
01/01/2020 04:40:02 - Scan completed (0.208 seconds)
01/01/2020 04:40:02 - Active flags:
01/01/2020 04:40:02 - No expire flags in filesystem, suppressing scan.
01/01/2020 04:40:02 - No dedup flags in filesystem, suppressing scan.
01/01/2020 04:40:02 - No decrypt flags in filesystem, suppressing scan.
01/01/2020 04:40:02 - No shrink flags in filesystem, suppressing scan.
01/01/2020 04:40:02 - No mp3 flags in filesystem, suppressing scan.
01/01/2020 04:40:02 - No mpg flags in filesystem, suppressing scan.
01/01/2020 04:40:02 - Auto processing completed in 0.375 seconds.
01/01/2020 12:50:05 - autotrigger[3763]: /media/My Video/The Simpsons/The Simpsons_20200101_1218
01/01/2020 12:50:05 - autotrigger[3763]: will run for /media/My Video/The Simpsons
01/01/2020 12:50:05 - autotrigger[3763]: got lock
01/01/2020 12:50:06 - autotrigger[3763]: done
01/01/2020 13:20:05 - autotrigger[31210]: /media/My Video/The Simpsons/The Simpsons_20200101_1250
01/01/2020 13:20:05 - autotrigger[31210]: will run for /media/My Video/The Simpsons
01/01/2020 13:20:05 - autotrigger[31210]: got lock
01/01/2020 13:20:06 - autotrigger[31210]: done
01/01/2020 13:55:06 - autotrigger[31171]: /media/My Video/The Simpsons/The Simpsons_20200101_1320
01/01/2020 13:55:06 - autotrigger[31171]: will run for /media/My Video/The Simpsons
01/01/2020 13:55:06 - autotrigger[31171]: got lock
01/01/2020 13:55:07 - autotrigger[31171]: done
01/01/2020 14:55:05 - autotrigger[21350]: /media/My Video/The Simpsons/The Simpsons_20200101_1418
01/01/2020 14:55:05 - autotrigger[21350]: will run for /media/My Video/The Simpsons
01/01/2020 14:55:06 - autotrigger[21350]: got lock
01/01/2020 14:55:06 - autotrigger[21350]: done
01/01/2020 16:30:03 - autotrigger[13594]: /media/My Video/The Magnificent Seven_20200101_1508
01/01/2020 16:30:03 - autotrigger[13594]: will run for /media/My Video
01/01/2020 16:30:03 - autotrigger[13594]: got lock
01/01/2020 16:30:04 - autotrigger[13594]: done

 

[ejstubbs]

You will do better by ticking the file selection box then queuing the decrypt (bottom of the page), or just auto-decrypting.

Am I right in thinking that queued decrypts only run overnight? Certainly in the past when I've tried this the recording(s) has just sat in the queue with nothing obviously happening.

I don't use auto-decrypt because I don't often want to take recorded content off the box - plus I don't want a build up of stuff in the _original folder to cause the HDD to get full (SWMBO is all too eager to go around deleting stuff as it is, even though the HDD is only half full!) On the odd occasion that I do want to take a recording off the box I'd prefer to get it decrypted in an online fashion rather than as a batch task.

 

[MymsMan]

Am I right in thinking that queued decrypts only run overnight? Certainly in the past when I've tried this the recording(s) has just sat in the queue with nothing obviously happening.

That will depend on what you have set up in auto processing settings, the default is to decrypt immediately after recording but it can be deferred to a later time

I don't want a build up of stuff in the _original folder to cause the HDD to get full

Only manual decryption causes a buildup in the _original folder, using auto-decryption or Queue for Decryption will put the originals in to the dustbin or delete immediately depending on the options set.

 

[Black Hole]

Am I right in thinking that queued decrypts only run overnight?

You can configure it (I think). Without any inhibits, the queue is processed immediately something put on it comes to the top. You can also inspect the queue and delete or suspend waiting jobs.

Auto-processing scans for new tasks every ten minutes, auto-decryption adds new recordings to the queue on completion.

The big bonus with passing manual jobs through the queue is you don't then need to keep the browser window open. qtube is great for stuffing iplayer downloads onto the queue, for example.

 

[ejstubbs]

OK, thanks both for your clarification of queue processing. I'll have to take a look and see why my box seemed not to start processing a recording as soon as it was added to the queue.

An hour or so ago it did manage to manually decrypt one of the recordings which had been failing to decrypt previously. That was after I had power-cycled the box. However, the next one I tried failed as before. No obvious evidence in the auto.log but I did notice that the recording was flagged as IN USE when I went back to the media list and, if I hovered the house pointer over the page header, after a bit of a pause it reported that it was playing that recording - but nothing else, even though SWMBO was watching Bake Off live at the time. After a few minutes the IN USE flag had gone, and the box correctly reported Bake Off was being watched.

As a very wild guess I'd say that it looks to me as if the DLNA server is correctly "streaming" the recording - hence why the recording still shows as IN USE - but whatever is supposed to be "receiving" it is crashing.

 

[MymsMan]

I was wrong in suggesting looking at the auto.log - that is relevant for processing using queue processing.

How long are your decryptions taking when working and before failing?
It should only take a couple of minutes or so to process an hour of recording.
If they are taking a long time it is possible that the web page running the manual decrypt timed out before completion leaving the recording still in-use.

Without any evidence it is difficult to know what may be going wrong, so I don't know if these ideas will help.
Try resetting the DLNA database on the diagnostics page.
What do the Disk Diagnotics show?
Try entering Maintenance Mode and running Fix-disk to correct any disk problems (this can take overnight)

 

[ejstubbs]

How long are your decryptions taking when working and before failing?
It should only take a couple of minutes or so to process an hour of recording.
If they are taking a long time it is possible that the web page running the manual decrypt timed out before completion leaving the recording still in-use.

Just checked: a 1 hour 5 minute/3.93GiB recording failed 55% of the way through after 6 minutes pretty much on the nail.

The xxx.ts.decrypting file continued to grow after the manual decryption had jumped to 100%. After a few more minutes it was the same size as the original xxx.ts file, and the original recording was no longer showing as IN USE.

Ran the test again with the same recording: same result, except it had got to 57% before failing.

If this is a web page timeout issue, what if anything can be done to stop it timing out? Are we talking a browser setting, or something in the WebIF?

Try resetting the DLNA database on the diagnostics page.

Done - before I did the test above, so it doesn't seem to have made any difference.

What do the Disk Diagnotics show?
Try entering Maintenance Mode and running Fix-disk to correct any disk problems (this can take overnight)

The disk looked fine last time I checked it, which was only a few weeks ago. I know it could have developed a fault in the mean time, but the fact that at least one decrypt did succeed earlier today suggests that the disk is less likely to be a common factor (though I'll admit not impossible).

 

[MymsMan]

Does anything appear in web-error.log when decryption fails,

One advantage of queued decryption is auto retry on failures.

 

[ejstubbs]

Does anything appear in web-error.log when decryption fails,

That log is empty.

I have now updated the auto processing settings and successfully decrypted the test recording I was using above by submitting it to the queue (FWIW the successful decryption took 10 minutes 26 seconds). So it does look like the problem is caused by a timeout in the web page when decrypting manually - and I'd still like to find a fix/workaround for that if such exists.

 

[Black Hole]

I'd still like to find a fix/workaround for that if such exists.

I think the only (user) way is to force processing into a protected session such as abduco - which means opening a Telnet or Webshell session and running decryption on the command line... something like:

# abduco -A x (opens a protected session called "x")
# curl localhost:9000/web/media/<DLNA_REF>.TS -o <OUTPUT_FILE>

This is the basic decryption implemented by WebIF, and you have to find the reference number used for the recording in question from the DLNA database first, then integrate the resulting decrypted file into the media library afterwards (appropriate manipulation of sidecars etc). It would be a lot easier if there was a command line equivalent of WebIF decryption.

Until WebIF manual decryption is provided with a protected session, it's much easier to just queue it.

 

[ejstubbs]

Thanks for this explanation. I can't see myself going down that path if queueing decrypts proves to be a satisfactory workaround for my purposes in the long term. The protected session approach looks a bit complicated - although I could probably skip the re-integration in to the media library step as I decrypt recordings in order to move them off the box anyway.

 

[MartinLiddle]

There is a post about changing browser timeout values at https://stackoverflow.com/questions/39751124/increase-timeout-limit-in-google-chrome Using a tweaked Firefox for decryption might be the way to go IF the suggested change still works in the current Firefox.

 

[ejstubbs]

The tweak is still available in Firefox - at least, the preference is still there and can be changed. Upping the value to from the default 90 to 1200 (seconds, I assume, so 20 minutes) doesn't make any difference, though: decrypts fail after 6 minutes either way. That suggests to me that it's not the browser that's timing the session out but the server.

 

[Trev]

Why not just auto decrypt everything?

 

[Black Hole]

Why not just auto decrypt everything?

I don't use auto-decrypt because I don't often want to take recorded content off the box

The case for blanket auto-decrypt is less persuasive now we can decrypt off the box (in the case of failure).

 

[Trev]

The case for 'blanket decrypt' is as strong as ever. Set it once then forget all about it. Saves a lot of forum space.

 

[EEPhil]

The case for 'blanket decrypt' is as strong as ever. Set it once then forget all about it. Saves a lot of forum space.

In this forum, yes. You try auto-decrypting with 1800T/2000T or 4000T/5000T. Plenty of scope for expanding forum usage.