HDMI to IPTV converter

emaherx

Johnboy1951 wrote: »

If you look at the tcpdump after the command I used above, it shows UDP and not RTP from the device.

This even though RTP is specified in the command.

Also that command apparently has no effect on the port numbers used, if my results here are anything to go by.

not RTP but RTSP it is a TCP Protocol you won't see any traffic from it unless you actually manage to create a connection. RTP on the other hand is a UDP protocol and will spew out all it has to say whether or not any clients are trying to connect.

The default port for RTSP is 554 and it becomes open when you select Unicast on this device. It makes sense as this is the same protocol used with nearly all IP based CCTV systems and they don't flood the network with traffic and are not limited to one client connection.

Johnboy1951

OK, I got the single IP stream to play.

EDIT:

No I didn't ....... mcast was enabled again whenever I tried

Johnboy1951

emaherx wrote: »

not RTP but RTSP it is a TCP Protocol you won't see any traffic from it unless you actually manage to create a connection. RTP on the other hand is a UDP protocol and will spew out all it has to say whether or not any clients are trying to connect.

The default port for RTSP is 554 and it becomes open when you select Unicast on this device. It makes sense as this is the same protocol used with nearly all IP based CCTV systems and they don't flood the network with traffic and are not limited to one client connection.

From what I could determine, when I tried to enable unicast and specified the target IP, I was able to receive the stream there using UDP.

BUT, it appears that Multicast was not properly disabled ...... the multicast notifications were still going to the whole network causing some probs.

I would need to go back and look more closely in the future, as I got rather confused during that last session

emaherx

Johnboy1951 wrote: »

From what I could determine, when I tried to enable unicast and specified the target IP, I was able to receive the stream there using UDP.

BUT, it appears that Multicast was not properly disabled ...... the multicast notifications were still going to the whole network causing some probs.

I would need to go back and look more closely in the future, as I got rather confused during that last session

The methods of "unicast" discussed in Danman's Blog is not true unicast.

Johnboy1951

emaherx wrote: »

The methods of "unicast" discussed in Danman's Blog is not true unicast.

I suppose a firmware change would be needed to achieve proper unicast

I have not seen any indication on how to achieve it so far.

Any ideas?

emaherx

Johnboy1951 wrote: »

I suppose a firmware change would be needed to achieve proper unicast

I have not seen any indication on how to achieve it so far.

Any ideas?

