Cannot connect to RS using SAT>IP

[renzz]

I am using TVHeadend but want to connect to RS using SAT>IP to use a tuner that is not supported on my TVH system.

 

TVH can see all the RS tuners as SAT>IP devices, but when it tries to connect and use them it fails with

 

RTSP SETUP error -5 (Input/output error) [6-404]

 

In a debug log for TVH I can see it make a SETUP call to connect:

 

SETUP rtsp://192.168.1.201/?fe=1&freq=545.833&bw=8&msys=dvbt2&mtype=256qam&tmode=32k&gi=1128&pls=0 RTSP/1.0
Transport: RTP/AVP;unicast;client_port=55408-55409
CSeq: 1

 

but then RS rejects it with

 

RTSP/1.0 404 Stream Not Found' (rcseq: 1)

 

I raised this with the TVH guys and they say the SETUP command is valid (as described at http://www.satip.info/resources), so why is RS rejecting the connection?

 

TVH and svcdebug logs are attached

 

Thanks

TVHlog.log

support.zip

[Griga]

SETUP rtsp://192.168.1.201/?fe=1&freq=545.833&bw=8&msys=dvbt2&mtype=256qam&tmode=32k&gi=1128&pls=0

 

That's the problem. fe=1 (frontend = 1) selects the first tuner in the RS device list. According to your svchardware.xml it's a DVB-C tuner (Astrometa), so DVB-T2 can't work. The client should omit the fe parameter and leave the tuner selection to the server. See Sat>IP specifications 1.2.2, appendix A1.1

 

Binding to a particular frontend

SAT>IP servers mostly provide several frontends. A client should generally let the server automatically select a frontend. It does this by not including the “fe” parameter in its requests.

[renzz]

Thanks Griga, it looks like TVH is incorrectly reversing the order of tuners, so it tries to connect to tuner 1 (DVB-C) by specifying fe=3, and vice-versa. I'll raise it with the TVH guys.

[Tjod]

TVH should not set the fe= parameter at all.

 

If a user really needs to define a exact tuner. They could offer a special expert setting. Whether a user could set the tuner number. But it should be clear that ist should not be set unless the user knows exactly what he is doing and why.

[renzz]

The TVH guys are reluctant to remove fe= as they say people may need to target specific tuners (maybe they have different Diseqc per tuner). However, they have provided me with a workaround to tell TVH exactly what tuners are where in RS.

 

Solution is in the bug I raised at https://tvheadend.org/issues/4016

[Griga]

The TVH guys are reluctant to remove fe= as they say people may need to target specific tuners

 

It should be configurable for special purpose, but it should not be the default. That's clearly a bad idea. The default should be no frontend assignment as stated in the Sat>IP specifications (see my post above).

 

However, they have provided me with a workaround to tell TVH exactly what tuners are where in RS.

 

That's just a questionable work-around. It must be considered that the RS handles request -> tuner assignnments dynamically. If you have two DVB-T tuners and the first one is occupied by a recording or another streaming client, the RS will automatically use the second one. This feature is spoiled by using the fe parameter unnecessarily. And it spoils similar features in other Sat>IP servers as well. If the RS has started a DVB-T recording, it will reject TVH as client, because it stubbornly insists on a particular tuner that is occupied.

 

I think the TVH guys will learn it sooner or later... you can support the learning process by forwarding my statements to them

[perexg]

The problem is not that we specify FE, but the problem is that DVBViewer does not order correctly the frontend list in the XML description file. TVH assumes that the order in the XML file defines the fe indexes! Like DVBTC-1,DVBT2-2 means fe=1 is DVB-C and fe=2 or fe=3 are DVB-T2 tuners. We do support the no-fe config now, too.

[Griga]

Thanks for the hint. I will look after it.

[Griga]

Off-topic post moved to a separate thread.

[Griga]

vor 9 Stunden schrieb perexg:

The problem is not that we specify FE, but the problem is that DVBViewer does not order correctly the frontend list in the XML description file. TVH assumes that the order in the XML file defines the fe indexes!

 

I've checked it. The Sat>IP specifications neither prescribe a certain order nor an implicit frontend number definition. They only say

 

Zitat

A <satip:X_SATIPCAP> capabilities element should be included in the XML description of a SAT>IP server in
order to provide the SAT>IP supported modulation systems with the number of corresponding front-ends.

 

Regarding this,  your assumption is a proprietary thing and may cause incompatibilities. In the RS / DMS  the frontend order is user-defined (it establishes a priority) and may even contain non-standard frontends for ATSC or IPTV. So the only one who is able to assign / configure frontend numbers correctly is the user if he needs to for some reason, e.g. if satellite frontends are connected to different dishes that receive different satellite positions, so a client who wants to receive one of these satellite positions must connect to a specific server frontend.