Is this firmware abandoned now? remote streaming

[MymsMan]

Thanks for looking into this. Can it not be done client side in the browser? the ip address is right there in the address bar.

Is it? I use the name humax rather than the ip address and for most other users it will be the internal ip address

The external URL should not change so it should be possible to look it up once and then stash it for future reuse (until rebooted) so the speed of the service used to find it is much less significant

 

[imanon]

Is it?

Yes, you are misunderstanding the problem. How would I connect to your humax from here? I need your external ip address to connect to your modem/router. Then using a port number that you have setup using port forwarding to point to your humax ip address on your local network. This can be coded into the webif by reading the ip address in the address bar and adding web/media/whatever the number of the recording is.TS onto the end.

The code to read the ip address from the browser address bar is here:

How To Get Current URL in Browser With JavaScript - TecAdmin

How to Get Current URL in Web Browser using JavaScript. This tutorial will help you to get current url js with JavaScript

tecadmin.net

If I could add this function as an extra "stream to external" button, not to replace the current "play" button, I would. I'm hoping someone who can, will.

 

[bottletop]

Hi, I dug out my old HDR Fox T2 out to be able to remote stream from another location. I can get it to stream by replacing the DLNA URL local address portion to the remote address, as in "local address:9000/web/media/26.TS" to "remote address:9000/web/media/26.TS" to play in VLC on my Linux pc without issue, but this is a pain to do.
Can the open in the browser VLC plugin code be removed now it doesn't work and be replaced by something that when a recorded program is clicked on, it passes the true remote location to whatever app I want my browser to use. It would be great if there was a one click solution that works on a tablet too, as this is what I want to eventually use.

Or have I missed some easy way in several days of searching here?

Thx

Maybe this isn't the option you're looking for, but why not use an old abandoned solution like a Slingbox? They use to be the in demand solution, but aren't fashionable now. So they're fairly cheap at an online auction site. It may suit others looking for this functionality. I'm not sure of the downside except having to add another consumer box to your collection. I've never wanted to stream my media across the internet myself and never had good upload speed anyway. Ironically now that fibre broadband is more common (offering better speed) the hardware is no longer on sale! Go figure ..

 

[/df]

...
If I could add this function as an extra "stream to external" button, not to replace the current "play" button, I would. I'm hoping someone who can, will.

The DLNA server is distinguished from the WebIf server by the use of different port numbers (9000 vs 80/443). While we can easily substitute the hostname from the WebIf page into a media link, there needs to be a way of preserving or remapping the port number that the WebIf wants to use across the NAT boundary. Given that ...

Whatever might be changed in the WebIf won't change the problem behaviour that your browser will most likely try to download the "stream" rather than playing it. Tests with files streamed by the WebIf server showed that my browser (Mozilla rv52.0) would play MP4 containing H.264 and AV1 video, MKV/WEBM containing H.264 and VP9 video. However it had no clue about other MPEG containers, in particular MPEG-TS/.ts, and I believe this will also be true of Chromeish browsers.

What can be done (ie, I have done it as a proof of concept, but without any NAT traversal) is this:

• trivially, add .webm to the list of extensions that are shown in the Browse Files display;
• trivially, enable the Play button in the Media Details pop-up for all listed file types;
• make the Play button try to handle all the listed file types, using a WebIf URL for a non-TS file, as happens with unencrypted, unindexed TS files;
• make the Play button open the link for the file in the browser, instead of trying to use the obsolete VLC plugin;
• in the above step, use a JS fragment to substitute the hostname of the page's URL into the linked file's URL:
  

       let hh = new URL(link,window.location.href);
       hh.hostname = window.location.hostname; 
       window.location.href = hh.href;

So far I just hacked this into the existing Play page, but a final version ought to be able to load the video with no interstitial page.

Would this be useful?

If so, should the video be opened in a new window/tab?

How can we get the browser to forward the URL to a helper application for the cases where it would otherwise try to download to a file?

Comments invited from all.

 

[imanon]

Thanks for your work on this. Personally, leave the port 9000 intact, I have no problem in port forwarding 9000 to the Humax ip.

Abandon playing in the browser?

How can we get the browser to forward the URL to a helper application for the cases where it would otherwise try to download to a file?

Put the link in a m3u playlist file? this should trigger the browser to pass it to your video player. I've been copying the whole DNLA index column in flex view, pasting it into a text editor, using find and replace to swap the lan ip with the wan ip and removing the video/ts off the end, then saving it as a m3u playlist. Drop that into VLC and we're good to go, although without knowing what the program is until it plays.

 

[sine24]

Maybe this isn't the option you're looking for, but why not use an old abandoned solution like a Slingbox?

Some people seem to choose the uber complicated way. Whether it's volition or not.

 

[/df]

A further issue with the HDR-Fox T2 is that its DLNA server believes that there is a MIME type video/ts and the WebIf code has acquired this belief. The only registered MIME type for MPEG-TS is video/mp2t (RFC 3555). This corrects the WebIf, but any solution that redirects to the DLNA server will result in the client receiving Content-type: video/ts.

 

[/df]

