Bug #4471
SAT>IP: Inactive streams created when the SETUP request triggers an error.
100%
Description
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.
History
Updated by Jaroslav Kysela over 7 years ago
- Status changed from New to Fixed
- % Done changed from 0 to 100
Applied in changeset commit:tvheadend|72128777940978239ba535c98d2c27648687c93f.
Updated by DSA APF over 7 years ago
Hi Jaroslav,
We're still testing it. However, the last patch seems to be correct.
Thank you!
D.
Updated by Jaroslav Kysela about 7 years ago
- Status changed from Fixed to Accepted
I have to revert this patch, because of bug #4499. Perhaps, this issue is already fixed with the other satip server updates.
Updated by Jaroslav Kysela about 7 years ago
- Status changed from Accepted to Fixed
Applied in changeset commit:tvheadend|0683521cb0c9c4384a245436a32a26e2439f487a.
Updated by Jaroslav Kysela about 7 years ago
- Status changed from Accepted to Fixed
Applied in changeset commit:tvheadend|b75bb114b7000b1aa42b795994d52194e43e9027.