Tvheadend

Hi,

We have found one tricky bug with “some” clients.

The problem appears when this condition is true:

- The TVHeadEnd is running as a SAT>IP server. And some frequencies are unavailable, for example, when using IPTV muxes as inputs.
- When one client request some unavailable frequency with a SETUP command, then it receives one error as the response (“RTSP/1.0 405 Method not allowed”).

Until here no problem!

- However, for each frequency unavailable the TVHeadEnd is creating internally a new “stream”. So, if the client requests, for example for 20 unused frequencies, then 20 “inactive streams” are created. Here one example of the response to a DESCRIBE command after these failed tuning requests:

RTSP/1.0 200 OK
Content-Type: application/sdp
Content-Length: 2617
CSeq: 40
Content-Base: rtsp://192.168.224.19/stream=25
v=0
o=- 8387533343261 8387533343384 IN IP4 192.168.224.19
s=SatIPServer:1 8 t=0 0
a=control:stream=3
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=4
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=5
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=6
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=7
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=8
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=9
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=10
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=11
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=12
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=13
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=14
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=15
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=16
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=17
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=18
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=19
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=20
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=21
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=22
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=23
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=24
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=25
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive

- The problem is then when the client can’t process such large response!
- This case is only true when the client uses the SETUP command for tuning unavailable frequencies.

So, we recommend to not instantiate any new stream when one error appears. In fact, if the server sends one error (4xx) it doesn’t have sense to create/modify/destroy any internal stream. Right?

We hope you consider this case and improve the behavior of the SAT>IP server module.
Regards.
D.