• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Is this firmware abandoned now? remote streaming

imanon

New Member
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
 
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.
...
If you click on the show of interest in the WebIf Browse Files page for the relevant directory, a Media Details dialog[ue] should open with Play and Close buttons at the bottom. Towards the bottom of the details presented, note the DLNA URL value. You can copy+paste or (if the applications and system GUI support it) drag this URL to your media player. However it sounds as if you're doing something like this already: do you have a more complex requirement that I don't understand from your description?

As discussed elsewhere it's difficult to present the video with a useful name because it's coming directly from the system's DLNA web server over which CF packages have no direct control. For the same reason, we can't control the disposition metadata sent by the DLNA server, so clicking on the URL itself causes the browser to download and save the recording on your client, which is probably not what you want even if you might then be able to play the downloaded file.

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.
 
Last edited:
If you click on the show of interest in the WebIf Browse Files page for the relevant directory, a Media Details dialog[ue] should open with Play and Close buttons at the bottom. Towards the bottom of the details presented, note the DLNA URL value. You can copy+paste or (if the applications and system GUI support it) drag this URL to your media player. However it sounds as if you're doing something like this already: do you have a more complex requirement that I don't understand from your description?

Thanks for replying. The quoted bit above is how I get the address to paste into VLC.

The problem is that the HDR Fox T2 is at another location, not on my home network. The URL presented to me to copy, is the internal ip address of the network the HDR Fox T2 is connected to (192.168.1.103:9000/web/media/26.TS). To play the file over the internet, I have to replace the 192.168.1.103 bit with the external internet ip address of the remote location (not posting that ip address up). I have setup port forwarding at the remote location to send any external request on port 9000 to the internal ip address (192.168.1.103) and the file will play without any problems.

It would be great if the code within the webif could look at the external ip address I used to connect to the HDR Fox T2, and present a link that is the true location of the file, not it's internal ip address. Everything else works great 👍
 
No the firmware is not abandoned!

The Pale Moon browser still supports the VLC plugin though these days I mainly use the Univeral Plug n Play within VLC to play Humax content.

There has been very little support for remote access since, until recently, most residential broadband connections did not have sufficient upload speed to allow for satisfactory streaming - mine still doesn't :(

It should not be hard to adapt the browse displays to show both internal and external ip addresses. A good learner project if you have any desire to try your hand at modifying the webif.

The Download option of the webif should work remotely and insulates you from any bandwidth issues.
 
Thanks for the replies, I have no trouble connecting to the HDR Fox T2 from the WAN. It's the serving me links with the internal LAN ip address it's connected to that's the problem. It will stream HD content fine when I alter the link to using the WAN ip address. I tried the Pale Moon browser but cannot find how to install VLC as a plugin, VLC itself has no options anymore to install itself as a browser plugin.

There has been very little support for remote access since, until recently,
This is why I ask if it's abandoned, as streaming content has been the thing for a while. I'm hoping it will get some minds thinking about updating the firmware to accommodate this as I have no idea how to modify the webif myself.
 
This is why I ask if it's abandoned, as streaming content has been the thing for a while. I'm hoping it will get some minds thinking about updating the firmware to accommodate this as I have no idea how to modify the webif myself.
I think it's a reasonable description of the WebIF "play" facility specifically - it would require somebody (you!) to come along and say they want to use it to revive interest. However, you should not say it's abandoned without that qualification - overall, the custom firmware (and software packages... those include the WebIF!) are most certainly no abandoned.

That said, @af123 (who would need to be heavily involved in any tweaks) has been somewhat indisposed recently.

The play facility used to work, but web browser standards moved on and now I suspect it would need to be implemented in HTML5 to support the mainstream browsers. If my hunch is correct, this might prove difficult. Perhaps there could be a way to trigger DLNA streaming from a WebIF link.
 
It will pop up in google searches, out of context. I don't understand why the question was even asked - it's not like the forum isn't active. The OP stuck that up as his first ever post. How about a more discreet title, like "How Do I Make the WebIF Play Button Work?"? Why hint at an accusation (the "when did you stop beating your wife?" type question)?

I'm sure you've heard of "abandonware" - this isn't it.
 
