rtp-over-tcp doesn't work with minisatip

[stauraum]

I don't know whats wrong.

root@bruno:~# vdr -V vdr (2.2.0/2.2.0) - The Video Disk Recorder conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu epgsearch (1.0.1.beta5) - search the EPG for repeats and more epgsearchonly (0.0.1) - Direct access to epgsearch's search menu live (0.3.0) - Live Interactive VDR Environment quickepgsearch (0.0.1) - Quick search for broadcasts restfulapi (0.2.6.5) - Offers a RESTful-API to retrieve data from VDR satip (2.2.5) - SAT>IP Devices streamdev-server (0.6.1-git) - VDR Streaming Server vdrmanager (0.14) - VDR-Manager plugin vnsiserver (1.5.2) - VDR-Network-Streaming-Interface (VNSI) Server

ii vdr-plugin-satip 2.2.4+git20171118-f3fe1e amd64 SAT>IP plugin for VDR

~ # ps -efl|grep minisat|grep -v grep 781 root 0:04 minisatip7 -f -g --satip-tcp ~ #

satip.CICAM = 0 0 satip.DisabledFilters = satip.DisabledSources = satip.EnableCIExtension = 0 satip.EnableEITScan = 0 satip.OperatingMode = 3 satip.TransportMode = 2

2018-01-09T11:28:52.563742+01:00 bruno vdr: [275] SATIP-ERROR: Connection timeout - retuning [device 0] 2018-01-09T11:28:52.566249+01:00 bruno vdr: [275] SATIP-ERROR: Detected invalid status code 454: rtsp://192.168.2.15/ [device 0] 2018-01-09T11:28:52.566573+01:00 bruno vdr: [275] SATIP-ERROR: Connect failed [device 0] 2018-01-09T11:28:57.838871+01:00 bruno vdr: [275] SATIP-ERROR: Connection timeout - retuning [device 0] 2018-01-09T11:28:57.841376+01:00 bruno vdr: [275] SATIP-ERROR: Detected invalid status code 454: rtsp://192.168.2.15/ [device 0] 2018-01-09T11:28:57.841698+01:00 bruno vdr: [275] SATIP-ERROR: Connect failed [device 0] 2018-01-09T11:29:03.112695+01:00 bruno vdr: [275] SATIP-ERROR: Connection timeout - retuning [device 0] 2018-01-09T11:29:03.115334+01:00 bruno vdr: [275] SATIP-ERROR: Detected invalid status code 454: rtsp://192.168.2.15/ [device 0] 2018-01-09T11:29:03.115645+01:00 bruno vdr: [275] SATIP-ERROR: Connect failed [device 0] 2018-01-09T11:29:08.387611+01:00 bruno vdr: [275] SATIP-ERROR: Connection timeout - retuning [device 0] 2018-01-09T11:29:08.390423+01:00 bruno vdr: [275] SATIP-ERROR: Detected invalid status code 454: rtsp://192.168.2.15/ [device 0] 2018-01-09T11:29:08.390741+01:00 bruno vdr: [275] SATIP-ERROR: Connect failed [device 0]

[rofafor]

You should look at the minisatip logs, why it's replying 454.

[stauraum]

