Project

General

Profile

Forums » General »

SAT>IP protocol

Added by Ofink Uspärk almost 10 years ago

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.


Replies (6)

RE: SAT>IP protocol - Added by Ofink Uspärk almost 10 years ago

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?

RE: SAT>IP protocol - Added by Ofink Uspärk almost 10 years ago

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?

RE: SAT>IP protocol - Added by Ofink Uspärk almost 10 years ago

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.

RE: SAT>IP protocol - Added by lukas buehl over 9 years ago

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/boards/5/topics/15557?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..

RE: SAT>IP protocol - Added by Roland A. about 7 years ago

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.

RE: SAT>IP protocol - Added by Roland A. about 7 years ago

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. :)

    (1-6/6)