Is this firmware abandoned now? remote streaming

[/df]

I've done a combination of housekeeping and bug-fixing on the patch, and it's much readier to be tested.

Unfortunately it's still not a 1-shot process, but I've tried the cycle of installing the latest WebIf beta, patching, and reinstalling the beta several times with no issues. Instructions at the end of this PR comment.

 

[4ndy]

Just to add a small observation. I used the webif browser “download”option to download an mp4 file from iPlayer to watch on my iPad. Instead of downloading as expected, (and as it works with ts files), it started streaming directly.I was using the Chrome app.

I got the same result on my android phone. PC Chrome downloads, as it says on the tin.

 

[prpr]

Yes, I see the same. "Download" on a .ts file works as expected, but not on a .mp4 - using FF it just plays.

 

[Black Hole]

Is that a default action for the browser, rather than something at the server end?

 

[prpr]

<shrug> I dunno, I'm just a simple user. </shrug>

 

[Black Hole]

If you dissociate .mp4 from the browser, it should try to save it rather than play it.

 

[4ndy]

Whatever the explanation, i was wondering if something as simple as spoof extension change could get round the plugin issue.

 

[prpr]

If you dissociate .mp4 from the browser, it should try to save it rather than play it.

But we want it to play when clicking "Play" and download when clicking "Download".

 

[Black Hole]

But we want it to play when clicking "Play" and download when clicking "Download".

Remind me: does "download" access the file directly while "play" accesses via the DLNA server?

I've lost track of this thread. We're now talking about the enduring problem of the multiplicity of web browsers being coaxed into both playing and downloading a file on command, when it started out with a niche request to make a WebIF running in a browser not on the local network report the actual global URL of the resources (which won't be appropriate if the browser is on the local network).

Tidying up an old loose end:

If you have decrypted your recordings, you can play them from a file share set up on the HDR (ie, not using DLNA), which has been discussed extensively in the forum though I don't believe there is an up-to-date single page of instructions here or in the Wiki. Study the nfs-utils, samba and network-shares-automount packages.

Does this not serve the purpose?: Content Sharing 101 (click)

 

[/df]

But we want it to play when clicking "Play" and download when clicking "Download".

The Download option is implemented by sending a Refresh. If the linked item is an encrypted .ts, the redirection goes to the DLNA server, if present. WebIf has no control over how the refreshed content is served (MIME type, etc). It would have to be reimplemented by proxying the downloaded resource to do so.

There may be extensions available for mobile versions of Chrome (bearing in mind that these are actually Safari in iThings) that would enable the user to control the download behaviour.

We could put a Download button next to the new Play button in the Media Details pseudo-dialog using a link with the download attribute, if that has an effect (no, not the one we want), like this:

<a download="...desired filename..." id="playdownload" href="...local or DLNA URL..." >Download</a>

Some JS and CSS tweaks can make that look like the other buttons, and then we just need to set the link to point to the DLNA URL for .ts files, which is already being computed there.

 

[/df]

Remind me: does "download" access the file directly while "play" accesses via the DLNA server?

The new Play button uses the DLNA server if the file is both encrypted and indexed and so does Opt+>Download (as above).

...Does this not serve the purpose?: Content Sharing 101 (click)

It certainly does now, and probably did then!

 

[Black Hole]

WebIf has no control over how the refreshed content is served (MIME type, etc). It would have to be reimplemented by proxying the downloaded resource to do so.

So in summary, apart from some pretty exotic limbo dancing (which will probably be heavily browser-dependent), there is no way for a browser to tell the difference between a file for rendering and a file for downloading, and you just have to tell it to associate with files of one type and not another. Thought so.

 

[/df]

Not quite. The "no control" is (or rather, is not) over how the DLNA server serves the file.

As I point out later on, there is a specific way for the page to tell the browser that a link is meant to be downloaded as a file rather than opened, ie the "download" attribute of the link/anchor HTML element, which should be understood by recent-ish browsers. But bad news, this isn't meant to work unless the link's origin (scheme+host+port) matches that of the page (though older Chrome-alikes might not know that), so it doesn't help with links to the DLNA server, and, as the documentation explains, some browsers might believe the HTTP headers instead, or just not know about it (IE).

Thus the only real solution is for the WebIf to proxy the DLNA server so that the file is served with headers controlled by WebIf. I suppose
there must be a way to do that within the Jim/CGI/lighttpd framework, if it were sufficiently important.

As was researched earlier in the thread, current browsers have forgotten how to pass streams to helper applications, so essentially rendering and downloading are the same, except that in the former case the downloaded file may be transient and its location hidden from the user. This is why the new Play button has to fake up a playlist for "downloading".

 

[Black Hole]

No wonder I can't get my head around it. Just gimme hardware...

 

[prpr]

No wonder I can't get my head around it. Just gimme hardware...

It's a good job we all have slightly different skills.