Set your device to unicast by unchecking multicast in the web GUI (don't run any other commands). Now rerun your nmap you will now see port 554 is open.

This is the proper rtsp port for unicast streams so it is likely that the firmware is fine. But you would need to know the correct URL to connect to it.

How you find it, I don't know. I've tried using CCTV software to auto detect or brute force find the URL but no luck yet.

Edit: I wonder if we had the rx device could we intercept the packets and see what the URL is?

Johnboy1951

emaherx wrote: »

Set your device to unicast by unchecking multicast in the web GUI (don't run any other commands). Now rerun your nmap you will now see port 554 is open.

This is the proper rtsp port for unicast streams so it is likely that the firmware is fine. But you would need to know the correct URL to connect to it.

How you find it, I don't know. I've tried using CCTV software to auto detect or brute force find the URL but no luck yet.

Edit: I wonder if we had the rx device could we intercept the packets and see what the URL is?

I ran tcpdump after disabling multicast and noticed the following ...

20:45:36.412379 IP 192.168.1.102 > 239.255.42.196: igmp v2 report 239.255.42.196
20:45:36.412388 IP 192.168.1.102 > all-systems.mcast.net: igmp v2 report all-systems.mcast.net

192.168.1.102 is the device and I ran tcpdump on 192.168.1.101

emaherx

I got a unicast stream to play by using one of my Kodi R-Pi's as Proxy and a second Ethernet adapter connected by USB. So a unicast stream and no multicast traffic on network. If this works out it might just do.

I'm going to the pub now, but will give more detailed report of whats what before the weekend is out.

Johnboy1951

emaherx wrote: »

I got a unicast stream to play by using one of my Kodi R-Pi's as Proxy and a second Ethernet adapter connected by USB. So a unicast stream and no multicast traffic on network. If this works out it might just do.

I'm going to the pub now, but will give more detailed report of whats what before the weekend is out.

Thanks.
I look forward to the details

emaherx

Johnboy1951 wrote: »

Thanks.
I look forward to the details

OK so its working but not without issue, there is occasional buffering at the client Devices. Not sure if its a Network limitation with my bodged together home network or if the Pi is just not up to the Job.

For my test I'm streaming the output of the same Raspberry Pi so it may be under a little pressure. Basically I'm streaming a HD channel from my TV server to the R-Pi the output of its HDMI is sent to the IPTV converter and back to eth1 of the R-Pi by multicast converted to unicast and back out through eth0.

Perhaps a NUC would be a better choice for this Job.

Anyway R-Pi is running Libreelec, took me ages to figure out how to install Udpxy as I couldn't compile it on the device due to the cut down nature of the OS. But it is actually on the Libreelec Repo as part of network-tools addon listed under programs. :rolleyes:

Statically set IP on IPTV converter to 192.168.10.20 (or whatever address not in your main subnet)

Connect USB Network Adapter to R-Pi
Install the network-tools addon from libreelec repo

ssh into the device
ifconfig eth1 192.168.10.10 netmask 255.255.255.0
route add -net 224.0.0.0 netmask 240.0.00 dev eth1
iptables -t raw -A PREROUTING -p udp -m length --length 28 -j DROP (thanks Johnboy1951)
cd /storage/.kodi/addons/virtual.network-tools/bin
cp udpxy /usr/bin/
udpxy -p 81

On client device.
http://192.168.x.x:81/udp/239.255.42.42:5004 (need to edit x.x for your udpxy server)
http://192.168.x.x:81/status (will show status of udpxy server)

I added 2 lines to my channellist.m3u file and the IPTV stream shows as a channel named HDMI on all of my Kodi device (they all link to the same file)
#EXTINF:-1, HDMI
http://192.168.x.x:81/udp/239.255.42.42:5004

emaherx

Johnny1951 did you try tvheadend? I tried it yesterday but couldn't figure out how to setup the stream.

Johnboy1951

Thanks for the details .... appreciate it.

It is good that you got it working, although for me needing to use an extra device rather defeats the purpose as it is added cost.

At one time I took the multicast stream into Kodi using IPTV Simple and dispensed with the iptables command and still had a stable stream.
I used it for some hours without problems but could not record the stream.
Probably the later versions of tvheadend can take this stream in directly which would allow recording?

OK, the multicast operation caused problems for the rest of the LAN, even though I tried to isolate the device on its own IGMP snooping capable switch. I never did find out why this did not work. Probably because I am not familiar enough with the requirements for managing it.

When trying various commands trying to change to unicast, I did succeed (I believe) in specifying the unicast address, only to have the device operate as multicast.

There just might be a method of specifying this address, then switching off multicast, to see if the stream remains on the specified address as unicast.

Of course I might well be mistaken about specifying that address so lots of trial and error will be needed to try to duplicate it.
Maybe next week I will get the chance to 'interfere' with the set up without upsetting others in the household!

Thanks again for the details

Johnboy1951

I wonder if you could test something to see if it is somehow dependent on my LAN topography or if it will work for you.

I used a command which needs to be tweaked etc etc, but is sufficient to test here.

# curl "http://192.168.1.102/dev/info.cgi?action=streaminfo&udp=n&rtp=y&multicast=n&unicast=y&mcastaddr=192.168.1.101&port=5004"

I am able to receive the stream on
udp://@192.168.1.101:5004
using VLC.

By changing the destination IP I can observe the stream changing on the LAN switches.
Although Multicast is ticked in the WebGUI the stream is apparently not multicast.

I would be interested in any results you get while running some tests with the above.

EDIT:

I can change the stream to any device on the LAN with this reduced command

curl "http://192.168.1.102/dev/info.cgi?action=streaminfo&multicast=n&mcastaddr=192.168.1.113"

.

emaherx

Johnboy1951 wrote: »

Thanks for the details .... appreciate it.

It is good that you got it working, although for me needing to use an extra device rather defeats the purpose as it is added cost.

Not ideal no, but if I can get it 100% stable on a R-Pi then there is no extra device for me except a 10 Euro USB Ethernet adapter. As I want to stream a Blu-ray player which will be connected to the same TV as a R-Pi running Libreelec.

emaherx

Johnboy1951 wrote: »

By changing the destination IP I can observe the stream changing on the LAN switches.
Although Multicast is ticked in the WebGUI the stream is apparently not multicast.

The Multicast button it would seem is to change from UDP Multicast to RTSP/TCP Unicast so if you untick it you stop all UDP traffic which will make it useless to us unless we were to know the exact RTSP URL. What you are doing is a bit of a hack for this device as you are essentially just sending the multicast Stream to a single Unicast IP address.

Johnboy1951

emaherx wrote: »

The Multicast button it would seem is to change from UDP Multicast to RTSP/TCP Unicast so if you untick it you stop all UDP traffic which will make it useless to us unless we were to know the exact RTSP URL.

That would seem to be the case.

What you are doing is a bit of a hack for this device as you are essentially just sending the multicast Stream to a single Unicast IP address.

Yes it is ..... but is all I've got for now
.... and it is working for that one destination without crashing the LAN.

I was hoping you might get some insight or be able to determine the URL from your use of the R-Pi.

emaherx

Johnboy1951 wrote: »

That would seem to be the case.

Yes it is ..... but is all I've got for now
.... and it is working for that one destination without crashing the LAN.

Oh, i know without the UDP output we would have nothing at all and that wasn't meant as a criticism.

Johnboy1951 wrote: »

I was hoping you might get some insight or be able to determine the URL from your use of the R-Pi.

I don't think so, due to the nature of the TCP stream there is nothing to see without a session being created first and without knowing the URL I can't create the session.

UDP is different because it spews out data and doesn't care if there is a client listening or not.

I tried to use some programs to brute force the URL but I think they just use a dictionary of known words used in common RTSP devices which are mostly CCTV they usual have a URL like rtsp://192.168.1.10:554/DVR/CAM1 I was hoping ours would be something like rtsp://192.168.1.10:554/IPTV or rtsp://192.168.1.10:554/IPTV/STREAM but really it could be anything and there could be a username and password as part of the URL also.

I think the most likely way to find the URL is to have the RX device also set to Unicast through its GUI (would probably need a certain firmware level also) and intercept the packets between the two devices, unless the lads pulling the firmware apart find the URL.

Johnboy1951

In my client list of switch the device is called

android-17790f2c2402 3c9a

The device name from the terminal access on Port 9999 using NC is

get_device_name
TX_00ABE3B2DEBC

I wonder if that is just a 'best guess' by the switch or if there really is something "Android" about the device that might be exploited?

emaherx

Something Android? like the OS? I'm going to say no given that Danaman's Blog have looked at the installed chips and even read the files on the onboard flash, if there was anything of that complexity he would have been all over it.

Your Device name is built from TX for transmitter followed by Mac address

Johnboy1951

emaherx wrote: »

Something Android? like the OS? I'm going to say no given that Danaman's Blog have looked at the installed chips and even read the files on the onboard flash, if there was anything of that complexity he would have been all over it.

Yeah, I guess you are right ..... wishful thinking on my part.

Your Device name is built from TX for transmitter followed by Mac address

Nelbert

Did you get this working stable and reliable? I'd be interested in it. Resubscribed to sky and looking for a clean and high WAF (i.e. few cables as possible) method of integrating one of the sky boxes around the house.
Would integrate it into TVHeadend and then share to other HTPC boxes from there.

Johnboy1951

Nelbert wrote: »

Did you get this working stable and reliable? I'd be interested in it. Resubscribed to sky and looking for a clean and high WAF (i.e. few cables as possible) method of integrating one of the sky boxes around the house.
Would integrate it into TVHeadend and then share to other HTPC boxes from there.

You should look at something like this IMO
http://www.freetv.ie/hdmi-modulator/

Nelbert

Johnboy1951 wrote: »

You should look at something like this IMO
http://www.freetv.ie/hdmi-modulator/

So what I recommended originally? Had a feeling the cheap iptv meant grief and heartache. My hope was you'd have nailed it down by now.
Gonna go with the triax unit, move sky box towards server and use existing cabling the other way round to carry the IR via sky eye thingys

Johnboy1951

Nelbert wrote: »

So what I recommended originally? Had a feeling the cheap iptv meant grief and heartache. My hope was you'd have nailed it down by now.
Gonna go with the triax unit, move sky box towards server and use existing cabling the other way round to carry the IR via sky eye thingys

You could get both TX & Rx which would avoid all messing about.
I noticed the more recent versions have the ability to feed multiple Rx and also can carry IR signals.

Nelbert

Johnboy1951 wrote: »

You could get both TX & Rx which would avoid all messing about.
I noticed the more recent versions have the ability to feed multiple Rx and also can carry IR signals.

So something like this?
http://m.ebay.co.uk/itm/1080P-3D-100m-120m-HDMI-Extender-Over-Single-LAN-RJ45-Cat5-6-Cable-TCP-IP-Router-/121708232481?hash=item1c56603f21%3Ag%3AcXYAAOSwPcVVq-hg&_trkparms=pageci%253A4f34180a-78e4-11e7-b90c-74dbd1803d54%257Cparentrq%253Aac16d3aa15d0a9cbad3fd4b9fffc2bb5%257Ciid%253A1

emaherx

Johnboy1951 wrote: »

You could get both TX & Rx which would avoid all messing about.
I noticed the more recent versions have the ability to feed multiple Rx and also can carry IR signals.

Even using RX and TX devices you would still have the multicast storm issue. Which is our only issue with the device anyway.

It's possible the right switches would sort that, but your switches which are meant to handle multicast traffic couldn't, so until we test other switches I couldn't recommend that.

You could always use a dedicated switch to make a Network just for these, but that gets expensive.

The proxy solution does work but relies on another device with 2 NIC’s.

As a matter of interest how does the DVBT modulator behave when distributed along with the Saorview signal? Or is that the reason you are building a 3 tuner DVBT server?

Nelbert

emaherx wrote: »

Even using RX and TX devices you would still have the multicast storm issue. Which is our only issue with the device anyway.

It's possible the right switches would sort that, but your switches which are meant to handle multicast traffic couldn't, so until we test other switches I couldn't recommend that.

You could always use a dedicated switch to make a Network just for these, but that gets expensive.

The proxy solution does work but relies on another device with 2 NIC’s.

As a matter of interest how does the DVBT modulator behave when distributed along with the Saorview signal? Or is that the reason you are building a 3 tuner DVBT server?

Getting wife approval for purchase at the moment..... a lot of the iptv devices all specify gigabit switches etc. which is a red flag for network load... running second lan cables not an option.

The 3 DVB-T is more of an ideal. One dedicated to Sky, one dedicated to each Mux on soarview. Initially I'll probably use one of the two DVB-T I have and run soarview through it too (from my research it should be a non-issue) to keep initial costs down.
Will likely buy modulator initially then following pay day buy io link and sky eyes if wife not fully satisfied. Hoping wife will use sky plus app for time being.

It'll all be feed into tvheadend and distributed same as our soarview and freesat channels currently are. Just going to give the sky box it's own channel number on tvheadend. By moving the sky box to my tvheadend server the existing satellite cables can be used for sky eyes (my server and dish are only small distance apart).

Did I not read earlier in the thread you bought one of the modulators?

Johnboy1951

For some reason I have not investigated, when using the Sky+HD box through the modulator, there is an appreciable delay from pressing the remote to a reaction on the display. All equipment in the same room.
I think the delay here is about 5 secs.
It could also be due to my particular hardware and set up ... don't know.

I have a similar delay in Kodi when changing channel from Sky-Box to IPTV-Stream from the LK device.

It does not affect me as I use it only when I have a particular program to view ..... maybe a match or such .... so I do not require quick channel change.

emaherx wrote: »

Even using RX and TX devices you would still have the multicast storm issue. Which is our only issue with the device anyway.

I wondered if the behaviour of the multicast stream would in some way be 'corrected' by having its own Rx to talk to.

It's possible the right switches would sort that, but your switches which are meant to handle multicast traffic couldn't, so until we test other switches I couldn't recommend that.

You could always use a dedicated switch to make a Network just for these, but that gets expensive.

The proxy solution does work but relies on another device with 2 NIC’s.

As a matter of interest how does the DVBT modulator behave when distributed along with the Saorview signal? Or is that the reason you are building a 3 tuner DVBT server?

My idea for 3 tuners was simply to ensure all Saorview channels be available, in addition to the Edision.
The Edision is essentially a third mux (with one channel).

The Edision output can be combined with the aerial, apparently without any negative consequences. I had worried that the strength of the Edision output might have some detrimental affect, but so far I have not noticed any.

emaherx

No the network switch "should" handle the multicast traffic and only allow data out on ports where it is requested.

It's a very efficient way of delivering a single video stream to multiple devices and actually reduces network load when it works.

emaherx

Nelbert wrote: »

Did I not read earlier in the thread you bought one of the modulators?

That I believe was Johnboy1951

Johnboy1951

emaherx wrote: »

No the network switch "should" handle the multicast traffic and only allow data out on ports where it is requested.

It's a very efficient way of delivering a single video stream to multiple devices and actually reduces network load when it works.

Yes I understand that ...... but the stream is going straight through.

My thought was that the Tx expects to find its companion receiver/s on the LAN.
Just maybe, failing to receive a recognisable response from a Rx is the reason for our probs.

..... or maybe not ......

Johnboy1951

Nelbert wrote: »

So something like this?
http://m.ebay.co.uk/itm/1080P-3D-100m-120m-HDMI-Extender-Over-Single-LAN-RJ45-Cat5-6-Cable-TCP-IP-Router-/121708232481?hash=item1c56603f21%3Ag%3AcXYAAOSwPcVVq-hg&_trkparms=pageci%253A4f34180a-78e4-11e7-b90c-74dbd1803d54%257Cparentrq%253Aac16d3aa15d0a9cbad3fd4b9fffc2bb5%257Ciid%253A1

Not sure about that one ....... I came across similar devices which had an IR facility and also would multicast to multiple Rx.
I don't have a link at present.

EDIT:

This is one with an IR Tx/Rx
http://www.ebay.co.uk/itm/120m-HDMI-Over-Ethernet-Extender-Single-Cable-Supports-IR-/172535454773?hash=item282bea1c35:g:KmUAAOSw2gxYpld8

but unsure about multiple receivers on that device ........ if you require the signal at multiple locations.

emaherx

Johnboy1951 wrote: »

Yes I understand that ...... but the stream is going straight through.

My thought was that the Tx expects to find its companion receiver/s on the LAN.
Just maybe, failing to receive a recognisable response from a Rx is the reason for our probs.

..... or maybe not ......

No, the whole point of multicast is it shouldn't wait for or care about a response it just sends out data regardless if any other devices are listening. And it's data is addressed to everyone so simple switches just forward the data to everyone as they don't know what else to do with it. Smart switches should only forward to ports where a device shows interest.

Johnboy1951

emaherx wrote: »

No, the whole point of multicast is it shouldn't wait for or care about a response it just sends out data regardless if any other devices are listening. And it's data is addressed to everyone so simple switches just forward the data to everyone as they don't know what else to do with it. Smart switches should only forward to ports where a device shows interest.

Yes, but unfortunately we I do not know if these devices are properly compliant or what arrangement they have for connecting to their receivers.
I doubt they are compliant.
Those two switches of mine work for other multicast streams as I recall, but not here.

Nelbert

Johnboy1951 wrote: »

Not sure about that one ....... I came across similar devices which had an IR facility and also would multicast to multiple Rx.
I don't have a link at present.

EDIT:

This is one with an IR Tx/Rx
http://www.ebay.co.uk/itm/120m-HDMI-Over-Ethernet-Extender-Single-Cable-Supports-IR-/172535454773?hash=item282bea1c35:g:KmUAAOSw2gxYpld8

but unsure about multiple receivers on that device ........ if you require the signal at multiple locations.

will probably stick with the modulator idea. Seems less potential hiccups and tvheadend is already working really well with good WAF with kodi front ends.

Johnboy1951

Nelbert wrote: »

will probably stick with the modulator idea. Seems less potential hiccups and tvheadend is already working really well with good WAF with kodi front ends.

I tend to agree .... less complicated set up and channel can be recorded just like any other DVB-T channel.

emaherx

Id be inclined to agree and I haven't tried the DVBT modulator device, but it sounds like a much more network friendly idea. At least with consumer grade network kit anyway.

mick_ser

Have stacked 5 x Technomate HDMI modulators and Saorview no issues. http://www.technomate.com/products/TM%252dRF-HD.html
Got deal for them see http://www.megavision.ie/tm-rf-hdmi-mod.html

Anyone recommend a good encoder? Where best to get them? Everyone using the iSolem?

Nelbert

mick_ser wrote: »

Have stacked 5 x Technomate HDMI modulators and Saorview no issues. http://www.technomate.com/products/TM%252dRF-HD.html
Got deal for them see http://www.megavision.ie/tm-rf-hdmi-mod.html

Anyone recommend a good encoder? Where best to get them? Everyone using the iSolem?

Do you just daisy chain them and then combine with soarview right at the end?
Good to know there's no issues. The giant internet bookstore seems to be a good bit cheaper than the link you posted with the current exchange rate.

Johnboy1951

mick_ser wrote: »

Have stacked 5 x Technomate HDMI modulators and Saorview no issues. http://www.technomate.com/products/TM%252dRF-HD.html
Got deal for them see http://www.megavision.ie/tm-rf-hdmi-mod.html

Anyone recommend a good encoder? Where best to get them? Everyone using the iSolem?

Seem to be a well priced unit ...... £129.99 (€144.30) from Tech store
http://www.technomate.com/store/products/TM%252dRF-HD.html

Nelbert

So weak, saw the exchange rate was good today so ordered technomate off amazon............ will report back on WAF once integrated into TVheadend.

Johnboy1951

Nelbert wrote: »

So weak, saw the exchange rate was good today so ordered technomate off amazon............ will report back on WAF once integrated into TVheadend.

I am interested to know if you have a similar delay after using the remote as I posted about.

Nelbert

Johnboy1951 wrote: »

I am interested to know if you have a similar delay after using the remote as I posted about.

Reviews I've read on the technomate suggest approx 0.8 second delay. will let you know though.

mick_ser

Yeah daisy chained them and combined with Saorview at the end. Saw a hotel done too using these stacked with a headend and Saorview. Got the 3+ offer at 125 each so good value I thought...

Johnboy1951

I had attempted to combine the Saorview signal at first but the RTE2 mux was swamped apparently.
I tried initially changing the freq used but gave up and just separated the signals until I get the urge to tidy things up.

Nelbert

Worked out about 135 with Amazon so I'm fairly happy. Got a splitter / combiner today and have my cabling ready for the techno mate to just be plugged in.

I had split my soarview to the two DVB-T tuners so I've put the combiner before this split which means the sky box will be available to either tuner and hopefully minimise any potential recording / viewing conflicts. Still think longer term I prefer the idea of a third dedicated tuner for it but it can wait.

Nelbert

Just an update guys.... arrived today. Set up and working well already.

The 2017 version lets you loop in an aerial (says so in the manual) and soarview works via the technomate which has helped reduced signal loss on my setup a good bit vs using the cheap combiner I got.

Channel change delay is about 4-5 seconds but I'm pretty sure most of that is tvheadend buffer (I've live pause / timeshift enabled). Will test more at the weekend to see if I can bring this down.

Unsure whether to bother with sky eye given the delay.... would make menus unusable.
Might stick with sky+ app as THE remote for this sky box.

Johnboy1951

Nelbert wrote: »

Just an update guys.... arrived today. Set up and working well already.

The 2017 version lets you loop in an aerial (says so in the manual) and soarview works via the technomate which has helped reduced signal loss on my setup a good bit vs using the cheap combiner I got.

Channel change delay is about 4-5 seconds but I'm pretty sure most of that is tvheadend buffer (I've live pause / timeshift enabled). Will test more at the weekend to see if I can bring this down.