...I have setup port forwarding at the remote location to send any external request on port 9000 to the internal ip address (192.168.1.103) and the file will play without any problems.
Thanks, that was the missing bit.
...This is why I ask if it's abandoned, as streaming content has been the thing for a while. I'm hoping it will get some minds thinking about updating the firmware to accommodate this as I have no idea how to modify the webif myself.
However streaming between NAT subnets across the public Internet hasn't been much of a thing, because of the need to set up port forwarding (as you have) and (as MM pointed out) the generally inadequate upstream speeds offered by consumer ISPs.
 
...The play facility used to work, but web browser standards moved on and now I suspect it would need to be implemented in HTML5 to support the mainstream browsers. If my hunch is correct, this might prove difficult. Perhaps there could be a way to trigger DLNA streaming from a WebIF link.
The last bit is done already. The problem is that browsers don't have any way to take the streamed data and render it/them without additional code (what the VLC plugin used to do, I suppose). I recall that some browsers used to have a way of directing a stream to a player but this doesn't seem to work in recent Mozilla-derived releases. Nowadays, the stream gets saved to a single file which is then played by the configured application as a local file.

Replacing the VLC Plugin functionality would need a free JS player that understands the various media containers and codecs supported on the HD/R. Currently the Play function is offered for exactly those media files (Humax recordings) which typical HTML5 media support in browsers doesn't handle, while MP4/H.264+AAC has no Play function. To support (eg) MPEG-TS containers and MPEG2 Video, a nice JS player like Plyr would have to be augmented, possibly with things like this TS demuxer and/or this MPEG decoder. Or some future browser might be able to run VLC directly by compiling it to a subset of JavaScript.

In the Unix-like systems that I usually use for access to HD/HDR, there is an adequate solution that doesn't require a team of JavaScript devs, which is to drag a media URL to the mpv player and let it deal with all the media issues; possibly VLC would also work for this and in Windows too.
 
streaming between NAT subnets across the public Internet hasn't been much of a thing, because of the need to set up port forwarding
And thus he's also opened up a load of security issues (unwittingly probably).
 
Perhaps a VPN has been set up, as discussed in the remote access thread linked earlier?
 
And thus he's also opened up a load of security issues (unwittingly probably)
A load?? what possible load would that be? that someone in China is watching a Qi that I recorded?

No VPN setup, otherwise I wouldn't have to do the ip address swap.
 
what possible load would that be?
Opening ports in your router bypasses the firewall which keeps out attacks. Nasty people aren't looking for your recordings of QI, they're looking for ways to exploit the tech you have in your house and what they might reveal about you and your assets, or at the very least to set up DDoS attacks against other targets. Take a look in your router firewall logs to see how many external probes get blocked.
 
...It should not be hard to adapt the browse displays to show both internal and external ip addresses. A good learner project if you have any desire to try your hand at modifying the webif.
...
I don't think it's entirely straightforward. There are two parts: changing the WebIf code and layout to display the external address, and actually determining that address.

The first part means modifying some HTML and the Jim code that formats and populates it (for the Media Details pop-up) in /mod/webif/html/browse/file.jim so as to display an external DLNA URL; it would also be useful to add the DLNA URL field to the "general file" display, but that probably means more work to create a general media file class of which the existing ts Humax recording class would be a specialisation.

The second part requires creating a new system information function to return the external IP address, and modifying the media file classes to use it.

In general there's no direct way for WebIf software to know the external IP address, as this is between the LAN router/gateway and the ISP router.

These techniques are suggested but can be ruled out:
  • parse the output of traceroute to a known external host: too slow and unreliable;
  • parse an informational web page served by the gateway that shows the address: faster, but depends on each router model (including whether it offers such a page) and its authentication data;
  • use SNMP to read the address from the gateway: in theory a fast and standardised approach, but we have no SNMP client in the repository.
This leaves other techniques in which we ask some external service to send back the source address that we used to contact it.

Several web addresses will return the desired address as plain-text content; examples include icanhazip.com, ifconfig.me, ipecho.net and even some fly-by-night offerings like checkip.amazonaws.com.

This guy set up a test of various such services which I've adapted as a POSIX shell script to run in the CF environment with the busybox package installed (it will be) and also curl (below, the transcript shows 'a.b.c.d' for the actual IP address that was returned):
Code:
#!/bin/ sh

# tests the speed of various services for externalip:
# https://github.com/rsp/scripts/blob/master/externalip.md
# converted from the ajax-cdn-speed-test:
# https://github.com/rsp/ajax-cdn-speed-test
# by Rafał Pocztarski https://rsp.github.io/