With my browser (pre-WebExtensions Mozilla), I was able to load a venerable extension "MozAmPeek Streamer" which allowed me to redirect certain URL types to an external app, and so play a .ts link (actually .TS) from my HDR, using its DLNA server, in a PC application:

Adds options to Firefox Download dialog to stream media files instead of downloading then opening. This allows the user to specify an unlimited number of players and assign as many file types to the players as they like.

I wonder what happens in FF85/78, Chrome-alikes, Safari?

 

[MymsMan]

A further issue with the HDR-Fox T2 is that its DLNA server believes that there is a MIME type video/ts and the WebIf code has acquired this belief. The only registered MIME type for MPEG-TS is video/mp2t (RFC 3555). This corrects the WebIf, but any solution that redirects to the DLNA server will result in the client receiving Content-type: video/ts.

Firefox has an "Open in VLC" extension available but this has never worked with the webif - hopefully this change will allow that extension to start working now.

 

[/df]

I've confirmed that Firefox 85 (and presumably 57+) is a toy browser that does not support adding URL handlers by configuration or by installing an extension. Essentially all you can do is something like OP's suggestion of serving a playlist file and having the browser's Download Manager open that with the desired local media player. Extensions like Open in VLC make this a 2-step procedure by shipping a native binary that passes (presumably) a file containing the URL to the player.

No doubt this also applies to the other market-leading browsers, since FF's APIs have been dumbed down to match those.

 

[imanon]

Thanks /df for your work on this

 

[/df]

This prototype works for me. See the PR for the to-do list.

 

[imanon]

Get's a thumbs up from me

 

[Ian Manning]

Maybe this isn't the option you're looking for, but why not use an old abandoned solution like a Slingbox? They use to be the in demand solution, but aren't fashionable now. So they're fairly cheap at an online auction site. It may suit others looking for this functionality. I'm not sure of the downside except having to add another consumer box to your collection. I've never wanted to stream my media across the internet myself and never had good upload speed anyway. Ironically now that fibre broadband is more common (offering better speed) the hardware is no longer on sale! Go figure ..

I agree that the Slingbox is/was a great solution, but Sling Media announced last year that they would be terminating the service in the next couple of years, hence rendering all existing Slingboxes completely useless and worthless. Very annoying :0(

 

[geordie]

I am going to admit to struggling with this thread but as far as I can tell, there is a patch for the webif to fix the application/x-vlc-plugin.

Does the patch form part of a webif upgrade so I can fix the problem that way? How else do it add the patch?

 

[Black Hole]

I am going to admit to struggling with this thread but as far as I can tell, there is a patch for the webif to fix the application/x-vlc-plugin.

Does the patch form part of a webif upgrade so I can fix the problem that way? How else do it add the patch?

The GIT is a repository for proposed changes to be reviewed and incorporated into an (eventual) package update, which might well be released as a beta first. If it was a simple single-file patch it might be do-able as a non-techie, but the commits in the GIT look a bit complicated to me. There might also be other mods to the same files pending to address other issues/requests, so the proposed mods might not be exactly what makes it to release.

Unless @/df is willing to issue a combined diff file we can apply fairly easily (and reverse if necessary), I recommend waiting for a formal release.

 

[/df]

...
Unless @/df is willing to issue a combined diff file we can apply fairly easily (and reverse if necessary), I recommend waiting for a formal release.

A beta tester of webif-1.4.9-3 who is confident of being able to force reinstall that version (I would want to have a local copy of the .opk) could test the patch attached to the PR, having regard to the caveats in my posting there.

Generally you can just add .diff to a Gitea (as here) or GitHub pull request URL to get a patch file (you can also get a .patch file for use with the git am command), or Gitea has a pull-down in the Files Changed pseudo-tab. In this case parallel developments affecting the same files have confused the version management system, so that the default patch file doesn't apply to the released beta files, which are the latest master/trunk/main versions.

 

[Black Hole]

In this case parallel developments affecting the same files have confused the version management system,

I think that's exactly what I was warning about.

so that the default patch file doesn't apply to the released beta files, which are the latest master/trunk/main versions.

Sorry, you've lost me. What do you mean by "default patch file"? If the patch file doesn't apply to webif-1.4.9.3, I don't see how we could install it.

The text file which results from appending .patch to the URL looks rather messy.

 

[/df]

"default patch file", that does not apply for the reasons described: the one created by adding .patch or using the pull-down menu.

"patch attached to the PR", for which follow the link in the post: a tweaked version that might under some circumstances with a following wind apply to the latest beta files.

The messiness is the sort of thing that the arcane C-as-assembler code (originally written by the guy guilty of perl) of the patch program is supposed to understand. For this reason and however fine a programmer Rob Landley might be, I'm not so confident about applying complex patches with the Busybox patch applet. I wouldn't encourage anyone to apply the changes manually.

Once the 1.4.9-3 version is fully bedded in (which it may already be, as we have found and fixed a couple of small defects, and no further issues have been reported), I expect that a new beta will be released with the playmedia patch.

 

[Black Hole]

That's still going over my head at first reading, don't know if it will become clearer in time.

@geordie: the answer appears to be "wait for an official beta release".