Decrypting HD recordings not working

ejstubbs said:
... it's not the browser that's timing the session out but the server.
Click to expand...
Indeed it's not the browser (since the timeout is ~5 minutes vs my 90s browser timeout), nor wget (which has a default idle read timeout of 900s) that's timing out. The CF lighttpd webserver is timing out the operation because no data is being sent.

The manual decryption page calls the jQuery .load() without overriding jQuery's global timeout, but that's not the issue because the timeout is infinite by default in JQuery-1.12.4. A process is started to decrypt the "recording" using wget to fetch it from the internal DLNA server. While this is happening, the page updates the progress bar every second by measuring the size of the decrypted file. However the request that's running the decryption returns no data and lighttpd has a write timeout server.max-write-idle set to 360s, after which the request is cancelled and the progress is set to 100%, as if it had completed successfully. Meanwhile wget carries on and eventually completes, leaving a stray decrypted file (with the .decrypting suffix). Presumably this would also happen (but more easily) using stripts to decrypt.

If jQuery were timing out, as it might with the latest versions, it would be possible to add a load_with_timeout() method. To override the lighttpd timeout, you can globally change the setting in /mod/etc/lighttpd/server.conf (the server needs to be restarted). A sufficient timeout seems to be 40s per minute of content, so 19200 would handle a recording of 8 hrs. Alternatively, it might be possible to modify the invocation of wget in /mod/webif/html/browse/decrypt/execute.jim so that progress is sent to the standard output: currently the output of the wget call is delayed until the operation has completed.

Using a more rigorous test plan, I decoded NYE's Hootenanny (126 minutes, HD) first changing the server.max-write-idle value to a distinctive shorter value, and observed the decryption request being cancelled after that time, and then using the super-long timeout to run the WebIf manual decode successfully (with the completion page only shown after reaching 100%, and carrying out the final housekeeping), as below.
Code: 
--Decrypt in-place--
File:	/media/My Video/Jools' Annual Hootenanny_20191231_2317.ts
Length:	02:06:10
Decryption method:	Hardware accelerated (via DLNA)
Decrypting: 100 %

Processing Jools' Annual Hootenanny_20191231_2317
Moving recording to /media/My Video/_original
Copying back sidecar nts
Copying back sidecar hmt
Copying back sidecar thm
Time taken: 1830.345
 
Last edited:
Necroposting I know, but I just found a similar problem - but for all recordings - occurs when you switch off CONTENT SHARE in Settings -> System -> Internet Setting. I think I was trying to work out what was causing the HDR FOX T2 to crash and switched it off to see if it made a difference a few months ago and never did switch it back on, then wondered why anything newer than October this year wouldn't stream. Then checked the queue to see DLNA SERVER NOT RUNNING as the root cause.

Just posting this reminder in case it helps anyone Googling for the solution, as I just did.
 
zekepliskin said:
Necroposting I know, but I just found a similar problem - but for all recordings - occurs when you switch off CONTENT SHARE in Settings -> System -> Internet Setting. I think I was trying to work out what was causing the HDR FOX T2 to crash and switched it off to see if it made a difference a few months ago and never did switch it back on, then wondered why anything newer than October this year wouldn't stream. Then checked the queue to see DLNA SERVER NOT RUNNING as the root cause.

Just posting this reminder in case it helps anyone Googling for the solution, as I just did.
Click to expand...
I don't know why I bother documenting everything :rolleyes:

Black Hole said:
Ensure content sharing is turned on
Click to expand...
 
Yes BH, I read that part too, but the Google search I made takes you to the 2ᴺᴰ page not the first, and you'd be amazed how many people don't bother to read the first. 🙄
 
A good explanation by /df. Having just had this problem (decrypting a large file) and searching and finding this thread, is there any reason why the server.max-write-idle timeout shouldn't be greatly increased in the config file by the custom FW (e.g. by a one-off script that sets a flag in the same directory to say it's been done, or some more elegant means), so this problem vanishes? Auto-decrypting everything seems like a lot of disk mileage and CPU usage/box sluggishness for those (like me) that rarely need a decrypt. I appreciate I can work around it and use the DLNA server on port 9000 to pull a decrypted version off the box, but it would save others the need to search for this post if they never had the problem.
 
Yes prpr I will do, or pull via the DLNA server, now I actually know about the issue. My previous post was asking, "why not fix the issue?" as I was a bit puzzled and was wasting time failing to decrypt before finding this thread. My last two failures have been while the box was also recording (and possibly also watching) something, so the decrypt was slowed down and the timeout occurred. I did a command line "find" and found (and deleted) 5 stray "xxx.decrypting" files, taking up a little bit of space. Maybe the web page that is opened by opt+ -> decrypt could state the issue and recommendations. Or something! I must say the posts and excellent CFW by the well known members have been well appreciated over the years.
 
Last edited:
The simplest fix would be to remove the archaic 'while you wait' decryption option and just support queued decryption,
 
The simplest fix would be to remove the archaic 'while you wait' decryption option
Click to expand...

Other 'while you wait' operations are also affected: in particular anything that involves software transcoding.
 
My WebIF told me lighttpd got an upgrade today (I see the "server.max-write-idle" timeout has gone from 360 to 3600 as per prpr's comment earlier). So I ran an on-demand decrypt on a previously failing file and it worked (a 3 hour program, decrypt took 1436 seconds, the box was busy recording two programs at the time, both having chaseget detectads done on them). Appreciate it! I was going to edit the server.conf myself next time I wanted a decrypt but no need now...
 
MymsMan said:
Why not use the queued decrypt option - no need to leave the webif sitting on the same page for 25 minutes waiting for it to finish
Click to expand...
No compelling reason really, the opt+ decrypt option is there and I've always used it. I also have "Suspend automatic processing whilst recording?" enabled, so it gives me a "do it right now" option if something long is recording (like the football was the other day when I wanted to do it). Walking past the computer, seeing the progress bar gives an idea of how long to go, or if finished (reminds me to copy it off the box!), although I could queue it and leave the queue window open instead (refreshes every minute) I suppose.
 
You must log in or register to reply here.
Back
Top