i see nothing ... :-(

https://pastebin.com/Gas83jTk

[rofafor]

There are plenty of "connection refused" messages in your log, so I'd check any firewall rules first. However, the error code 454 is "Session not found", but I don't know enough of minisatip internals what might be a cause for this: The RTSP session identifier value in the "Session:" header field of the request is missing, invalid, or has timed out. Returned when issuing the wrong session identifier value in a request.

[9000h]

looks like you have a digibit r1 or similar, you should try to update the firmware https://github.com/perexg/satip-axe/issues/94#issuecomment-360391337

[stauraum]

minisatip8 doesn't solve my issue :-( There is no firewall etc. between my VDR and my digibit r1.

· 2018-01-26T09:42:59.491996+01:00 bruno vdr: [207] SATIP-ERROR: Connection timeout - retuning [device 0] │···································· 2018-01-26T09:42:59.494082+01:00 bruno vdr: [207] SATIP-ERROR: Detected invalid status code 454: rtsp://192.168.2.15/ [device 0] │···································· 2018-01-26T09:42:59.494405+01:00 bruno vdr: [207] SATIP-ERROR: Connect failed [device 0]

[9000h]

try to add to the minisatip options -O

-O --satip-tcp Use RTSP over TCP insead of UDP for data transport

[stauraum]

I've running minisatip8 with this option. With tvheadend rts-over-tcp is working, but VDR is my preferred DVR.

[9000h]

did you have an outdated libcurl (7.36.0 or greater is required)?

[stauraum]

libcurl is 7.36.0-1fnu0~trusty

[9000h]

is there a Fritz!box in between with ports in "Green Mode"?

[stauraum]

No. There is a TP-Link with OpenWRT. No power-saving-settings enabled.

[9000h]

did you also try without -O, if your network is clean UDP should not be an issue

[stauraum]

yes. without -O there are sometimes disorders. I would use tcp-transport to know, if the issue appears.

[9000h]

I hope you have also adjust on the vdr/tvhedend side the kernel mem settings like

net.core.wmem_max=20491520 net.core.rmem_max=20491520 net.ipv4.tcp_mem = 65536 131072 262144 net.ipv4.udp_mem = 65536 131072 262144

[stauraum]

I dont know if this works. My VDR and tvheadend are running inside docker containers.

I will test this when my family-members are offline.

[9000h]

and by the way check nstat -a|grep Udp if you have unusual high or increasing UdpRcvbufErrors or UdpInErrors

[rofafor]

1) Verify, that the satip plugin is sending a proper transport header (RTP/AVP/TCP;unicast) in RTSP SETUP messages. 2) Verify, that the satip plugin detects your server with a proper name. It should contain a string "minisatip", otherwise the plugin won't allow you to use RTP-over-TCP 3) Verify, that Docker port forwarding settings are setup correctly and match with the "portrange" command-line parameter of the satip plugin.

[stauraum]

@9000h i will check this soon

@rofafor

1. How can ich check this?
2. The automatic detection works successful
3. VDR runs in Host-mode, no port forwardings needed.

[CvH]

@stauraum random idea, install LibreELEC at an VM/RPi ... and activate the vdr addon there (with included vdr-plugin-satip) if it works there - then you can rule out that it is a problem of the box at least

[stauraum]

@CvH i've installed LibreELEC in a VirtualBox. The Problem appears.

When i switch to rtsp-over-tcp there are some connection failures.

At the moment i'm running tvheadend fine and stable with 5 connected clients. The webinterface is very terrible an i'm missing the clear text configuration. But it's working at the moment.

[rofafor]