Unsure whether to bother with sky eye given the delay.... would make menus unusable.
Might stick with sky+ app as THE remote for this sky box.

I'm happier knowing that the delay is not something peculiar to my set up.
I hope you find the cause .... look forward to further info from you.
Thanks.

Nelbert

Johnboy1951 wrote: »

I'm happier knowing that the delay is not something peculiar to my set up.
I hope you find the cause .... look forward to further info from you.
Thanks.

Do you have an Edison or a Technomate? Not sure it would make much difference as I'm pretty confident the delay is related to my dvb-t tuner and tvheadend setup.

There's a fringe benefit to not getting sky eye (wife seems happy enough to use sky plus app).... I can use the cash to get a dedicated dvb-t for the technomate.

Johnboy1951

Nelbert wrote: »

Do you have an Edison or a Technomate? Not sure it would make much difference as I'm pretty confident the delay is related to my dvb-t tuner and tvheadend setup.

There's a fringe benefit to not getting sky eye (wife seems happy enough to use sky plus app).... I can use the cash to get a dedicated dvb-t for the technomate.

I have an Edision .... but they sure look the same with the same spec etc.

What setting might be edited in tvheadend to reduce the delay?

EDIT:

I reduced the "Input buffer (bytes): 188000" to 18800 and that appears to have had a beneficial effect.