WebIF Download


I have used the WebIF "decrypt" option followed the "Extract To mpg" to generate an mpg file. When I use the "download" option on the mpg file, it plays rather than downloads.

I can use an FTP client to copy the file over, but is there something I'm doing wrong in the WebIf to download the file? Nicer to only have to use one interface if possible.

The fact that it plays is because that is what your web browser is configured to do when it links to that file type. I'm not sure whether this will work, but try right-click and select "save target as".
ah, ok thanks. I'm using Chrome, and its the VLC plugin that's causing this behaviour. if I disable it, the file will download, but I can't play any files through the webif. oh well, not to worry, I'll use ftp to download.
That might not be the answer you desire. With a WebIF download option, the content will be decrypted in the process. If you want to FTP the file, it will need decrypting first to be of any use to you.
I've used the WebIF decrypt option, installed ffmpeg, and used the "Convert to MPG" option. I should be able to ftp the resulting mpg file to my PC and play it as normal I think?
However, having played around with this, I think the [network-shares-automount] package sounds like a much better way to go! I will get reading that thread.
Automount is for an external network share to become visible on your Humax (HD/HDR-FOX), not to make your Humax visible on your PC. What you need is the support side of automount without automount itself - in other words automatic decryption to make the content usable, and Samba to make it shared on the network.
Automount is for an external network share to become visible on your Humax (HD/HDR-FOX),

This is what I really want to do!

I went off down the decrypt, convert to mpg, copy mpg to PC route as this is what I used to do with my Topfield. The converted mpg file ended up on my Linkstation, streamed back to the telly via Twonky. This was how I used to reclaim space from the Topfield. Cumbersome, but it worked and I was still in that mindset!!

But, with Automount I can move recordings direct to the Linkstation (I think?), and they will be visible/playable via the Humax media button.
I'm new to this forum, so I hope I'm posting in the right place.

I have been using Webif happily for several months to download decrypted files from my HDR Fox T2 to my PC, using a Firefox browser. I had been using an older version of Webif, I think it was around v 0.7, but I have just upgraded it to Webif 1.02 and now the file download via the 'OPT+' button on the Webif Browse page is no longer working correctly in Firefox. (I'm using the latest Firefox v 21.0 on Windows.) Instead it appears that Firefox is now trying to render the binary .ts file as a page instead of saving it. The strange thing is that exactly the same download IS still working correctly using both Chrome and IE 8. It suggests to me that maybe something has been changed for the file download in the http header sent by the upgraded Webif that Firefox no longer handles correctly, while the other two browsers still do.

Can anyone shed any light on this?
Odd. I can't think of anything specific that has changed although that's a big version jump. I will have a look. I think I'm still on FF20 but can upgrade. Did it definitely work with FF21 and the older webif?

Posted on the move; please excuse any brevity.
I was actually on FF 20.0.1 when I did the Webif upgrade (along with a number of other related package upgrades), and found the download error. I upgraded my FF to 21.0 just to see if that made any difference, but the download error remained. With the older version of Webif it had worked fine for months through several generations of FF upgrades up to and including 20.0.1.
I have just successfully downloaded / decrypted an SD encrypted file that was DLNA indexed to a P.C. running Firefox Ver 21.0 Via Web-If Ver 1.0.2. Although the download worked I had to refresh the contents of the address bar twice e.g.:- Video/Pet Squad/Pet Squad_20121209_0726.ts&base=
and then click Allow to accept a Firefox re direction request. While the file was downloading there was no download window to show what was happening, so without looking at the growing file in the P.C's download areas the user would not be aware that there was a download happening
Curioser and curioser. I just tried downloading an encrypted HD file in FF (using the DLNA-indexed file), and that IS working correctly in FF 21 and webif 1.02. No refresh needed - I get the usual 'open/save' dialog box immediately. But when I try downloading an HD file that has already been DEcrypted (using the autodecrypt facility), that is when it no longer appears to work in FF. No 'open/save' dialog box, no warnings or error messages, and FF becomes a bit sluggish like with a slow connection. The page tab also continually shows "connecting...", and after a while FF renders a page of binary gibberish as text.

I also tried downloading a decrypted SD file. Same problem.

Is it possible that this might have something to do with the files having been decrypted earlier using an older version of webif_autodecrypt? (It has decrypted HD files correctly in the past, since they were OK when downloaded using the older webif, and also when transferred by FTP instead. So the decrypted .ts file itself must be OK, but maybe there's something different in a database entry?)
Some more info. I can successfully download Hi-Def. and SD files that were both encrypted and decrypted using FF21.0. I think the double refresh in the address bar I have to do is linked to having to accept the FireFox page redirect, so you probably won't see these problems. I do see something in FF21.0 that I haven't noticed before, when a download is kicked off, the usual download window is replaced with a very small icon in the FF top right hand corner, the '1s' in the picture


Can you play the decrypted files that don't download using the Web-If 'Play' option? that would prove the state of the files
Updating the mongoose package and restarting your Humax should fix the problem.
When I upgraded it on my box, the service didn't restart properly. A restart ensures that the new version's running before the end users confirms the fix.