@stauraum, you can use tcpdump/wireshark/tshark/your_favourite_capture_application to capture RTSP traffic on port 554 (or whatever you've configured on your minisatip).

[9000h]

found a minor typo also

--- socket.c.orig       2018-02-06 14:34:11.822574200 +0100
+++ socket.c    2018-02-06 14:34:42.902233383 +0100
@@ -128,7 +128,7 @@

 void cSatipSocket::Close(void)
 {
-  debug1("%s sockerPort=%d", __PRETTY_FUNCTION__, socketPortM);
+  debug1("%s socketPort=%d", __PRETTY_FUNCTION__, socketPortM);
   // Check if socket exists
   if (socketDescM >= 0) {
      Leave();

[9000h]

looks like the issue is happen in function SetupTransport tuner.c:385

so changing the call to SetupTransport seams to fix it, but I did not check if this has any other side effects

--- rtsp.c.orig 2018-02-06 17:06:39.416598407 +0100
+++ rtsp.c      2018-02-06 17:07:10.163810424 +0100
@@ -442,7 +442,7 @@
               SATIP_CURL_EASY_SETOPT(handleM, CURLOPT_INTERLEAVEFUNCTION, cSatipRtsp::InterleaveCallback);
               SATIP_CURL_EASY_SETOPT(handleM, CURLOPT_INTERLEAVEDATA, this);
               modeM = cSatipConfig::eTransportModeRtpOverTcp;
-              tunerM.SetupTransport(-1, -1, NULL, NULL);
+              tunerM.SetupTransport(rtp, rtcp, NULL, NULL);
               }
            FREE_POINTER(tmp);
            FREE_POINTER(destination);

[rofafor]

This change enables UDP receiving as TCP is done via interleaving with curl. Please, verify, that your video traffic is really TCP as the minisatip is announcing in RTSP headers.

[9000h]

tcpdump port 554 and tcp -vvv

18:42:08.179021 IP (tos 0x0, ttl 64, id 23114, offset 0, flags [DF], proto TCP (6), length 2948)
    satip.fritz.box.rtsp > Acer.fritz.box.50162: Flags [.], cksum 0xf1b3 (incorrect -> 0x8e00), seq 11716218:11719114, ack 1718, win 107, options [nop,nop,TS val 2940015131 ecr 1116969722], length 2896: RTSP
18:42:08.193820 IP (tos 0x0, ttl 64, id 37859, offset 0, flags [DF], proto TCP (6), length 52)
    Acer.fritz.box.50162 > satip.fritz.box.rtsp: Flags [.], cksum 0xcd89 (correct), seq 1718, ack 11719114, win 1, options [nop,nop,TS val 1116969743 ecr 2940015130], length 0
18:42:08.193920 IP (tos 0x0, ttl 64, id 37860, offset 0, flags [DF], proto TCP (6), length 253)
    Acer.fritz.box.50162 > satip.fritz.box.rtsp: Flags [P.], cksum 0x8430 (correct), seq 1718:1919, ack 11719114, win 1, options [nop,nop,TS val 1116969743 ecr 2940015130], length 201: RTSP, length: 201
    PLAY rtsp://192.168.178.129/stream=1?src=1&freq=11493&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&sr=22000&fec=23 RTSP/1.0
    CSeq: 11
    Session: 1633108117
    User-Agent: vdr-satip/2.3.1-GIT-e008ee0 (device 0)

18:42:08.194506 IP (tos 0x0, ttl 64, id 37861, offset 0, flags [DF], proto TCP (6), length 52)
    Acer.fritz.box.50162 > satip.fritz.box.rtsp: Flags [.], cksum 0xccb8 (correct), seq 1919, ack 11719114, win 8, options [nop,nop,TS val 1116969744 ecr 2940015130], length 0
18:42:08.195103 IP (tos 0x0, ttl 64, id 37862, offset 0, flags [DF], proto TCP (6), length 52)
    Acer.fritz.box.50162 > satip.fritz.box.rtsp: Flags [.], cksum 0xccb0 (correct), seq 1919, ack 11719114, win 16, options [nop,nop,TS val 1116969744 ecr 2940015130], length 0
18:42:08.197744 IP (tos 0x0, ttl 64, id 23116, offset 0, flags [DF], proto TCP (6), length 1500)
    satip.fritz.box.rtsp > Acer.fritz.box.50162: Flags [.], cksum 0xec93 (correct), seq 11719114:11720562, ack 1718, win 107, options [nop,nop,TS val 2940015151 ecr 1116969743], length 1448: RTSP
18:42:08.198044 IP (tos 0x0, ttl 64, id 23117, offset 0, flags [DF], proto TCP (6), length 2948)
    satip.fritz.box.rtsp > Acer.fritz.box.50162: Flags [.], cksum 0xf1b3 (incorrect -> 0x4777), seq 11720562:11723458, ack 1718, win 107, options [nop,nop,TS val 2940015151 ecr 1116969743], length 2896: RTSP
18:42:08.198076 IP (tos 0x0, ttl 64, id 37863, offset 0, flags [DF], proto TCP (6), length 52)

a tcpdump port 554 and udp -vvv shows no traffic

[rofafor]

Can you capture also the SETUP command (and the response) before the PLAY command? The UDP traffic isn't on the port 554, but on a random selected socket pair that's defined in the SETUP response.

[9000h]

tcpdump -n host 192.168.178.129 -w /tmp/dump.pcap (with the patch active) dump.pcap.gz

but it's still not 100%

as a reference http://www.informit.com/articles/article.aspx?p=169578&seqNum=3

[rofafor]

The dump looks valid, but your SetupTransport hack doesn't as you're just opening ports 0 and 1 for UDP in it. However, I noticed two bugs in the code that are now fixed in master, but I doubt they will make any difference for this issue.

[9000h]

it makes a difference but there are still issues a vdr log with -t 0xff

syslog.txt.gz

[rofafor]

Minisatip doesn't answer to PLAY command issued at Feb 6 22:18:50 in 1.5 seconds and RTSP session is re-created. This should be debugged with a network capture to see, whether the minisatip really got the message and did it responded back, but libcurl messed up the message or something. Make sure, you're using the latest libcurl version!

[9000h]

curl 7.47.0 the same test tcpdump

dump.pcap.gz

[9000h]

it did not work right up to now, but it works better on low bandwidth SD channels could it be that the video data / control data is getting in now handled wrong, the outgoing traffic on the minisatip side goes queued up until it get dropped

[9000h]

rtsp.c SATIP_CURL_EASY_SETOPT(handleM, CURLOPT_MAX_RECV_SPEED_LARGE, eMaxDownloadSpeedMBits * 131072L); looks like this is also part of the issue, as I had SD channel that did work but HD channels did not, if it's commented out HD channels did work better but still with artifacts or the screen stops if the screen freezes minisatip is still sending data and RTSP Cseq count increases also satip shows then Feb 7 18:47:26 Acer vdr: video: 7:52:49.165+1064 97 580/\ms 0+1 v-buf Feb 7 18:47:27 Acer vdr: [29862] SATIP-ERROR: Connection timeout - retuning [device 0] Feb 7 18:47:32 Acer vdr: [29862] SATIP-ERROR: Connection timeout - retuning [device 0]

(all channels are fine with UDP)

[rofafor]

So, you're saying that 20Mbit/s is not enough for your HD channels. What's the actual bitrate of those channels? Please, check your network stack buffer sizes and make sure, they are big enough.

The problem is that satip plugin doesn't get any PLAY responses from minisatip during the interleaved data and the requests timeout that leads to re-tuning loop. This could be a bug in satip plugin or libcurl, but I didn't notice such behaviour when I implemented the feature against the minisatip, but the server and client were on the same host. The RTP-over-TCP is just an experimental feature in the plugin and the performance is much worse than with UDP due to the current design. As the protocol isn't even included in the SAT>IP specifications, the implementation will exists as a dirty hack in the future too.

[9000h]

you have to take also in account the overhead of tcp, 20 bytes gets consumed more per packet.

[9000h]

I understand your position about the RTP-over-TCP, but it could be beneficial if you have some unreliable device like powerline adapters in between. I do not have any issue with UDP here.

The latest tcpdump I did upload did show all play requests get answered by minisatip if I did not overlooked something.

I will not insist any further.

[rofafor]

Removing the download limit is ok for satip as it's for live streaming only and therefore the receiving buffer is harder to get over/underflow. If you take a look at your latest packet capture and add a "rtsp.request || rtsp.response" filter, you'll see that there aren't any responses for RTSP PLAY commands after 5.5 seconds until the RTSP connection is teared down and re-created (OPTIONS) at 12.9 seconds. I might be using the libcurl interface in an invalid way, but the commands are shown in network traffic, so I doubt it. For me it looks like minisatip isn't listening RTSP commands or drops these packets while sending the interleaved data back.

[rofafor]

The speed limit has now been removed.

[catalinii]

Feel free to upload also the minisatip logs ( -l http ) with the tcpdump capture.

Thanks

[9000h]

btw. minisatip rtp-over-tcp is working with tvheadend and also with VLC the vdr-plugin-satip did run in some reconnect timeout an did re-tune every 2 Seconds

for tests you can set VLC to TCP in the advanced settings https://www.wowza.com/docs/how-to-configure-vlc-media-player-for-rtsp-rtp-playback-rtsp-rtp-interleaved-and-tuning

[9000h]

I did some experiments and found a way to get rtsp-over-tcp going, but it did break Unicast

bool cSatipTuner::KeepAlive(bool forceP)
{
  debug16("%s (%d) tunerState=%s [device %d]", __PRETTY_FUNCTION__, forceP, TunerStateString(currentStateM), deviceIdM);
  cMutexLock MutexLock(&mutexM);
  if (keepAliveM.TimedOut()) {
     keepAliveM.Set(timeoutM);
     forceP = true;
     }
  if (forceP && !isempty(*streamAddrM)) {
     cString uri = GetBaseUrl(*streamAddrM, streamPortM);
     if (!rtspM.Options(*uri))
        return false;
     }
     cString uri = GetBaseUrl(*streamAddrM, streamPortM);
     rtspM.Options(*uri);

  return true;
}

how to get it right https://stackoverflow.com/questions/38733021/libcurl-rtsp-keep-alive-with-rtsp-server

[rofafor]

I don't understand your solution - you'll have to send the OPTIONS command twice?

[9000h]

with this both uincast and rtp-over-tcp is working

bool cSatipTuner::KeepAlive(bool forceP)
{
  debug16("%s (%d) tunerState=%s [device %d]", __PRETTY_FUNCTION__, forceP, TunerStateString(currentStateM), deviceIdM);
  cMutexLock MutexLock(&mutexM);
  if (keepAliveM.TimedOut()) {
     keepAliveM.Set(timeoutM);
     }

  if (!isempty(*streamAddrM)) {
     cString uri = GetBaseUrl(*streamAddrM, streamPortM);
     rtspM.Options(*uri);
     }

  return true;
}

[rofafor]

So, it's the forceP flag that's not behaving correctly within TCP mode. Can you check, how does the Session header of SETUP command look like - the plugin might not parse that properly and therefore keepAliveM timer is not working as it should.

[9000h]

Hi, should this not be already visible the dump above https://github.com/rofafor/vdr-plugin-satip/issues/47#issuecomment-363592795 CU 9000h

[9000h]

so this is it

OPTIONS rtsp://192.168.178.129/ RTSP/1.0
CSeq: 1
User-Agent: vdr-satip/2.3.1-GIT-8dc4844 (device 0)

RTSP/1.0 200 OK
Date: Tue, Feb 6 22:44:52 2018 GMT
Cseq: 1
Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN
Server: minisatip/0.7.15

SETUP rtsp://192.168.178.129/?src=1&freq=11493&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&sr=22000&fec=23 RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: vdr-satip/2.3.1-GIT-8dc4844 (device 0)

RTSP/1.0 200 OK
Date: Tue, Feb 6 22:44:52 2018 GMT
Cseq: 2
Transport: RTP/AVP/TCP;interleaved=0-1
Session: 1804289383;timeout=30
com.ses.streamID: 1
Server: minisatip/0.7.15

DESCRIBE rtsp://192.168.178.129/stream=1 RTSP/1.0
CSeq: 3
Session: 1804289383
Accept: application/sdp
User-Agent: vdr-satip/2.3.1-GIT-8dc4844 (device 0)

RTSP/1.0 200 OK
Date: Tue, Feb 6 22:44:52 2018 GMT
Session: 1804289383
Cseq: 3
Content-type: application/sdp
Content-Base: rtsp://192.168.178.129/
Server: minisatip/0.7.15
Content-Length: 250

v=0
o=- 1804289383 1804289383 IN IP4 192.168.178.129
s=SatIPServer:1 4 4 2
t=0 0
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=control:stream=1
a=fmtp:33 ver=1.0;src=1;tuner=1,255,1,15,11493,h,8psk,,0.35,dvbs2,22000,23;pids=
b=AS:5000
a=inactive
PLAY rtsp://192.168.178.129/stream=1?addpids=5101,5102 RTSP/1.0
CSeq: 4
Session: 1804289383
User-Agent: vdr-satip/2.3.1-GIT-8dc4844 (device 0)

RTSP/1.0 200 OK
Date: Tue, Feb 6 22:44:52 2018 GMT
Session: 1804289383
Cseq: 4
RTP-Info: url=rtsp://192.168.178.129/stream=1;seq=6141;rtptime=2958453
Range: npt=0.000-
Server: minisatip/0.7.15

PLAY rtsp://192.168.178.129/stream=1?src=1&freq=11493&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&sr=22000&fec=23 RTSP/1.0
CSeq: 5
Session: 1804289383
User-Agent: vdr-satip/2.3.1-GIT-8dc4844 (device 0)

RTSP/1.0 200 OK
Date: Tue, Feb 6 22:44:52 2018 GMT
Session: 1804289383
Cseq: 5
RTP-Info: url=rtsp://192.168.178.129/stream=1;seq=6172;rtptime=2958453
Range: npt=0.000-
Server: minisatip/0.7.15

PLAY rtsp://192.168.178.129/stream=1?pids=0,17,18,20,5101,5102,5103,5105,5106 RTSP/1.0
CSeq: 6
Session: 1804289383
User-Agent: vdr-satip/2.3.1-GIT-8dc4844 (device 0)

RTSP/1.0 200 OK
Date: Tue, Feb 6 22:44:52 2018 GMT
Session: 1804289383
Cseq: 6
RTP-Info: url=rtsp://192.168.178.129/stream=1;seq=6187;rtptime=2958453
Range: npt=0.000-
Server: minisatip/0.7.15

[rofafor]

So it's 30 seconds then. Unfortunately your captures are too short for checking what's happening during the keep-alive OPTIONS command. It would be great if you could capture that with the faulty (current master) and working (your patch) setup.

[9000h]

plain vanilla plugin tcpdump -ni any port 554 -w dump.pcap -s 0

https://drive.google.com/file/d/1DGSoGadvGyfm9LbDMHnkDZUQaU3JTTi4/view

[9000h]

now with the patch https://drive.google.com/file/d/1611jhY5N3qyOs2f_6eeqreqszzBDznhr/view

[rofafor]

Good. So, the both are actually broken. Can you enable some debug output in vanilla plugin: 1) cSatipTuner::SetSessionTimeout()

• values of timeoutP parameter and timeoutM member variables 2) cSatipTuner::KeepAlive()
• when the function is called - I need just timestamps 3) cSatipRtsp::Options()
• when the function is called
• value of return code aka. rc
• value of result