# hosts taken on 2015-04-02 from:
# http://unix.stackexchange.com/questions/22615
# https://coderwall.com/p/lyrjsq/extract-your-external-ip-using-command-line-tools
# using only those that output IP only (with no need to parse output)

# local not yet in POSIX
type local >/dev/null || local() { true;}

# Busybox sleep only knows -N but there is usleep
! sleep 0.1s 2>/dev/null && type usleep >/dev/null &&
    sleep() { # secs[s]
        local zz zzs
        zz=${1%s}
        zzs=${zz%.*}
        [ -z "$zzs" ] && zzs=0
        [ "${zzs%[^0-9]}" != "$zzs" ] && return 1
        zz=${zz#$zzs}; zz=${zz#.}000000
        # microseconds 0<=zz<1000000
        zz=${zz%${zz#??????}}
        usleep $(( 1000000*zzs + zz ))
    } 
    
# default CF ping doesn't know -i
if ! ping -c 1 -i 0.2 127.0.0.1 2>/dev/null; then
    myping() { # host count interval
	local cnt ival cmd1 cmd2 cmd3 cmd4 cmd5
	[ -n "$1" ] || exit
	cmd1='BEGIN { xmt=0; rcv=0; rtn=999999; rtm=0; rtt=0; dst=0; }'
	cmd2='/^PING [[:alnum:].]+ / { if (dst == 0) { print $0; dst=1; host=$2;};}'
	cmd3='/^[[:digit:]]+ bytes from / { rtt += $10; if ($10 < rtn) rtn=$10; if ($10 > rtm) rtm=$10; ++rcv; print $0;}'
	cmd4='/^[[:digit:]]+ packets transmitted, / { xmt += $1; }'
	cmd5='END {printf "\n--- %s ping statistics ---\n", host; if (xmt > 0) printf "%d packets transmitted, %d packets received, %d%% packet loss\n", xmt, rcv, 100*(xmt-rcv)/xmt; if (rcv > 0) printf "round-trip min/avg/max = %1.2f/%1.2f/%1.2f ms\n", rtn, rtt/rcv, rtm; }'
	ival=${3:-1}
	cnt=${2:-1}
	while [ "$cnt" -gt 0 ]; do
		ping -c 1 "$1" 2>&1
		cnt=$((cnt - 1))
		[ $cnt -gt 0 ] && sleep "${ival}s"
	done | 
	    awk -F '[ =]' "${cmd1}; ${cmd2}; ${cmd3}; ${cmd4}; ${cmd5}"
    }
else
    myping() { ping -c "${2:-1}" -i "${3:-1}" "$1"; }
fi

curlout() {
	awk -F '[[:space:]~]' '{if ($NF ~ /[[:digit:].]+/) {time=$NF; --NF; printf "%s %1.3fms\n", $0, time;} else print; exit;}'
}

checkurls() {
	local httpl httpsl pingl url protocol err cout answer time
	httpl=
	httpsl=
	pingl=

	while read -r url; do
	    printf "\n%s\n" "$url"
	    host=${url#//}; host=${host%%/*}
	    # avoid weird hostname (ifcfg.me, eg) resolving to 0.0.0.0
	    nslookup "$host" | grep -q '0.0.0.0' && continue
	    for protocol in http https; do
		    cout="$(curl -f -m10 -L -sw "~over $protocol:\t%{time_total}" "${protocol}:${url}")"
		    err=$?
		    cout="$(echo "$cout" | tr -d '\n')"
		    answer="$(echo "$cout" | cut -d'~' -f1)"
		    if [ -z "$answer" ]; then
			if [ $err -ne 0 ]; then
			    answer="--no response--"
			else
			    answer="--no address--"
			fi
			time=999999
			echo "${answer}${cout}" | curlout
			continue
		    elif [ -n "${answer##*[0-9].*[0-9].*[0-9].*[0-9]}" ]; then
			cout="$(echo "$cout" | cut -d'~' -f2-)"
			answer="--not a.b.c.d address--"
			time=999999
			echo "${answer}${cout}" | curlout
			continue
		    else
			time=$(echo "$cout" | awk '{printf $NF; exit}')
			echo "${cout}" | curlout
			# stats=$(echo $cout | cut -d'~' -f1)
			case $protocol in
			http) httpl="${httpl}${time}s http:${url} - answer='${answer}'\n" ;;
			https) httpsl="${httpsl}${time}s https:${url} - answer='${answer}'\n" ;;
			esac
		    fi
	    done
	    avgping="$(myping "$host" "$pings" "$interval" | 
			awk -F = '/min\/avg\/max/ { if (1 < split($2, aa, /\//)) {print aa[2];}; exit; }')"
	    [ -z "$avgping" ] && avgping=999999
	    printf "average ping:\t%1.2fms\n" "$avgping"
	    pingl="${pingl}${avgping}ms ${url}\n"
	done
	
	printf "\nBest http response times:\n"
	printf "${httpl}\n" | sort -n
	
	printf "\nBest https response times:\n"
	printf "${httpsl}\n" | sort -n
	
	printf "\nBest average ping times:\n"
	printf "${pingl}\n" | sort -n | grep -vE '^999999'
}

pings=5
interval=0.2

# Obsolete:
#//curlmyip.com/
#//tnx.nl/ip
#//ifcfg.me/

cat << 'END' | (checkurls)
//ifconfig.me/
//icanhazip.com/
//ip.appspot.com/
//ident.me/
//ipecho.net/plain
//whatismyip.akamai.com/
//wgetip.com/
//ip.tyk.nu/
//corz.org/ip
//bot.whatismyipaddress.com/
//checkip.amazonaws.com/
//ipof.in/txt
//l2.io/ip
//eth0.me/
END
Code:
# ./externalip-benchmark
...
Best http response times:

0.065987s http://l2.io/ip - answer='a.b.c.d'
0.066000s http://ident.me/ - answer='a.b.c.d'
0.103650s http://eth0.me/ - answer='a.b.c.d'
0.127000s http://ip.tyk.nu/ - answer='a.b.c.d'
0.131227s http://whatismyip.akamai.com/ - answer='a.b.c.d'
0.160751s http://ifconfig.me/ - answer='a.b.c.d'
0.197161s http://checkip.amazonaws.com/ - answer='a.b.c.d'
0.199395s http://icanhazip.com/ - answer='a.b.c.d'
...

Best https response times:

0.916000s https://ifconfig.me/ - answer='a.b.c.d'
0.931052s https://l2.io/ip - answer='a.b.c.d'
0.952342s https://eth0.me/ - answer='a.b.c.d'
0.966221s https://ipof.in/txt - answer='a.b.c.d'
1.022527s https://icanhazip.com/ - answer='a.b.c.d'
...

Best average ping times:

9.67ms //ifconfig.me/
17.18ms //l2.io/ip
21.51ms //ipof.in/txt
28.57ms //ident.me/
35.11ms //whatismyip.akamai.com/
36.10ms //eth0.me/
....
#
For me http://l2.io wins easily but your mileage may vary.

Although HTTP is quite lightweight, compared to HTTPS, another approach which may be faster, and doesn't demand a client like curl or wget, uses a public DNS services that automatically returns the sender's IP address for some special query. The services that do this are OpenDNS, Akamai and Google, but to exercise them we need something better than Busybox nslookup: that thing is the Jim DNS package provided as an example in the Jim TCL distribution -- the file has to be copied into /mod/lib/jim:
Code:
# jimsh
Welcome to Jim version 0.79
. package require dns
1.0
. ::dns::address [::dns::resolve myip.opendns.com -server resolver1.opendns.com]
a.b.c.d
. # also available resolver2, resolver3, resolver4 ... .opendns.com 
. ::dns::address [::dns::resolve whoami.akamai.net -server ns1-1.akamaitech.net]
a.b.c.d
.  dict get [split [string range [::dns::result [::dns::resolve o-o.myaddr.l.google.com -server ns1.google.com -type TXT]] 1 end-1]] "rdata"
a.b.c.d
.
These all seem to take about 100ms per query, but maybe there's some Jim overhead in that: still faster than most of the HTTP services.

As there are more HTTP services with a single API than DNS services, and HTTP is clearly faster than HTTPS, one should use http://l2.io/ip or similar. If a bad result that might be injected by an attacker must be avoided, use HTTPS instead, but wait more than 10 times longer for the result. It might be useful to annotate the new Media Details external URL to show which service was used to determine the external IP address.
 
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.
 
Back
Top