SAT>IP protocol

Ofink Uspärk

Hi,

I like to share my experience with the SAT>IP protocol, because no good info is in the Wiki (at time):

- If you like to use any SAT>IP server with TVH you need to install the "unstable" branch, not "beta" or "stable" (see http://tvheadend.org/projects/tvheadend/wiki/AptRepository)

- After initial install (see http://tvheadend.org/projects/tvheadend/wiki/Install_and_initial_setup), you need to go to he Web Interface and select "DVB Inputs". If you show your servers... great! if no continue reading.

- Current implementation of the SAT>IP protocol in the TVHeadEnd is enforcing the use of the SSDP/UPNP autodiscovery. Also, if the code don't like your servers then you don't be warned about anything, and you think that SAT>IP don't work. But you can fix it! First enable logging; to do it edit file "/etc/default/tvheadend" and change last line TVH_ARGS="" with this new TVH_ARGS=" -l /home/hts/hts.log --trace httpc,upnp,udp,satip". After that restart the service ($service tvheadend restart), and try to review the log. You can have different troubles:

- The TVHeadEnd can't discover your device using the SSDP/UPNP protocol. In this case you can fix it forcing to read the device description. Edit the file "/etc/default/tvheadend" and add the URL of the XML description of your device (you can found the URL with some external tool). As example TVH_ARGS="--satip_xml http://192.168.1.111:8080/description.xml". With this I fixed the discovery of my STB device.

- In some cases the TVHeadEnd can discover your server (automatically or using the "--satip_xml" parameter) but can't read the config. This can be done if the HTTP server don't send correct headers (actually "Content-type: text/xml" is enforced, I hope this will be fixed!); or if the XML file misses some required info (I suggest to developers to put more trace info about faulty XML descriptions); or if some other problem exists.

- Other problems can be related to incorrect behaviour of the tuner. So disable trace of "upnp" and "httpc" and try yo search where is the problem: no full TS support, timeouts when tuning, incorrect parameters, etc. Changing some values of the config using the Web Interface you can fix several problems.

I suggest to you to send all your problems to the develpers for improving the compatibility with SAT>IP devices. I feel this protocol be the facto standard for DVB in the future.

Ofink Uspärk

Hi,

The Smart Mirage CX-02 STB isn't autodiscovered, but it can be used if I use the parameter "--satip_xml URL".

For developers I put one log at http://pastebin.com/MbynhCpJ

The .181 device is the STB and the .17 is the machine where TVH is running.

Please, can you fix this?

Ofink Uspärk

Hi,

Another suggestion to fix problems with some servers: Please, add the option to the parameter "--satip_xml URL" to support "file:///" acccess. Remember to add the option to stablish the IP of the server (at time, it's decoded from the http request). As example "--satip_xml file:///home/hts/my_satip_server.xml,192.168.1.200". This will simplifies much testing and fixing.

You aggree?

Ofink Uspärk

Hi,

Anyone agree my suggestion?

I'm doing several tests with SAT>IP products, and I like to improve the support for this protocol in TVH.

lukas buehl

Hey Ofink,

It looks like you’ve digged pretty deep into the Sat>IP tuner issue and I have a problem getting TVH to recognise my Devolo Sat>IP Tuner.

I was hoping you could help.

I’ve followed your steps that you describe above and described my problem a bit here: https://tvheadend.org/d/2637-sat-ip-config-questions?r=16270#message-16270 I’ve also uploaded my log-text there.

I added the correct desc.xml (which I could find only thanks to your logging suggestions!) to the startup arguments,

but TVH still wouldn’t recognise my tuner under TV Adapters.

Do you have another tip for me :) ?

Thanks!

P.s.: The tuner itself works fine on the network -works with all mobile apps and via vlc on mac,win,linux with a m3u playlist containing html links..

Roland A.

There might be another issue. I was wondering, why tvheadend was able to find my Kathrein EXIP-414E SAT>IP Server on one Raspberry directly, while it was not working on the Raspberry where it was supposed to run.

Turns out, as tvheadend seems to always bind to 0.0.0.0, when it comes to broadcasts, the broadcast that is used to detect SAT>IP servers, it sent to the wrong interface (and it is only sent to one of the ones that are found).

root@machine:~# netstat -tulpn |grep tvh tcp 0 0 0.0.0.0:9981 0.0.0.0:* LISTEN 27774/tvheadend tcp 0 0 0.0.0.0:9982 0.0.0.0:* LISTEN 27774/tvheadend udp 0 0 239.255.255.250:1900 0.0.0.0:* 27774/tvheadend udp 0 0 0.0.0.0:52421 0.0.0.0:* 27774/tvheadend

Using Wireshark, I found that the SSDP "M-SEARCH * HTTP/1.1" Packet, that was sent to 239.255.255.250, used my public internet IP as the source (which is ppp0 and not eth0).

Any idea, how to tell tvheadend to change this? Or maybe this can be done on system level?

root@machine:~# ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:27:eb:59:ca:2f brd ff:ff:ff:ff:ff:ff inet 192.168.110.1/24 brd 192.168.110.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::ba27:ebff:fe59:ca2f/64 scope link valid_lft forever preferred_lft forever 3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 192.168.111.1 peer 192.168.111.2/32 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::6b39:4e2e:dd9e:8826/64 scope link flags 800 valid_lft forever preferred_lft forever 49: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1452 qdisc htb state UNKNOWN group default qlen 3 link/ppp inet 83.135.8.XXX peer 62.214.YY.XX/32 scope global ppp0 valid_lft forever preferred_lft forever 50: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN group default qlen 500 link/none inet 172.22.0.69 peer 172.22.0.70/32 scope global tun1 valid_lft forever preferred_lft forever inet6 fe80::cbb7:addb:5949:1e0/64 scope link flags 800 valid_lft forever preferred_lft forever root@machine:~#

Again, on a Raspberry Pi where is only one external interface (next to lo), it seems to magically pick the correct one. :-)

On the other one (the one that generated the interface list above, it selects interface #49 as the broadcast source.
I'm using 4.2.3-20~g407c8a3~raspbianjessie from http://dl.bintray.com/mpmc/deb, if that is of help.

Roland A.

After thinking a little bit, I found I can fix this by myself.

ip route add 239.255.255.250/32 dev eth0

Might also be helpful for you, nevermind. Thanks for listening. :)