rofafor / vdr-plugin-satip Goto Github PK

View Code? Open in Web Editor NEW

24.0 17.0 25.0 669 KB

SAT>IP plugin for the Video Disk Recorder (VDR)

License: GNU General Public License v2.0

Makefile 1.54% C 80.87% C++ 16.51% Python 1.08%

vdr plugin satip

vdr-plugin-satip's Introduction

This is an SAT>IP plugin for the Video Disk Recorder (VDR).

Written by: Rolf Ahrenberg
< R o l f . A h r e n b e r g @ s c i . f i >

Project's homepage: https://github.com/rofafor/vdr-plugin-satip

Latest version available at: https://github.com/rofafor/vdr-plugin-satip/releases

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2 as
published by the Free Software Foundation.
See the file COPYING for more information.

Requirements:

- Libcurl >= 7.36.0 - the multiprotocol file transfer library with RTSP support
http://curl.haxx.se/libcurl/

- PugiXML - Light-weight, simple and fast XML parser for C++
http://pugixml.org/
or
TinyXML - a simple, small, C++ XML parser
http://www.grinninglizard.com/tinyxml/

- Glibc >= 2.12 - the GNU C library (recvmmsg)
http://www.gnu.org/software/libc/

Description:

This plugin integrates SAT>IP network devices seamlessly into VDR.
You can use any SAT>IP channel like any other normal DVB channel for
live viewing, recording, etc. The plugin also features full section
filtering capabilities which allow for example EIT information to be
extracted from the incoming stream.

Installation:

tar -xzf /put/your/path/here/vdr-satip-X.Y.Z.tgz
make -C satip-X.Y.Z install

Configuration:

The plugin accepts a "--devices" (-d) command-line parameter defaulting
to two. This parameter defines how many simultaneous transponders can
be received, if there are available SAT>IP tuners.

The plugin accepts also a "--server" (-s) command-line parameter, that
can be used to manually configure static SAT>IP servers if autodetection
via UPnP somehow can't be used. Multiple service entries can be given
separated by a semicolon:

[<srcaddress>@]<ipaddress>[:<port>]|<model>[:<filter>]|<description>[:<quirk>];...

- srcaddress (Optional) Source address can be used to define used
networking interface on a host, e.g. 127.0.0.1.
- ipaddress IP address of SAT>IP server, e.g. 127.0.0.1.
- port (Optional) IP port number of SAT>IP server, e.g 443.
- model Model defines DVB modulation system (DVBS2,
DVBT2, DVBT, DVBC) and number of available
frontends separated by a hyphen, e.g. DVBT2-4.
- filter (Optional) Filter can be used to limit satellite frontends
to certain satellite position, e.g. S19.2E.
- description Friendly name of SAT>IP server. This is used
for autodetection of quirks.
- quirk (Optional) Quirks are non-standard compliant features and
bug fixes of SAT>IP server defined by a
hexadecimal number. Multiple quirks can be
defined by combining values by addition:

0x01: Fix session id bug
0x02: Fix play parameter (addpids/delpids) bug
0x04: Fix frontend locking bug
0x08: Support for RTP over TCP
0x10: Support the X_PMT protocol extension
0x20: Support the CI TNR protocol extension
0x40: Fix auto-detection of pilot tones bug
0x80: Fix re-tuning bug by teardowning a session

Examples:

The plugin accepts a "--portrange" (-p) command-line parameter, that can
be used to manually specify the RTP & RTCP port range and therefore
enables using the plugin through a NAT (e.g. Docker bridged network).
A minimum of 2 ports per device is required.

SAT>IP satellite positions (aka. signal sources) shall be defined via
sources.conf. If the source description begins with a number, it's used
as SAT>IP signal source selection parameter. A special number zero can
be used to disable the source. Otherwise, the default parameter is one:

S19.2E Astra 1KR/1L/1M/2C
=> Signal source = 1

S19.2E 2
=> Signal source = 2

S19.2E 3 Astra 1KR/1L/1M/2C
=> Signal source = 3

S19.2E 0 Astra 1KR/1L/1M/2C
=> Source is disabled

A channel can be assigned into a specific SAT>IP frontend by giving the
identifier number in RID field of a channels.conf entry:
FE = RID % 100
Valid range: 1 ... 99

Setup menu:

- Operating mode = off If you want exclude all SAT>IP devices
low from VDR's device handling, set this
normal option to "off". Otherwise, if you want
high to keep SAT>IP at a low priority when
selecting available devices, set this
option to "low". Similarly, the "high"
value prefers the SAT>IP over the local
DVB cards when selecting available devices.
- Use CI extension = no If you want to use the CI extension found
in some SAT>IP hardware (e.g. Digital
Devices OctopusNet), set this option to
"yes".
- CICAM #<slot> = <system> If you want to assign a CA system into
a specific CI slot, set this option to
a named one. Use "---" for autoselection.
- Enable EPG scanning = yes If you want exclude all SAT>IP devices
from VDR's EIT background scanning, set
this option to "no".
- Disabled sources = none If your SAT>IP servers don't have certain
satellite positions available you can
disable them via this option.
- Disabled filters = none Certain section filters might cause some
unwanted behaviour to VDR such as time
being falsely synchronized etc. This option
allows creation of blacklists of ill-behaving
filters. If this option is set to a non-zero
value, the menu page will contain that many
"Disable filter" options which allow you
to disable the individual section filters.
Valid range: "none" = 0 ... 7
- Transport mode = unicast If you want to use the non-standard
multicast RTP-over-TCP transport mode, set this option
rtp-o-tcp accordingly. Otherwise, the transport
mode will be RTP-over-UDP via unicast or
multicast.
- Enable frontend reuse = yes Certain devices might have artifacts if
multiple channels are assigned to the same
frontend. If you want to avoid such a
frontend assignment, set this option to "no".
- [Red:Scan] Forces network scanning of SAT>IP hardware.
- [Yellow:Devices] Opens SAT>IP device status menu.
- [Blue:Info] Opens SAT>IP information/statistics menu.
- [Ok] Opens information menu of selected SAT>IP
device.

Information menu:

- [Red:General] Opens the general information page.
- [Green:Pids] Opens the pid statistics page.
- [Yellow:Filters] Opens the section filter statistics page.
- [Blue:Bits/bytes] Toggles between bits and bytes mode.

Notes:

- If you are having problems receiving DVB-S2 channels, make sure your
channels.conf entry contains correct pilot tone setting.

- The stream id "-1" states about unsuccessful tuning. This might be a
result of invalid channel parameters or lack of free SAT>IP tuners.

- If the plugin doesn't detect your SAT>IP network device, make sure
your setup doesn't have firewalled the UDP port 1900.

- Stream decryption requires a separate CAM plugin that works without
direct access to any DVB card devices. Also the integrated CAM slots
in Octopus Net devices are supported.

- Tracing can be set on/off dynamically via command-line switch or
SVDRP command.

- OctopusNet firmware 1.0.40 or greater recommended.

- Inverto OEM firmware 1.17.0.120 or greater recommended.
The firmware 1.16.0.120 can be downloaded and installed
from their webpage: http://www.inverto.tv/support/
An update to a newer firmware should be offered afterwards.

- FRITZ!OS 7.00 or greater recommended for FRITZ!Box Cable devices.
Older firmware versions require both PlayPids and ForceLock quirks.

- If you are experiencing glitches in the video stream, one possible
reason can be buffer overflows in RTP receive sockets. You can verify
this by checking "receive buffer errors" counter by running "netstat -s"
command. If the counter increases every time a video glitch happens,
you should try to tweak the RTP receive buffer size with the "--rcvbuf"
(-r) plugin parameter.
A good starting point for the buffer size is to double the operating
system default value until errors disappear or the maximum value is
reached. You can check these values in Linux by checking the kernel
parameters:
$ cat /proc/sys/net/core/rmem_default
$ cat /proc/sys/net/core/rmem_max

Acknowledgements:

- Big thanks to Digital Devices GmbH for providing the Octopus Net
hardware for development!

vdr-plugin-satip's People

Contributors

Stargazers

Watchers

vdr-plugin-satip's Issues

satip-axe gets PID 65535/-1 from satip-plugin?

Hi Rolf,
since the satip-axe firmware on my Grundig GSS400 box always had issues after switching channels (streaming stopped) I've done some testing yesterday and fortunately perexg was able to fix it (please have a look at the comments made yesterday in this thread: perexg/satip-axe#108).

His latest release is a great improvement and stable so far (my VDR recorded permanently last night on different channels and I haven't had any new error!), but it may be helpful to have a look at a special behaviour.

In some situations the VDR satip plugin seems to send the PID 65535/-1 to the satip server what per se from my point of view is implausible:

 [17/10 12:07:23.999 main]: PLAY rtsp://192.168.0.141/stream=3?addpids=65535 RTSP/1.0

perexg's comment is more direct ;-) and he asked me to open an issue for vdr-plugin-satip.

You can find additional information and my logs in the issue thread mentioned above. Please let me know if you need further information!

Thanks for your effort!
Klaus

channel retune issue

I do have reduced the test to 2 channels, 1 good and a second bad (RTL7) channel.
If I switch back and for multiple times I end up with no picture on the good channel.

Das Erste HD;ARD:11493:HC23M5O35P0S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0
RTL7;CANALDIGITAAL:12343:hC34S0:S19.2E:27500:518+8190=2:90=dut@4:38:1817,100:2006:53:1097:0

vdr.log.gz

Feb 3 19:11:23 localhost minisatip[3710]: [03/02 19:11:23.490 main]: PLAY rtsp://192.168.178.129/stream=1?pids=5101,5102,5103,5105,5106 RTSP/1.0

Feb  3 19:11:15 localhost vdr: [27669] femon receiver thread started (pid=27576, tid=27669, prio=high)
Feb  3 19:11:15 localhost vdr: [27670] femon osd thread started (pid=27576, tid=27670, prio=high)
Feb  3 19:11:23 localhost vdr: [27580] SATIP-ERROR: Tuning timeout - retuning [device 0]
Feb  3 19:11:43 localhost vdr: [27580] SATIP-ERROR: Tuning timeout - retuning [device 0]
Feb  3 19:11:44 localhost vdr: [27670] femon osd thread ended (pid=27576, tid=27670)
Feb  3 19:11:44 localhost vdr: [27669] femon receiver thread ended (pid=27576, tid=27669)

this seem to be the point where it's going wrong, vdr satip did only request the pids for the good channel but there is no tune.

if I comment this line out, it works as expected.

vdr-plugin-satip/tuner.c

Line 226 in 826dea4

return true;

it's happen with minisatip and also with a IDL-400s aka Digibit R1 with original firmware
the issue also not limited to dvb-s it also happens with dvb-c

ERROR: SATIP poller thread

some time this error is logged when vdr is started, any idea?

Dec 24 12:06:09 localhost vdr: [11498] ERROR: SATIP poller thread 11501 won't end (waited 3 seconds) - canceling it...

MIS Support for Multistream Transponders dvbs

if you like you may add the change fro Yuri
https://toda.ro/forum/viewtopic.php?f=5&t=3&start=10

Handle ERROR 405 (Method Not Allowed)

Hi,

In the function "bool cSatipRtsp::ValidateLatestResponse(long *rcP)"
http://github.com/rofafor/vdr-plugin-satip/blob/4e9b6f11eb606398f366e0c9502b6e3f8db07a22/rtsp.c#L396
only responses 200 (OK) and 402/403/503 are processed.

However, several other relevant responses are not right catched!
For example, 405 (Method Not Allowed) is returned by the SAT>IP server when the current request can't be processed (now and after). This is true, for example, when the frequency is not supported. Some servers (like TVHE) use this behaviour as describes the standard.

So, please, can you add support for this response?

Damaged streams when channels in same bouquet

Hello! :-)

While playing or recording two channels from the same bouquet there are a lot artifacts.

Everything works very fine when the channels are in different bouquets, tested up to 6 HD streams. No problems at all.

Infos:

Selfsat IP36 (FW version 2.2.19, HW version 0.2)
-> Switch (DGS-1210-24)
-> VDR (Debian Buster), vdr-plugin-satip 2.4.0-1

# while starting VDR IP36 identified as:
SATIP: Adding server '192.168.178.39|DVBS2-8|SAT2IP->AS_B3S100_V2' Bind: default Filters: none CI: no Quirks: none

# Selfsat (from syslog):
Jan  1 00:00:06 kernel: DVB: registering new adapter (Abilis TB100 DVB framework)
Jan  1 00:00:11 kernel: MxLWare 2.1.1.7-RC100, F/W 2.1.1.7-RC100, chip MXL584, Id 1, Ver 2
Jan  1 00:00:11 kernel: tb100_adapter tb100-dvb-adapter0.8: DVB: registering adapter 7 frontend 0 (Hydra)...
Jan  1 00:00:12 kernel: tb100_adapter tb100-dvb-adapter0.8: LPU0, tb100_sp_fw V1.0 (Sep 12 2014 08:51:48)
Jan  1 00:00:12 kernel: DVB: registering new adapter (Abilis TB100 DVB framework)
...

# cat /proc/sys/net/core/rmem_default && cat /proc/sys/net/core/rmem_max
212992
212992

# vdr -V
vdr (2.4.0/2.4.0) - The Video Disk Recorder
satip (2.4.0) - SAT>IP Devices
vnsiserver (1.6.0) - VDR-Network-Streaming-Interface (VNSI) Server

# grep satip /var/lib/vdr/setup.conf 
satip.CICAM = 0 0
satip.DisabledFilters = 
satip.DisabledSources = 
satip.EnableCIExtension = 0
satip.EnableEITScan = 0
satip.OperatingMode = 3
satip.TransportMode = 0

# cat /etc/vdr/conf.d/50-satip.conf 
[satip]
-d 7
# tried quirks in different combinations, but no effekt at all:
-s 192.168.178.39|DVBS2-8|SAT2IP->AS_B3S100_V2|0x7f

# from channels.conf twochannels in same bouquet showing this effect:
KiKA HD;ZDFvision:11347:VC23M5O35P0S1:S19.2E:22000:6610=27:6620=deu@3,6621=mis@3;6622=deu@106:6630;6631=deu:0:11160:1:1010:0
3sat HD;ZDFvision:11347:VC23M5O35P0S1:S19.2E:22000:6510=27:6520=deu@3,6521=mis@3,6523=mul@3;6522=deu@106:6530;6531=deu:0:11150:1:1010:0

There is nothing in the logs which is relevant. What else can i do?

What do you think: problem exists in plugin or vdr?

Thanks a lot for your time and efforts.

New release?

The last release was tagged over 2 years ago and a few fixes were pushed to GIT in the mean time. Is there any plan when the next release will happen?

Recover from server crash

Test case:

Start minisatip and VDR using the latest git version of vdr-plugin-satip
simulate server crash by killing minisatip
restart minisatip
restart with 2. as often as necessary

Expected result:
VDR is operated and shows the currently tuned channel.

Observed behavior:
VDR shows only a still image and channel switch isn't working anymore. Only a restart of the VDR could help.

Logs from vdr-plugin-satip:

--- everything normal till the server dead and then

url_easy_perform() [rtsp.c,255] failed: Couldn't connect to server (7)
SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.178.20/ [device 0]
curl_easy_perform() [rtsp.c,255] failed: Couldn't connect to server (7)
SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.178.20/ [device 0]
curl_easy_perform() [rtsp.c,255] failed: Couldn't connect to server (7)
SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.178.20/ [device 0]
curl_easy_perform() [rtsp.c,255] failed: Timeout was reached (28)
SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.178.20/ [device 0]
curl_easy_perform() [rtsp.c,255] failed: Timeout was reached (28)

--- after restart of minisatip

SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.178.20/ [device 0]
curl_easy_perform() [rtsp.c,255] failed: Timeout was reached (28)
SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.178.20/ [device 0]
curl_easy_perform() [rtsp.c,255] failed: Timeout was reached (28)
SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.178.20/ [device 0]
curl_easy_perform() [rtsp.c,255] failed: Timeout was reached (28)
SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.178.20/ [device 0]
curl_easy_perform() [rtsp.c,255] failed: Timeout was reached (28)
SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.178.20/ [device 0]

Logs on the server side (minisatip) after the restart:

read RTSP (from handle 10 sock_id 5, len: 0, sid -1):
DESCRIBE rtsp://192.168.178.20/stream=2 RTSP/1.0
CSeq: 80
Session: 0846930886
Accept: application/sdp
User-Agent: vdr-satip/2.2.3-GIT-49e2dd1 (device 0)
If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT

reply -> 10 (192.168.178.20:47716) CL:0 :
RTSP/1.0 404 Not Found
Date: Mon, Aug 10 18:43:53 2015 GMT
Cseq: 80
Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN

It seems that the plugin only sends DESCRIBE for an already unknown stream and does not handle or retune or something else after getting the 404 response.

Option for DISABLE some server

Hi,

This plugin works well. Thank you for it!

However, in my setup I have different SAT>IP servers, and sometimes I don't like to use one of them. Please, can you add the option for DISABLE some specific server?

At time, I'm using the command line option -P 'satip -s 192.168.0.1|DVBS2-2' but this only "adds" the server, not force to use only the listed.

I hope you can implement this.
Regards!

TVHeadend support

What about support for
a) support for tvheadend sat>ip server
b) different rtsp port

a) sat>ip works perfekt with dvbviewer and elgato sat>ip
b) would be nice bec. e.g. tvh in usermode server runs on port 9983

Ciao gerd

MegaSat Sat2IP Server RTSP 400

Hey,
after running for a while (minutes to days), my syslog gets spammed with
May 11 07:04:25 Server vdr: [1853] SATIP-ERROR: Detected invalid status code 400: rtsp://192.168.0.150/ [device 0]
May 11 07:04:25 Server vdr: [1853] SATIP-ERROR: Connect failed [device 0]
After this I can not receive any shows any more. A restart of VDR recoveres the
error. The error is highly undeterministic, and I don't know what triggers it. I will
try to get a network dump of the communication between the SAT2IP server and
vdr on the weekend.
Do you got any idea what could cause this error ?
Greetings

Reoccuring RTP errors with Octopus NET S2 V1.1.5/1.1.6

Hi,
on my vdr headless server with yavdr-ansible (VDR 2.4.0 + vdr-plugin-satip) using SATP>IP only I determine many reoccuring RTP errors with my Octopus NET S2 (SAT>IP Server 1.1.5 and 1.1.6) when vdr server's EPG scan is enable. This also happens when the SATIP>IP only client is not beeing used.

Extract of /var/log/syslog:

...
Mar  1 09:44:56 vdr-server vdr: [9456] SATIP: Idle timeout - releasing [device 0]
Mar  1 09:45:08 vdr-server vdr: [9454] SATIP: Detected 1 RTP packet error [device 0]
Mar  1 09:55:47 vdr-server vdr: [9456] SATIP: Idle timeout - releasing [device 0]
Mar  1 09:55:59 vdr-server vdr: [9454] SATIP: Detected 1 RTP packet error [device 0]
Mar  1 10:06:38 vdr-server vdr: [9456] SATIP: Idle timeout - releasing [device 0]
Mar  1 10:06:50 vdr-server vdr: [9454] SATIP: Detected 1 RTP packet error [device 0]
...

VDR parameter for the vdr-plugin-satip is set to "-d 1";I am using it for the client as well to have a dedicated SATIP device for client and server.

Extract of the setup.conf:

egrep "^satip|^EPG" /var/lib/vdr/setup.conf 
EPGBugfixLevel = 3
EPGLanguages = 
EPGLinger = 120
EPGScanTimeout = 5
satip.CICAM = 0 0
satip.DisabledFilters = 
satip.DisabledSources = 
satip.EnableCIExtension = 0
satip.EnableEITScan = 1
satip.EnableFrontendReuse = 0
satip.OperatingMode = 2
satip.TransportMode = 0

This is the more detailed debug from the log:

Mar  1 10:06:38 vdr-server vdr: [9456] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsRelease to tsIdle [device 0]
Mar  1 10:06:50 vdr-server vdr: [9451] SATIP1: bool cSatipTuner::SetSource(cSatipServer*, int, const char*, int) (110773, src=1&freq=10773&pol=h&ro=0.20&msys=dvbs2&mtype=8psk&sr=22000&fec=34, 0) [device 0]
Mar  1 10:06:50 vdr-server vdr: [9451] SATIP1: cString cSatipRtsp::RtspUnescapeString(const char*) (192.168.178.19) [device 0]
Mar  1 10:06:50 vdr-server vdr: [9451] SATIP1: cString cSatipRtsp::RtspUnescapeString(const char*) (src=1&freq=10773&pol=h&ro=0.20&msys=dvbs2&mtype=8psk&sr=22000&fec=34) [device 0]
Mar  1 10:06:50 vdr-server vdr: [9451] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsSet, smExternal) current=tsIdle internal=0 external=0 [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsIdle to tsSet [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: bool cSatipTuner::Connect() [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: bool cSatipRtsp::SetInterface(const char*) () [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: bool cSatipRtsp::Options(const char*) (rtsp://192.168.178.19/) [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO   Trying 192.168.178.19...
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO TCP_NODELAY set
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connected to 192.168.178.19 (192.168.178.19) port 554 (#0)
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD >>>#012OPTIONS rtsp://192.168.178.19/ RTSP/1.0#015#012CSeq: 1#015#012User-Agent: vdr-satip/2.4.1 (device 0)
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTSP/1.0 200 OK
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< CSeq: 1
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<<
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connection #0 to host 192.168.178.19 left intact
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: bool cSatipRtsp::Setup(const char*, int, int, bool) (rtsp://192.168.178.19/?src=1&freq=10773&pol=h&ro=0.20&msys=dvbs2&mtype=8psk&sr=22000&fec=34, 43672, 43673, 0) [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Found bundle for host 192.168.178.19: 0x7fd18801ac00 [can pipeline]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Re-using existing connection! (#0) with host 192.168.178.19
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connected to 192.168.178.19 (192.168.178.19) port 554 (#0)
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD >>>#012SETUP rtsp://192.168.178.19/?src=1&freq=10773&pol=h&ro=0.20&msys=dvbs2&mtype=8psk&sr=22000&fec=34 RTSP/1.0#015#012CSeq: 2#015#012Transport: RTP/AVP;unicast;client_port=43672-43673#015#012User-Agent: vdr-satip/2.4.1 (device 0)
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTSP/1.0 200 OK
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< CSeq: 2
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Session: 1499150323;timeout=60
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Transport: RTP/AVP;unicast;client_port=43672-43673;server_port=8000-8001
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< com.ses.streamID: 1
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<<
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connection #0 to host 192.168.178.19 left intact
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: void cSatipRtsp::ParseHeader() [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: virtual void cSatipTuner::SetSessionTimeout(const char*, int) (1499150323, 60000) [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: virtual void cSatipTuner::SetupTransport(int, int, const char*, const char*) (43672, 43673, (null), (null)) [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: virtual void cSatipTuner::SetStreamId(int) (1) [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsTuned, smInternal) current=tsSet internal=0 external=0 [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: bool cSatipRtsp::Play(const char*) (rtsp://192.168.178.19/stream=1) [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Found bundle for host 192.168.178.19: 0x7fd18801ac00 [can pipeline]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Re-using existing connection! (#0) with host 192.168.178.19
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connected to 192.168.178.19 (192.168.178.19) port 554 (#0)
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD >>>#012PLAY rtsp://192.168.178.19/stream=1 RTSP/1.0#015#012CSeq: 3#015#012Session: 1499150323#015#012User-Agent: vdr-satip/2.4.1 (device 0)
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTSP/1.0 200 OK
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< CSeq: 3
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Session: 1499150323
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTP-Info: url=rtsp://192.168.178.19/stream=1 RTSP/1.0
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<<
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connection #0 to host 192.168.178.19 left intact
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsSet to tsTuned [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: bool cSatipRtsp::Describe(const char*) (rtsp://192.168.178.19/stream=1) [device 0]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Found bundle for host 192.168.178.19: 0x7fd18801ac00 [can pipeline]
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Re-using existing connection! (#0) with host 192.168.178.19
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connected to 192.168.178.19 (192.168.178.19) port 554 (#0)
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD >>>#012DESCRIBE rtsp://192.168.178.19/stream=1 RTSP/1.0#015#012CSeq: 4#015#012Session: 1499150323#015#012Accept: application/sdp#015#012User-Agent: vdr-satip/2.4.1 (device 0)
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTSP/1.0 200 OK
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< CSeq: 4
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Content-Type: application/sdp
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Content-Base: rtsp://192.168.178.19/
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Content-Length: 235
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<<
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP DATA <<< v=0#015#012o=- 5678901234 7890123456 IN IP4 192.168.178.19#015#012s=SatIPServer:1 2#015#012t=0 0#015#012m=video 0 RTP/AVP 33#015#012c=IN IP4 0.0.0.0#015#012a=control:stream=1#015#012a=fmtp:33 ver=1.0;src=1;tuner=1,0,0,0,10773,h,dvbs2,8psk,,0.20,22000,34;pids=none#015#012a=sendonly
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connection #0 to host 192.168.178.19 left intact
Mar  1 10:06:50 vdr-server vdr: [9456] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Mar  1 10:06:50 vdr-server vdr: [9454] SATIP: Detected 1 RTP packet error [device 0]

Help is very much appreciated. The issue sometimes leads to glitches in picture and audio on the receiving client and yet I do not know if it is OctopusNet or vdr-plugin-satip related.

Thanks,
Holger.

ClearQAM/ATSC support?

Is there support for ClearQAM/ATSC yet? If so, which delivery system shall be used?

I have a remote vdr with an attached ClearQAM tuner (Sundtek), that is also SAT>IP capable.
Using vdr with the locally attached tuner, "A" (for ATSC) is used as delivery system and this also works (more or less) with streamdev-server/streamdev-client to a remote vdr. However, since I really just need the remote tuner I would rather like to use it as SAT>IP remote tuner and use the satip on my main vdr.

Session times out on EXIP418 when timeout is equal to eMinKeepAliveIntervalMs

On my current installation of vdr-2.4.6 together with the satip plugin, it occured quite frequently, that a session timed out on HD channels. SD channels were mostly unaffected, although I had TS discontinuities now and then.
My Kathrein EXIP418 advertises a timeout of 30 seconds. The standard timeout (eMinKeepAliveIntervalMs) in satip is also 30 seconds.
Lowering the timeout by 10% and allowing a timeout less than eMinKeepAliveIntervalMs, resulted in steady uninterrupted streams.

This is the diff:

diff --git a/rtsp.c b/rtsp.c
index 63e6dfa..3b20461 100644
--- a/rtsp.c
+++ b/rtsp.c
@@ -433,7 +433,7 @@ void cSatipRtsp::ParseHeader(void)
            int timeout = -1;
            char *session = NULL;
            if (sscanf(r, "Session:%m[^;];timeout=%11d", &session, &timeout) == 2)
-              tunerM.SetSessionTimeout(skipspace(session), timeout * 1000);
+              tunerM.SetSessionTimeout(skipspace(session), timeout * 900); // 900 instead of 1000: lets keep the timeout 10% lower than advertised
            else if (sscanf(r, "Session:%m[^;]", &session) == 1)
               tunerM.SetSessionTimeout(skipspace(session), -1);
            FREE_POINTER(session);
diff --git a/tuner.c b/tuner.c
index cd8366b..21bc60c 100644
--- a/tuner.c
+++ b/tuner.c
@@ -392,7 +392,7 @@ void cSatipTuner::SetSessionTimeout(const char *sessionP, int timeoutP)
   sessionM = sessionP;
   if (nextServerM.IsQuirk(cSatipServer::eSatipQuirkSessionId) && !isempty(*sessionM) && startswith(*sessionM, "0"))
      rtspM.SetSession(SkipZeroes(*sessionM));
-  timeoutM = (timeoutP > eMinKeepAliveIntervalMs) ? timeoutP : eMinKeepAliveIntervalMs;
+  timeoutM = (timeoutP < eMinKeepAliveIntervalMs) ? timeoutP : eMinKeepAliveIntervalMs;
 }

 void cSatipTuner::SetupTransport(int rtpPortP, int rtcpPortP, const char *streamAddrP, const char *sourceAddrP)

I'd very much like to hear your thoughts on this.

Feature request: add option for RTP unicast over TCP

I have some problems in my network accessing my GSS.Box SAT>IP server. I know, I should by an OctopusNet but anyway I found out, that I get only distortions and artefacts if I access it via RTSP and if I use http:// (VLC or mplayer) the picture is perfect. Another trial with VLC and rtsp:// showed a perfect picture after I activated "RTP over RTSP (TCP)" in the preferences. A quick hack in rtsp.c adding "/TCP" to line 193 improved the picture quality a lot:
transport = cString::sprintf("RTP/AVP/TCP;unicast;client_port=%d-%d", rtpPortP, rtcpPortP);
So do you think it is possible to activate the TCP option via a command line switch? I think it could be useful also for other users.

Best regards,
Helge

Errorcode 453: SessionID destroyed on Triax Tss 400

There ist a SessionID transmitted from the TSS400 to my vdr-box (Session:35d6ea6d11692b;). But there is no space left between "Session:" and the sessionId. The sessionId is used later on but the first character of the sessionId is lost.

Getting sessionId
22:02:37.598248 IP bpi.fritz.box.48391 > TSS400-MKII.fritz.box.rtsp: Flags [P.], seq 91:358, ack 73, win 115, options [nop,nop,TS val 77521957 ecr 807105], length 267
0x0000: 4500 013f 4a47 4000 4006 69e6 c0a8 021c E..?JG@[email protected].....
0x0010: c0a8 021f bd07 022a 99a5 aec1 1938 73dd ............8s.
0x0020: 8018 0073 86bd 0000 0101 080a 049e e425 ...s...........%
0x0030: 000c 50c1 5345 5455 5020 7274 7370 3a2f ..P.SETUP.rtsp:/
0x0040: 2f31 3932 2e31 3638 2e32 2e33 312f 3f73 /192.168.2.31/?s
0x0050: 7263 3d31 2666 7265 713d 3130 3734 3326 rc=1&freq=10743&
0x0060: 706f 6c3d 6826 726f 3d30 2e33 3526 6d73 pol=h&ro=0.35&ms
0x0070: 7973 3d64 7662 7326 6d74 7970 653d 7170 ys=dvbs&mtype=qp
0x0080: 736b 2670 6c74 733d 6f66 6626 7372 3d32 sk&plts=off&sr=2
0x0090: 3230 3030 2666 6563 3d35 3620 5254 5350 2000&fec=56.RTSP
0x00a0: 2f31 2e30 0d0a 4353 6571 3a20 320d 0a54 /1.0..CSeq:.2..T
0x00b0: 7261 6e73 706f 7274 3a20 5254 502f 4156 ransport:.RTP/AV
0x00c0: 503b 756e 6963 6173 743b 636c 6965 6e74 P;unicast;client
0x00d0: 5f70 6f72 743d 3538 3630 302d 3538 3630 _port=58600-5860
0x00e0: 310d 0a55 7365 722d 4167 656e 743a 2076 1..User-Agent:.v
0x00f0: 6472 2d73 6174 6970 2f32 2e32 2e34 2028 dr-satip/2.2.4.(
0x0100: 6465 7669 6365 2030 290d 0a49 662d 4d6f device.0)..If-Mo
0x0110: 6469 6669 6564 2d53 696e 6365 3a20 5468 dified-Since:.Th
0x0120: 752c 2030 3120 4a61 6e20 3139 3730 2030 u,.01.Jan.1970.0
0x0130: 303a 3030 3a30 3020 474d 540d 0a0d 0a 0:00:00.GMT....
22:02:37.638902 IP TSS400-MKII.fritz.box.rtsp > bpi.fritz.box.48391: Flags [.], ack 358, win 243, options [nop,nop,TS val 807116 ecr 77521957], length 0
0x0000: 4500 0034 2356 4000 4006 91e2 c0a8 021f E..4#V@.@.......
0x0010: c0a8 021c 022a bd07 1938 73dd 99a5 afcc ........8s.....
0x0020: 8010 00f3 20e9 0000 0101 080a 000c 50cc ..............P.
0x0030: 049e e425 ...%
22:02:37.710663 IP TSS400-MKII.fritz.box.rtsp > bpi.fritz.box.48391: Flags [P.], seq 73:234, ack 358, win 243, options [nop,nop,TS val 807133 ecr 77521957], length 161
0x0000: 4500 00d5 2357 4000 4006 9140 c0a8 021f E...#W@.@..@....
0x0010: c0a8 021c 022a bd07 1938 73dd 99a5 afcc .....*...8s.....
0x0020: 8018 00f3 e686 0000 0101 080a 000c 50dd ..............P.
0x0030: 049e e425 5254 5350 2f31 2e30 2032 3030 ...%RTSP/1.0.200
0x0040: 204f 4b0d 0a53 6573 7369 6f6e 3a33 3564 .OK..Session:35d
0x0050: 3665 6136 6431 3136 3932 623b 7469 6d65 6ea6d11692b;time
0x0060: 6f75 743d 3330 0d0a 636f 6d2e 7365 732e out=30..com.ses.
0x0070: 7374 7265 616d 4944 3a33 3038 330d 0a54 streamID:3083..T
0x0080: 7261 6e73 706f 7274 3a52 5450 2f41 5650 ransport:RTP/AVP
0x0090: 3b75 6e69 6361 7374 3b64 6573 7469 6e61 ;unicast;destina
0x00a0: 7469 6f6e 3d31 3932 2e31 3638 2e32 2e32 tion=192.168.2.2
0x00b0: 383b 636c 6965 6e74 5f70 6f72 743d 3538 8;client_port=58
0x00c0: 3630 302d 3538 3630 310d 0a43 5365 713a 600-58601..CSeq:
0x00d0: 320d 0a0d 0a 2....

Reuse of sessionId without first character
22:02:37.711428 IP bpi.fritz.box.48391 > TSS400-MKII.fritz.box.rtsp: Flags [P.], seq 358:559, ack 234, win 123, options [nop,nop,TS val 77521969 ecr 807133], length 201
0x0000: 4500 00fd 4a48 4000 4006 6a27 c0a8 021c E...JH@[email protected]'....
0x0010: c0a8 021f bd07 022a 99a5 afcc 1938 747e ............8t~
0x0020: 8018 007b 867b 0000 0101 080a 049e e431 ...{.{.........1
0x0030: 000c 50dd 4445 5343 5249 4245 2072 7473 ..P.DESCRIBE.rts
0x0040: 703a 2f2f 3139 322e 3136 382e 322e 3331 p://192.168.2.31
0x0050: 2f73 7472 6561 6d3d 3330 3833 2052 5453 /stream=3083.RTS
0x0060: 502f 312e 300d 0a43 5365 713a 2033 0d0a P/1.0..CSeq:.3..
0x0070: 5365 7373 696f 6e3a 2035 6436 6561 3664 Session:.5d6ea6d
0x0080: 3131 3639 3262 0d0a 4163 6365 7074 3a20 11692b..Accept:.
0x0090: 6170 706c 6963 6174 696f 6e2f 7364 700d application/sdp.
0x00a0: 0a55 7365 722d 4167 656e 743a 2076 6472 .User-Agent:.vdr
0x00b0: 2d73 6174 6970 2f32 2e32 2e34 2028 6465 -satip/2.2.4.(de
0x00c0: 7669 6365 2030 290d 0a49 662d 4d6f 6469 vice.0)..If-Modi
0x00d0: 6669 6564 2d53 696e 6365 3a20 5468 752c fied-Since:.Thu,
0x00e0: 2030 3120 4a61 6e20 3139 3730 2030 303a .01.Jan.1970.00:
0x00f0: 3030 3a30 3020 474d 540d 0a0d 0a 00:00.GMT....
22:02:37.712356 IP TSS400-MKII.fritz.box.rtsp > bpi.fritz.box.48391: Flags [.], ack 559, win 260, options [nop,nop,TS val 807134 ecr 77521969], length 0
0x0000: 4500 0034 2358 4000 4006 91e0 c0a8 021f E..4#X@.@.......
0x0010: c0a8 021c 022a bd07 1938 747e 99a5 b095 ........8t~....
0x0020: 8010 0104 1f50 0000 0101 080a 000c 50de .....P........P.
0x0030: 049e e431 ...1
22:02:37.717798 IP TSS400-MKII.fritz.box.rtsp > bpi.fritz.box.48391: Flags [P.], seq 234:318, ack 559, win 260, options [nop,nop,TS val 807135 ecr 77521969], length 84
0x0000: 4500 0088 2359 4000 4006 918b c0a8 021f E...#Y@.@.......
0x0010: c0a8 021c 022a bd07 1938 747e 99a5 b095 .....*...8t~....
0x0020: 8018 0104 3d95 0000 0101 080a 000c 50df ....=.........P.
0x0030: 049e e431 5254 5350 2f31 2e30 2034 3534 ...1RTSP/1.0.454
0x0040: 2053 6573 7369 6f6e 204e 6f74 2046 6f75 .Session.Not.Fou
0x0050: 6e64 0d0a 4353 6571 3a33 0d0a 5365 7373 nd..CSeq:3..Sess
0x0060: 696f 6e3a 3564 3665 6136 6431 3136 3932 ion:5d6ea6d11692
0x0070: 620d 0a43 6f6e 7465 6e74 2d4c 656e 6774 b..Content-Lengt
0x0080: 683a 2030 0d0a 0d0a h:.0....

Each scrambled channel blocks 1 Device

Hi,
When recording scrambled channels and at the same time view a second scrambled channel on the same transponder 2 devices are occupied. The expected behaviour is that just PIDs are added to the existing device as it is the case for unscrambled channels, i.e. only one device per transponder.
I assume this is a feature somwere, maybe not even caused by satip. Any hints?
Cheers

Server gets removed if behind a NAT

Hi,
After the last enhancement it's possible to use the plugin behind a NAT, this works only for a a about 3 minutes. Then the manually added (via command-line) server is removed.

2016-01-09T12:10:24.751437+01:00 0a666b41677b vdr: [124] SATIP: Adding server '192.168.1.142|DVBC-4|Octo1' CI: no Quirks: none
...
2016-01-09T12:13:25.782311+01:00 0a666b41677b vdr: [143] SATIP: Removing server Octo1 (192.168.1.142 DVBC-4)

I suspect the cSatipServer::Update() is not called because the cSatipDiscover cannot detect any Satip-servers behind the NAT.
I would propose to disable the automatic cleanup for servers which are added via command-line parameter.

Plugin uses all available tuners of AVM Fritz! box when using wirbelscan

Even with -d 1 all available tuners are in use shortly when starting wirbelscan plugin.
It turns out that several connections are made without sending TEARDOWN. FritzOS dislikes this and will detect the disconnect only after a timeout of one minute.

Dec 26 18:18:14 hadron vdr: [20963] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsSet, smExternal) current=tsIdle internal=0 external=0 [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsIdle to tsSet [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipTuner::Connect() [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipRtsp::SetInterface(const char*) () [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipRtsp::Options(const char*) (rtsp://192.168.121.1/) [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipRtsp::Setup(const char*, int, int, bool) (rtsp://192.168.121.1/?freq=113&msys=dvbc&mtype=64qam&sr=6900&specinv=0, 56808, 56809, 0) [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: void cSatipRtsp::ParseHeader() [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: virtual void cSatipTuner::SetSessionTimeout(const char*, int) (2057, 60000) [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: virtual void cSatipTuner::SetupTransport(int, int, const char*, const char*) (56808, 56809, (null), (null)) [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: virtual void cSatipTuner::SetStreamId(int) (2057) [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsTuned, smInternal) current=tsSet internal=0 external=0 [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsSet to tsTuned [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipRtsp::Describe(const char*) (rtsp://192.168.121.1/stream=2057) [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsLocked, smInternal) current=tsTuned internal=0 external=0 [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsTuned to tsLocked [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipRtsp::Receive(const char*) (rtsp://192.168.121.1/) [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipRtsp::Receive(const char*) (rtsp://192.168.121.1/) [device 0]
Dec 26 18:18:14 hadron vdr: [20903] SATIP1: bool cSatipRtsp::Receive(const char*) (rtsp://192.168.121.1/) [device 0]
Dec 26 18:18:15 hadron vdr: [20903] SATIP1: bool cSatipRtsp::Play(const char*) (rtsp://192.168.121.1/stream=2057?addpids=18) [device 0]
Dec 26 18:18:15 hadron vdr: [20903] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=failed [device 0]
Dec 26 18:18:15 hadron vdr: [20903] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsSet, smInternal) current=tsLocked internal=0 external=0 [device 0]
Dec 26 18:18:15 hadron vdr: [20903] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsLocked to tsSet [device 0]
Dec 26 18:18:15 hadron vdr: [20903] SATIP1: bool cSatipTuner::Connect() [device 0]
Dec 26 18:18:15 hadron vdr: [20903] SATIP1: bool cSatipTuner::Connect() Retuning [device 0]
Dec 26 18:18:15 hadron vdr: [20903] SATIP1: bool cSatipRtsp::Play(const char*) (rtsp://192.168.121.1/stream=2057?freq=113&msys=dvbc&mtype=64qam&sr=6900&specinv=0) [device 0]

missing quirk for Inverto IDL-400s

the "Inverto IDL-400s" which is the same hardware and software as the DIGIBIT/GSS is not handled yet, so adding it would be great for the owners with original firmware.
it shows up as "Multibox-030227:SAT>IP" but the number may unique.

./detectsatip.py 
[
  {
    "frontends": {
      "DVBC": 1
    }, 
    "name": "43CX750_Series"
  }, 
  {
    "frontends": {
      "DVBC2": 2, 
      "DVBS2": 4, 
      "DVBT2": 2
    }, 
    "name": "minisatip"
  }, 
  {
    "frontends": {
      "DVBC": 4
    }, 
    "name": "FRITZ!Box 6490 Cable"
  }, 
  {
    "frontends": {
      "DVBS2": 4
    }, 
    "name": "Multibox-030227:SAT>IP"
  }

in the mean time adding it like "--server=192.168.178.115|DVBS2-4|DIGIBIT" works also

PMT pid is added/deleted continuously

Hi,
After having issues with streaming to VLC from the streamdev-server, I detected that not all PMTs are received by cStreamdevLiveReceiver::Receive().

This happens both when receiving DVB-S from minisatip and DVB-C from OctopusNET. When locking at the RTSP requests comming from vdr-plugin-satip, there are continuous addpids/delpids with the PMT PID of the streamed channel. This happens for both scrambled and unscrambled channels.

Here an example from "Das Erste HD" with PMT PID 5100. The PID is added/removed several times per second:

No.     Time           Arrival Time       Source                Destination           Protocol Length Info
      4 0.132521       17:05:46.451647    10.76.1.1             10.76.1.1             RTSP     219    PLAY rtsp://10.76.1.1/stream=4?addpids=5100&delpids=5130 RTSP/1.0
     10 0.604172       17:05:46.923298    10.76.1.1             10.76.1.1             RTSP     219    PLAY rtsp://10.76.1.1/stream=4?addpids=5110&delpids=5100 RTSP/1.0
     34 1.962518       17:05:48.281644    10.76.1.1             10.76.1.1             RTSP     219    PLAY rtsp://10.76.1.1/stream=4?addpids=5100&delpids=5130 RTSP/1.0
     43 2.445167       17:05:48.764293    10.76.1.1             10.76.1.1             RTSP     219    PLAY rtsp://10.76.1.1/stream=4?addpids=5110&delpids=5100 RTSP/1.0
     61 3.722960       17:05:50.042086    10.76.1.1             10.76.1.1             RTSP     219    PLAY rtsp://10.76.1.1/stream=4?addpids=5100&delpids=5130 RTSP/1.0
     70 4.186928       17:05:50.506054    10.76.1.1             10.76.1.1             RTSP     219    PLAY rtsp://10.76.1.1/stream=4?addpids=5110&delpids=5100 RTSP/1.0
     94 5.537540       17:05:51.856666    10.76.1.1             10.76.1.1             RTSP     219    PLAY rtsp://10.76.1.1/stream=4?addpids=5100&delpids=5130 RTSP/1.0
    103 6.011867       17:05:52.330993    10.76.1.1             10.76.1.1             RTSP     219    PLAY rtsp://10.76.1.1/stream=4?addpids=5110&delpids=5100 RTSP/1.0
    124 7.395202       17:05:53.714328    10.76.1.1             10.76.1.1             RTSP     219    PLAY rtsp://10.76.1.1/stream=4?addpids=5100&delpids=5130 RTSP/1.0
    130 7.859299       17:05:54.178425    10.76.1.1             10.76.1.1             RTSP     219    PLAY rtsp://10.76.1.1/stream=4?addpids=5110&delpids=5100 RTSP/1.0
    151 9.148314       17:05:55.467440    10.76.1.1             10.76.1.1             RTSP     219    PLAY rtsp://10.76.1.1/stream=4?addpids=5100&delpids=5130 RTSP/1.0
    157 9.622293       17:05:55.941419    10.76.1.1             10.76.1.1             RTSP     219    PLAY rtsp://10.76.1.1/stream=4?addpids=5110&delpids=5100 RTSP/1.0

What is the reason for this continuous addpids/delpids requests? BTW: its the vdr-2.2.0 branch.

README/log improvements: list names of supported devices ("description"), quirks, ...

If SATIP automatically finds the SATIP hardware via Upnp then user gets this:
SATIP: Adding server 'a.b.x.y|DVBS2-2|OctopusNet' Bind: default Filters: none CI: yes Quirks: CiXpmt

However, there is a problem with this part:
"The plugin accepts also a "--server" (-s) command-line parameter, that can be used to manually configure static SAT>IP servers if autodetection via UPnP somehow can't be used..." ... "||"

The word "description" indicates "any name you like". It does not tell the user that a from a specific list (in server.c) needs to be used. Just by accident I searched the repo for OctopusNet and then found what this actually does in server.c...

As a result, using a "description" of "DD" (which I initially used) results in:
SATIP: Adding server 'a.b.x.y|DVBS2-2|DD' Bind: default Filters: none CI: no Quirks: none

On the other hand, using "description" of "OctopusNet" results in:
SATIP: Adding server 'a.b.x.y|DVBS2-2|OctopusNet' Bind: default Filters: none CI: yes Quirks: CiXpmt

And is "model" the right name to specify the type of "tuner" used by the SATIP hardware? Model sounds more like an actual SATIP hardware "model"?

Improvement suggestions:

Change the word "description" to "device name"
Change the word "model" to "tuner"
List the possible "device names" as specified in server.c in the README and also output them in the vdr help output
List the possible "quirks" that can be specified / are used for each device name (could help users with similar hardware which is just not (yet) supported by satip plugin)
Add info in the log about the device being used: "SATIP: Adding server 'a.b.x.y|DVBS2-2|...' Device: OctopusNet/.../unknown Bind: ... Filters: .../unknown CI: .../unknown Quirks: .../unknown"

compile warning

with gcc version 7.3.0 (Ubuntu 7.3.0-5ubuntu1) this warning is showing up

g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"satip"' -DGITVERSION='"-GIT-0a15717"'  -o param.o param.c
param.c: In function ‘cString GetTransponderUrlParameters(const cChannel*)’:
param.c:159:15: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
 #define ST(s) if (strchr(s, type) && (strchr(s, '0' + dtp.System() + 1) || strchr(s, '*')))
               ^
param.c:168:6: note: in expansion of macro ‘ST’
      ST(" S *") q += snprintf(q,       STBUFLEFT, "src=%d&",          ((src > 0) && (src <= 255)) ? src : 1);
      ^~
param.c:169:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
                 q += snprintf(q,       STBUFLEFT, "freq=%s",          *dtoa(freq, "%lg"));
                 ^
CC poller.o

SATIP-ERROR: invalid status code 454

Hello
I am trying to use this VDR plugin but I am having issues.
Please, see the log below:

Sep 16 12:01:10 Media vdr: [30749] SATIP: Adding server '192.168.0.18|DVBS2-4|Schwaiger Sat>IP Server' CI: no Quirks: none
Sep 16 12:01:18 Media vdr: [30736] switching to channel 1 (CT1)
Sep 16 12:01:18 Media vdr: [30736] OSD size changed to 720x480 @ 1
Sep 16 12:01:18 Media vdr: [30736] ERROR: no OSD provider available - using dummy OSD!
Sep 16 12:01:19 Media vdr: [30750] curl_easy_perform() [rtsp.c,255] failed: RTSP session error (86)
Sep 16 12:01:19 Media vdr: [30750] SATIP-ERROR: Detected invalid status code 454: rtsp://192.168.0.18/ [device 0]
Sep 16 12:01:20 Media vdr: [30750] curl_easy_perform() [rtsp.c,255] failed: RTSP session error (86)
Sep 16 12:01:20 Media vdr: [30750] SATIP-ERROR: Detected invalid status code 454: rtsp://192.168.0.18/ [device 0]
Sep 16 12:01:21 Media vdr: [30750] curl_easy_perform() [rtsp.c,255] failed: RTSP session error (86)
Sep 16 12:01:21 Media vdr: [30750] SATIP-ERROR: Detected invalid status code 454: rtsp://192.168.0.18/ [device 0]

Can we please troubleshoot this issue? I have tried with 2.2.2 and 2.3.1 and it is the same
Will you please help me to get this working?

Running on Ubuntu 14.04 and VDR 2.2.0

Thank you,
Jakub

satip channel switching issuse

I ran a vdr-2.3.8 server with vnsiserver newest Git. Clients are
libreelec newest git. Both software is self compiled. The channels are supplied
by DVB-C devices and Sat channels by an satip server via VDR-PLUGIN-SATIP.
Everythings works generally.

But i have the following issue:
start streaming a satip supplied channel works. Switching from a streaming channel to an other
satip supplied channel does not work, see attached log:

Aug 24 11:08:53 vnas1 vdr[6706]: [8278] VNSI: Welcome client 'XBMC Media Center' with protocol version '11'
Aug 24 11:08:53 vnas1 vdr[6706]: [8278] VNSI: LiveStreamer::Close - close
Aug 24 11:08:53 vnas1 vdr[6706]: [8278] VNSI: close video input ...
Aug 24 11:08:53 vnas1 vdr[6706]: [8278] VNSI: Successfully found following device: 0x13f9ea0 (3) for receiving, priority=0
Aug 24 11:08:53 vnas1 vdr[6706]: [8278] VNSI: Dummy receiver (0x7ff59c0a6290) activated
Aug 24 11:08:53 vnas1 vdr[6706]: [8278] VNSI: activate live receiver: 1
Aug 24 11:08:53 vnas1 vdr[6706]: [8278] VNSI: Successfully switched to channel 1 - Das Erste HD
Aug 24 11:08:53 vnas1 vdr[6706]: [8278] VNSI: Started streaming of channel Das Erste HD (timeout 14 seconds)
Aug 24 11:08:53 vnas1 vdr[6706]: [6715] SATIP: Detected 4 RTP packet errors [device 0]
Aug 24 11:08:53 vnas1 vdr[6706]: [8280] VNSI: Created stream for pid=5101 and type=8
Aug 24 11:08:53 vnas1 vdr[6706]: [8280] VNSI: Created stream for pid=5106 and type=1
Aug 24 11:08:53 vnas1 vdr[6706]: [8280] VNSI: Created stream for pid=5102 and type=2
Aug 24 11:08:53 vnas1 vdr[6706]: [8280] VNSI: Created stream for pid=5103 and type=2
Aug 24 11:08:53 vnas1 vdr[6706]: [8280] VNSI: Created stream for pid=5105 and type=10
Aug 24 11:08:53 vnas1 vdr[6706]: [8280] VNSI: Created stream for pid=5104 and type=12
Aug 24 11:08:53 vnas1 vdr[6706]: [8280] VNSI: Audio stream change, pid: 5106, channels: 2, samplerate: 48000
Aug 24 11:08:53 vnas1 vdr[6706]: [8280] VNSI: Audio stream change, pid: 5102, channels: 2, samplerate: 48000
Aug 24 11:08:53 vnas1 vdr[6706]: [8280] VNSI: Audio stream change, pid: 5103, channels: 2, samplerate: 48000
Aug 24 11:08:54 vnas1 vdr[6706]: [6706] ERROR: no OSD provider available - using dummy OSD!
Aug 24 11:08:54 vnas1 vdr[6706]: [8280] VNSI: Video stream change, pid: 5101, width: 1280, height: 720, aspect: 1,777778
Aug 24 11:09:12 vnas1 vdr[6706]: [6723] SATIP: Idle timeout - releasing [device 2]
Aug 24 11:09:19 vnas1 vdr[6706]: [8280] VNSI: exit streamer thread
Aug 24 11:09:19 vnas1 vdr[6706]: [8278] VNSI: LiveStreamer::Close - close
Aug 24 11:09:19 vnas1 vdr[6706]: [8278] VNSI: close video input ...
Aug 24 11:09:19 vnas1 vdr[6706]: [8278] VNSI: activate live receiver: 0
Aug 24 11:09:19 vnas1 vdr[6706]: [8278] VNSI: Dummy receiver (0x7ff59c0a6290) deactivated
Aug 24 11:09:19 vnas1 vdr[6706]: [8278] VNSI: close video input ...
Aug 24 11:09:19 vnas1 vdr[6706]: [8278] VNSI: LiveStreamer::Close - close
Aug 24 11:09:19 vnas1 vdr[6706]: [8278] VNSI: close video input ...
Aug 24 11:09:19 vnas1 vdr[6706]: [8278] VNSI: Successfully found following device: 0x13f9ea0 (3) for receiving, priority=0
Aug 24 11:09:19 vnas1 vdr[6706]: [8278] VNSI: Dummy receiver (0x7ff59c0a6290) activated
Aug 24 11:09:19 vnas1 vdr[6706]: [8278] VNSI: activate live receiver: 1
Aug 24 11:09:19 vnas1 vdr[6706]: [8278] VNSI: Successfully switched to channel 2 - ZDF HD
Aug 24 11:09:19 vnas1 vdr[6706]: [8278] VNSI: Started streaming of channel ZDF HD (timeout 14 seconds)
Aug 24 11:09:20 vnas1 vdr[6706]: [6706] ERROR: no OSD provider available - using dummy OSD!
Aug 24 11:09:33 vnas1 vdr[6706]: [8285] VNSI: Channel: no data 16
Aug 24 11:09:47 vnas1 vdr[6706]: [8285] VNSI: Channel: no data 16
Aug 24 11:10:01 vnas1 vdr[6706]: [8285] VNSI: Channel: no data 16
Aug 24 11:10:15 vnas1 vdr[6706]: [8285] VNSI: Channel: no data 16
Aug 24 11:10:15 vnas1 vdr[6706]: [8285] VNSI: exit streamer thread
Aug 24 11:10:15 vnas1 vdr[6706]: [8278] VNSI: LiveStreamer::Close - close
Aug 24 11:10:15 vnas1 vdr[6706]: [8278] VNSI: close video input ...
Aug 24 11:10:15 vnas1 vdr[6706]: [8278] VNSI: activate live receiver: 0
Aug 24 11:10:15 vnas1 vdr[6706]: [8278] VNSI: Dummy receiver (0x7ff59c0a6290) deactivated
Aug 24 11:10:15 vnas1 vdr[6706]: [8278] VNSI: close video input ...
Aug 24 11:10:15 vnas1 vdr[6706]: [8278] VNSI: cxSocket::read(fd=58): eof, connection closed
Aug 24 11:10:15 vnas1 vdr[6706]: [6737] VNSI: Client with ID 24 seems to be disconnected, removing from client list

Switching streaming channels from DVB-C devices does Work with no Problems.
in the following Log start satip Channel (ARD) then switch to DVB-C (TNT-Comedy) and then to DVB-C /Syfy) works as it should:

Aug 24 11:48:06 vnas1 vdr[6706]: [8426] VNSI: Successfully found following device: 0x13f9ea0 (3) for receiving, priority=0
Aug 24 11:48:06 vnas1 vdr[6706]: [8426] VNSI: Dummy receiver (0x7ff530004e70) activated
Aug 24 11:48:06 vnas1 vdr[6706]: [8426] VNSI: activate live receiver: 1
Aug 24 11:48:06 vnas1 vdr[6706]: [8426] VNSI: Successfully switched to channel 1 - Das Erste HD
Aug 24 11:48:06 vnas1 vdr[6706]: [8426] VNSI: Started streaming of channel Das Erste HD (timeout 14 seconds)
Aug 24 11:48:06 vnas1 vdr[6706]: [8428] VNSI: Created stream for pid=5101 and type=8
Aug 24 11:48:06 vnas1 vdr[6706]: [8428] VNSI: Created stream for pid=5106 and type=1
Aug 24 11:48:06 vnas1 vdr[6706]: [8428] VNSI: Created stream for pid=5102 and type=2
Aug 24 11:48:06 vnas1 vdr[6706]: [8428] VNSI: Created stream for pid=5103 and type=2
Aug 24 11:48:06 vnas1 vdr[6706]: [8428] VNSI: Created stream for pid=5105 and type=10
Aug 24 11:48:06 vnas1 vdr[6706]: [8428] VNSI: Created stream for pid=5104 and type=12
Aug 24 11:48:06 vnas1 vdr[6706]: [8428] VNSI: Audio stream change, pid: 5102, channels: 2, samplerate: 48000
Aug 24 11:48:06 vnas1 vdr[6706]: [8428] VNSI: Audio stream change, pid: 5103, channels: 2, samplerate: 48000
Aug 24 11:48:06 vnas1 vdr[6706]: [8428] VNSI: Audio stream change, pid: 5106, channels: 2, samplerate: 48000
Aug 24 11:48:07 vnas1 vdr[6706]: [8428] VNSI: Video stream change, pid: 5101, width: 1280, height: 720, aspect: 1,777778
Aug 24 11:48:14 vnas1 vdr[6706]: [8428] VNSI: exit streamer thread
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] VNSI: LiveStreamer::Close - close
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] VNSI: close video input ...
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] VNSI: activate live receiver: 0
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] VNSI: Dummy receiver (0x7ff530004e70) deactivated
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] VNSI: close video input ...
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] VNSI: LiveStreamer::Close - close
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] VNSI: close video input ...
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] VNSI: Successfully found following device: 0x13cb4b0 (1) for receiving, priority=0
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] dvb tuner: power-up - opening frontend 0/0
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] VNSI: Dummy receiver (0x7ff5300a31c0) activated
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] VNSI: activate live receiver: 1
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] DVBAPI: 0.0 set CAM decrypt (SID 38102 (0x94D6), caLm 4, HasCaDescriptors 0)
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] VNSI: Successfully switched to channel 27 - TNT Comedy HD
Aug 24 11:48:14 vnas1 vdr[6706]: [8426] VNSI: Started streaming of channel TNT Comedy HD (timeout 14 seconds)
Aug 24 11:48:15 vnas1 vdr[6706]: [8432] VNSI: Created stream for pid=523 and type=8
Aug 24 11:48:15 vnas1 vdr[6706]: [8432] VNSI: Created stream for pid=524 and type=1
Aug 24 11:48:15 vnas1 vdr[6706]: [8432] VNSI: Created stream for pid=525 and type=2
Aug 24 11:48:15 vnas1 vdr[6706]: [8432] VNSI: Created stream for pid=526 and type=2
Aug 24 11:48:15 vnas1 vdr[6706]: [6706] ERROR: no OSD provider available - using dummy OSD!
Aug 24 11:48:16 vnas1 vdr[6706]: [6737] VNSI: Requesting clients to reload channel list
Aug 24 11:48:16 vnas1 vdr[6706]: [6706] VNSI: re-tune to channel TNT Comedy HD
Aug 24 11:48:16 vnas1 vdr[6706]: [8432] VNSI: re-tuning...
Aug 24 11:48:16 vnas1 vdr[6706]: [8432] VNSI: close video input ...
Aug 24 11:48:16 vnas1 vdr[6706]: [8432] VNSI: activate live receiver: 0
Aug 24 11:48:16 vnas1 vdr[6706]: [8432] VNSI: Dummy receiver (0x7ff5300a31c0) deactivated
Aug 24 11:48:16 vnas1 vdr[6706]: [8432] VNSI: Successfully found following device: 0x13cb4b0 (1) for receiving, priority=0
Aug 24 11:48:16 vnas1 vdr[6706]: [8432] VNSI: Dummy receiver (0x7ff59c0a6400) activated
Aug 24 11:48:16 vnas1 vdr[6706]: [8432] VNSI: activate live receiver: 1
Aug 24 11:48:16 vnas1 vdr[6706]: [8432] DVBAPI: 0.0 set CAM decrypt (SID 38102 (0x94D6), caLm 4, HasCaDescriptors 1)
Aug 24 11:48:17 vnas1 vdr[6706]: [8432] VNSI: Audio stream change, pid: 524, channels: 6, samplerate: 48000
Aug 24 11:48:17 vnas1 vdr[6706]: [8432] VNSI: Audio stream change, pid: 526, channels: 2, samplerate: 48000
Aug 24 11:48:17 vnas1 vdr[6706]: [8432] VNSI: Audio stream change, pid: 525, channels: 2, samplerate: 48000
Aug 24 11:48:17 vnas1 vdr[6706]: [8432] VNSI: Video stream change, pid: 523, width: 1920, height: 1080, aspect: 1,777778
Aug 24 11:48:21 vnas1 vdr[6706]: [6737] VNSI: Requesting clients to reload channel list
Aug 24 11:48:23 vnas1 vdr[6706]: [8432] VNSI: exit streamer thread
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] VNSI: LiveStreamer::Close - close
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] VNSI: close video input ...
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] VNSI: activate live receiver: 0
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] VNSI: Dummy receiver (0x7ff59c0a6400) deactivated
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] VNSI: close video input ...
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] VNSI: LiveStreamer::Close - close
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] VNSI: close video input ...
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] VNSI: Successfully found following device: 0x13cb4b0 (1) for receiving, priority=0
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] VNSI: Dummy receiver (0x7ff530013460) activated
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] VNSI: activate live receiver: 1
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] DVBAPI: 0.0 set CAM decrypt (SID 27114 (0x69EA), caLm 4, HasCaDescriptors 1)
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] VNSI: Successfully switched to channel 28 - SyFy HD
Aug 24 11:48:23 vnas1 vdr[6706]: [8426] VNSI: Started streaming of channel SyFy HD (timeout 14 seconds)
Aug 24 11:48:23 vnas1 vdr[6706]: [8449] VNSI: Created stream for pid=543 and type=8
Aug 24 11:48:23 vnas1 vdr[6706]: [8449] VNSI: Created stream for pid=544 and type=1
Aug 24 11:48:23 vnas1 vdr[6706]: [8449] VNSI: Created stream for pid=545 and type=1
Aug 24 11:48:23 vnas1 vdr[6706]: [6706] ERROR: no OSD provider available - using dummy OSD!
Aug 24 11:48:24 vnas1 vdr[6706]: [8449] VNSI: Audio stream change, pid: 544, channels: 6, samplerate: 48000
Aug 24 11:48:24 vnas1 vdr[6706]: [8449] VNSI: Audio stream change, pid: 545, channels: 2, samplerate: 48000
Aug 24 11:48:24 vnas1 vdr[6706]: [8449] VNSI: Video stream change, pid: 543, width: 1920, height: 1080, aspect: 1,777778
Aug 24 11:48:33 vnas1 vdr[6706]: [8449] VNSI: exit streamer thread
Aug 24 11:48:33 vnas1 vdr[6706]: [8426] VNSI: LiveStreamer::Close - close
Aug 24 11:48:33 vnas1 vdr[6706]: [8426] VNSI: close video input ...
Aug 24 11:48:33 vnas1 vdr[6706]: [8426] VNSI: activate live receiver: 0
Aug 24 11:48:33 vnas1 vdr[6706]: [8426] VNSI: Dummy receiver (0x7ff530013460) deactivated
Aug 24 11:48:33 vnas1 vdr[6706]: [8426] VNSI: close video input ...
Aug 24 11:48:33 vnas1 vdr[6706]: [8426] VNSI: cxSocket::read(fd=40): eof, connection closed
Aug 24 11:48:33 vnas1 vdr[6706]: [6737] VNSI: Client with ID 32 seems to be disconnected, removing from client list

Its annoying that for SATIP Channels the stream has to bee stopped and then
the switched channel to be started.

The satip server has 8 Tuners and the Plugin is started with -d 8.

Any Idea for the cause of this?

best regards

Multiple OctopusNet servers with source-filtering - wrong server selection for devices

I'm using two OctopusNet servers with the new source-filtering feature with the following configuration:

--devices=8
--server=192.168.1.21|DVBS2-4:S19.2E|OctopusNet;192.168.1.20|DVBS2-2,DVBT2-2:S28.2E,T|OctopusNet

I'm having a problem when VDR starts its channel- and EPG-scan. VDR wants to start a scan with 8 Frontends in parallel and the satip-plugin tries to request all these device to the same server and I'm getting the following burst errors (this is an extract):

Jul 31 10:07:46 vdr vdr: [6619] SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.1.21/ [device 5]
Jul 31 10:07:46 vdr vdr: [6619] SATIP-ERROR: Connect failed [device 5]
Jul 31 10:07:46 vdr vdr: [6622] SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.1.21/ [device 6]
Jul 31 10:07:46 vdr vdr: [6622] SATIP-ERROR: Connect failed [device 6]
Jul 31 10:07:46 vdr vdr: [6616] SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.1.21/ [device 4]
Jul 31 10:07:46 vdr vdr: [6616] SATIP-ERROR: Connect failed [device 4]
Jul 31 10:07:46 vdr vdr: [6610] SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.1.21/ [device 2]

At the same time I see that on this OctopusNet-server (192.168.1.21) all four inputs are already tuned.

I'm using VDR 2.2.0 and the following OctopusNet firmware release:

FW Date 30 Jul 2016 18:44
MAC 54:84:7b:00:1f:c2
Linux   3.17.7 armv5tejl
SAT>IP Server   1.0.71
FPGA    300-0.46
Boot ID 9
Device ID   5

curl_easy_setopt(CURLOPT_MAX_RECV_SPEED_LARGE, eMaxDownloadSpeedMBits * 131072L) [rtsp.c,168] failed: A libcurl function was given a bad argument (43)

I could resolve a lot of issues of my Debian Testing/VDR 2.3.8 system step by step this week but one message didn't go away:

curl_easy_setopt(CURLOPT_MAX_RECV_SPEED_LARGE, eMaxDownloadSpeedMBits * 131072L)
[rtsp.c,168] failed: A libcurl function was given a bad argument (43)

Hopefully solved it by compiling your latest satip code plus changing rtsp.c line 168
from: SATIP_CURL_EASY_SETOPT(handleM, CURLOPT_MAX_RECV_SPEED_LARGE, eMaxDownloadSpeedMBits * 131072L);
to: SATIP_CURL_EASY_SETOPT(handleM, CURLOPT_MAX_RECV_SPEED_LARGE, (curl_off_t)(eMaxDownloadSpeedMBits * 1048576));

Speed may be a little bit high (20MByte versus 8-10MBytes HD streams) but so far I had no error messages. One group of messages (user.log) shows that the value may be to high:

recordingaction: executing /usr/share/vdr/recording-hooks/R90.custom as shell script
[2658] channel 161 (Das Erste HD) event Tue 13.02.2018 09:20-11:00 (VPS: 13.02. 09:20) 'Sportschau - Olympia Pyeongchang 2018' status 4
[2695] i/o throttle activated, count = 1 (tid=2695)
[2695] buffer usage: 70% (tid=2694)
[2695] buffer usage: 80% (tid=2694)
[2695] buffer usage: 60% (tid=2694)
[2695] i/o throttle released, count = 0 (tid=2695)

It appeared only one time directly after starting the recording of a HD channel. Maybe I'll decrease the value a little bit but currently I'm not experiencing package losses.

Klaus

Reception Issues

I am using Debian Stable (Stretch) with latest updates and a manual compiled Vanila VDR 2.3.8 with the current GIT Version of vdr-plugin-satip.
SAT>IP Server is a "Telestar DIGIBIT R1" with the current satip-axe Firmware. (I also tried an older version of satip-axe and the stock firmware of the receiver)
My configuration already worked with older software versions. (I had VDR 2.2 with an older vdr-plugin-satip verision and an older satip-axe version)

Using this configuration I currenly can't get stable TV picture or sound (a lot of artefacts).
Using the Android App "tivizen" I get a stable picture and sound, so I dont think its an major issue on my SAT>IP Server. (Using an android phone over an access point in the same network as my VDR Server.)

VDR Logging is attached:
VDR log.txt

The first block of the log is the start of the VDR with minimum plugins (satip & vnsiserver) which returns already the first SATIP-ERRORs
The second block of the log is starting KODI (as client) and switching to an channel which return even more SATIP-ERRORs.

I already tried older versions of vdr-plugin-satip but had no success so far.
I also tried smarttvplugin as output plugin (instead of vnsiserver) but I had the same problem.

Can you give me any advice how I can identify the issue?

rtp-over-tcp doesn't work with minisatip

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]

HUMAX Digital UHD 4tune+ - SATIP-ERROR: Detected invalid status code 454

Hi,

every now and again, usually every 10 to 30 minutes, I get a short loss of picture or scramble when watching TV with the satip plugin. When that happens it always seems to coincide with a "SATIP-ERROR: Detected invalid status code 454", immediately followed by "SATIP-ERROR: Connect failed [device 0]" and then "SATIP: Detected 1 RTP packet errors [device 0]"

This happens with HD, as well as SD free-to-air channels.

My system journal says this with satip trac 0x12 enabled. I hope the excerpt is enough.

Sep 22 23:41:48 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTSP/1.0 200 OK
Sep 22 23:41:48 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Date: Thu, 22 Sep 2016 21:41:48 GMT
Sep 22 23:41:48 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Session: 1D6AB6B4
Sep 22 23:41:48 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< CSeq: 1007
Sep 22 23:41:48 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTP-Info: url=rtsp://10.0.0.2/stream=10
Sep 22 23:41:48 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Content-Length: 0
Sep 22 23:41:48 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<<
Sep 22 23:41:48 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connection #0 to host 10.0.0.2 left intact
Sep 22 23:41:48 bananapipro vdr[3178]: [3184] SATIP5: bool cSatipRtsp::Play(const char*) (rtsp://10.0.0.2/stream=10?addpids=6300) Response 200 in 35 ms [device 0]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Found bundle for host 10.0.0.2: 0x5e98b0 [can pipeline]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Re-using existing connection! (#0) with host 10.0.0.2
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connected to 10.0.0.2 (10.0.0.2) port 554 (#0)
Sep 22 23:41:52 bananapipro vdr[3178]: [237B blob data]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTSP/1.0 454 Session Not Found
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Date: Thu, 22 Sep 2016 21:41:52 GMT
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< CSeq: 1008
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Content-Length: 0
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<<
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connection #0 to host 10.0.0.2 left intact
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP-ERROR: Detected invalid status code 454: rtsp://10.0.0.2/ [device 0]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP5: bool cSatipRtsp::Options(const char*) (rtsp://10.0.0.2/) Response 454 in 8 ms [device 0]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP-ERROR: Keep-alive failed - retuning [device 0]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Found bundle for host 10.0.0.2: 0x5e98b0 [can pipeline]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Re-using existing connection! (#0) with host 10.0.0.2
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connected to 10.0.0.2 (10.0.0.2) port 554 (#0)
Sep 22 23:41:52 bananapipro vdr[3178]: [312B blob data]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTSP/1.0 454 Session Not Found
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Date: Thu, 22 Sep 2016 21:41:52 GMT
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< CSeq: 1009
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Content-Length: 0
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<<
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connection #0 to host 10.0.0.2 left intact
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP-ERROR: Detected invalid status code 454: rtsp://10.0.0.2/ [device 0]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP5: bool cSatipRtsp::Play(const char*) (rtsp://10.0.0.2/stream=10?src=1&freq=11362&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&sr=22000&fec=23) Response 454 in 49 ms [device 0]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP-ERROR: Connect failed [device 0]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO   Trying 10.0.0.2...
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connected to 10.0.0.2 (10.0.0.2) port 554 (#0)
Sep 22 23:41:52 bananapipro vdr[3178]: [215B blob data]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTSP/1.0 200 OK
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Date: Thu, 22 Sep 2016 21:41:52 GMT
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< CSeq: 1
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Content-Length: 0
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<<
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connection #0 to host 10.0.0.2 left intact
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP5: bool cSatipRtsp::Options(const char*) (rtsp://10.0.0.2/) Response 200 in 50 ms [device 0]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Found bundle for host 10.0.0.2: 0x5e9110 [can pipeline]
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Re-using existing connection! (#0) with host 10.0.0.2
Sep 22 23:41:52 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connected to 10.0.0.2 (10.0.0.2) port 554 (#0)
Sep 22 23:41:52 bananapipro vdr[3178]: [334B blob data]
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTSP/1.0 200 OK
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Date: Thu, 22 Sep 2016 21:41:52 GMT
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< CSeq: 2
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Session: 10A26920;timeout=60
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< com.ses.streamID: 12
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Transport: RTP/AVP;unicast;destination=10.0.0.1;source=10.0.0.2;client_port=48400-48401;server_port=40076-51125
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Content-Length: 0
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<<
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connection #0 to host 10.0.0.2 left intact
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP5: bool cSatipRtsp::Setup(const char*, int, int, bool) (rtsp://10.0.0.2/?src=1&freq=11362&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&sr=22000&fec=23, 48400, 48401) Response 200 in 423 ms [device 0]
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Found bundle for host 10.0.0.2: 0x5e9110 [can pipeline]
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Re-using existing connection! (#0) with host 10.0.0.2
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connected to 10.0.0.2 (10.0.0.2) port 554 (#0)
Sep 22 23:41:53 bananapipro vdr[3178]: [299B blob data]
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTSP/1.0 200 OK
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Date: Thu, 22 Sep 2016 21:41:52 GMT
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Session: 10A26920
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< CSeq: 3
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTP-Info: url=rtsp://10.0.0.2/stream=12
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Content-Length: 0
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<<
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connection #0 to host 10.0.0.2 left intact
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP5: bool cSatipRtsp::Play(const char*) (rtsp://10.0.0.2/stream=12?pids=0,16,17,18,20,6300,6310,6320,6321,6322,6323,6330,6331) Response 200 in 100 ms [device 0]
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Found bundle for host 10.0.0.2: 0x5e9110 [can pipeline]
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Re-using existing connection! (#0) with host 10.0.0.2
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connected to 10.0.0.2 (10.0.0.2) port 554 (#0)
Sep 22 23:41:53 bananapipro vdr[3178]: [269B blob data]
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< RTSP/1.0 200 OK
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Date: Thu, 22 Sep 2016 21:41:53 GMT
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Content-Type: application/sdp
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Content-Base: rtsp://10.0.0.2/
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Content-Length: 266
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< CSeq: 4
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<< Session: 10A26920
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP HEAD <<<
Sep 22 23:41:53 bananapipro vdr[3178]: [385B blob data]
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP2: static int cSatipRtsp::DebugCallback(CURL*, curl_infotype, char*, size_t, void*) [device 0] RTSP INFO Connection #0 to host 10.0.0.2 left intact
Sep 22 23:41:53 bananapipro vdr[3178]: [3184] SATIP5: bool cSatipRtsp::Describe(const char*) (rtsp://10.0.0.2/stream=12) Response 200 in 82 ms [device 0]
Sep 22 23:41:53 bananapipro vdr[3178]: [3183] SATIP: Detected 1 RTP packet errors [device 0]

my setup:
satip server: HUMAX Digital UHD 4tune+. The server has no configuration possibilities other than name and IP, so I can't fiddle around with any settings on the server itself.
vdr 2.2.0 runs on a Banana Pi Pro (IP 10.0.0.1 in the log) that's directly connected through the ethernet port with the Humax satip server (IP 10.0.0.2 in the log)
satip plugin version is the current git version from the 2.2.x branch (earlier tonight I also compiled a version that enables the existing server.c SessionID quirk for my server, but that didn't solve the issue).
libcurl version: 7.47.0-1ubuntu2.1

Any help would be greatly appreciated. If a tcpdump is needed, I'd need some directions on what command to use to capture the desired output.

Config Directory in resource tree?

I dont understand why you use cPlugin::ResourceDirectory in satip.c line 124:
SatipConfig.SetConfigDirectory(cPlugin::ResourceDirectory(PLUGIN_NAME_I18N));

Why not use cPlugin::configDirectory instead?

I detected it while setting my vdr4arch, where resource directory is in /usr/share/vdr and not writeable to vdr user, whereas config directory is /var/lib/vdr that can be written by vdr user.

Stefan

Plugin does not start fresh connection after Curl timeout

I recently "upgraded" my setup with a Kathrein EXIP 418.
It seems that the box is rather allergic to EPG scans. After a while the device seems to "stall" for around 15 seconds before talking to VDR again.
When this happens, the log shows something like this:

May 20 11:46:10 server vdr[28570]: [28609] curl_easy_perform() [rtsp.c,369] failed: Timeout was reached (28)
May 20 11:46:10 server vdr[28570]: [28609] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 2]
May 20 11:46:10 server vdr[28570]: [28609] SATIP-ERROR: Pid update failed - retuning [device 2]
May 20 11:46:10 server vdr[28570]: [28601] curl_easy_perform() [rtsp.c,369] failed: Timeout was reached (28)
May 20 11:46:10 server vdr[28570]: [28601] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 0]
May 20 11:46:10 server vdr[28570]: [28601] SATIP-ERROR: Pid update failed - retuning [device 0]
May 20 11:46:10 server vdr[28570]: [28612] curl_easy_perform() [rtsp.c,369] failed: Timeout was reached (28)
May 20 11:46:10 server vdr[28570]: [28612] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 3]
May 20 11:46:10 server vdr[28570]: [28612] SATIP-ERROR: Pid update failed - retuning [device 3]
May 20 11:46:11 server vdr[28570]: [28609] curl_easy_perform() [rtsp.c,369] failed: Timeout was reached (28)

Shortly after that the messages show that the machine is reachable, but the port is closes.

May 20 11:46:23 server vdr[28570]: [28609] curl_easy_perform() [rtsp.c,369] failed: Couldn't connect to server (7)
May 20 11:46:23 server vdr[28570]: [28609] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 2]
May 20 11:46:23 server vdr[28570]: [28609] curl_easy_perform() [rtsp.c,369] failed: Couldn't connect to server (7)
May 20 11:46:23 server vdr[28570]: [28609] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 2]
May 20 11:46:23 server vdr[28570]: [28609] SATIP-ERROR: Pid update failed - retuning [device 2]
May 20 11:46:23 server vdr[28570]: [28609] curl_easy_perform() [rtsp.c,369] failed: Couldn't connect to server (7)
May 20 11:46:23 server vdr[28570]: [28609] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 2]
May 20 11:46:23 server vdr[28570]: [28609] curl_easy_perform() [rtsp.c,244] failed: Couldn't connect to server (7)
May 20 11:46:23 server vdr[28570]: [28609] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 2]
May 20 11:46:23 server vdr[28570]: [28609] SATIP-ERROR: Keep-alive failed - retuning [device 2]
May 20 11:46:23 server vdr[28570]: [28609] curl_easy_perform() [rtsp.c,369] failed: Couldn't connect to server (7)
May 20 11:46:23 server vdr[28570]: [28609] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 2]
May 20 11:46:23 server vdr[28570]: [28601] curl_easy_perform() [rtsp.c,369] failed: Couldn't connect to server (7)
May 20 11:46:23 server vdr[28570]: [28601] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 0]
May 20 11:46:23 server vdr[28570]: [28601] curl_easy_perform() [rtsp.c,369] failed: Couldn't connect to server (7)
May 20 11:46:23 server vdr[28570]: [28601] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 0]
May 20 11:46:23 server vdr[28570]: [28601] SATIP-ERROR: Pid update failed - retuning [device 0]
May 20 11:46:23 server vdr[28570]: [28601] curl_easy_perform() [rtsp.c,369] failed: Couldn't connect to server (7)
May 20 11:46:23 server vdr[28570]: [28601] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 0]
May 20 11:46:23 server vdr[28570]: [28609] curl_easy_perform() [rtsp.c,369] failed: Couldn't connect to server (7)
May 20 11:46:23 server vdr[28570]: [28609] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 2]
May 20 11:46:23 server vdr[28570]: [28609] SATIP-ERROR: Connect failed [device 2]
May 20 11:46:23 server vdr[28570]: [28612] curl_easy_perform() [rtsp.c,369] failed: Couldn't connect to server (7)
May 20 11:46:23 server vdr[28570]: [28612] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 3]
May 20 11:46:23 server vdr[28570]: [28612] curl_easy_perform() [rtsp.c,369] failed: Couldn't connect to server (7)
May 20 11:46:23 server vdr[28570]: [28612] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 3]
May 20 11:46:23 server vdr[28570]: [28612] SATIP-ERROR: Pid update failed - retuning [device 3]

As far as I understood error "7" is connection refused. So from here I'd say it is safe to assume, that we need to reset the connection and start anew.
Unfortunately the SATIP plugin seems to continue using the old sequence numbers after the EXIP418 has started talking to VDR again, instead of doing a "SETUP":

May 20 11:46:24 server vdr[28570]: [28609] curl_easy_perform() [rtsp.c,244] failed: Couldn't connect to server (7)
May 20 11:46:24 server vdr[28570]: [28609] SATIP-ERROR: Detected invalid status code 0: rtsp://10.6.66.254/ [device 2]
May 20 11:46:24 server vdr[28570]: [28609] SATIP-ERROR: Connect failed [device 2]
May 20 11:46:24 server vdr[28570]: [28612] SATIP-ERROR: Detected invalid status code 454: rtsp://10.6.66.254/ [device 3]
May 20 11:46:24 server vdr[28570]: [28612] SATIP-ERROR: Pid update failed - retuning [device 3]
May 20 11:46:24 server vdr[28570]: [28612] SATIP-ERROR: Detected invalid status code 454: rtsp://10.6.66.254/ [device 3]
May 20 11:46:24 server vdr[28570]: [28601] SATIP-ERROR: Detected invalid status code 454: rtsp://10.6.66.254/ [device 0]
May 20 11:46:24 server vdr[28570]: [28601] SATIP-ERROR: Pid update failed - retuning [device 0]
May 20 11:46:24 server vdr[28570]: [28601] SATIP-ERROR: Detected invalid status code 454: rtsp://10.6.66.254/ [device 0]
May 20 11:46:25 server vdr[28570]: [28612] SATIP-ERROR: Detected invalid status code 454: rtsp://10.6.66.254/ [device 3]
May 20 11:46:25 server vdr[28570]: [28612] SATIP-ERROR: Pid update failed - retuning [device 3]
May 20 11:46:25 server vdr[28570]: [28612] SATIP-ERROR: Detected invalid status code 454: rtsp://10.6.66.254/ [device 3]
May 20 11:46:25 server vdr[28570]: [28601] SATIP-ERROR: Detected invalid status code 454: rtsp://10.6.66.254/ [device 0]
May 20 11:46:25 server vdr[28570]: [28601] SATIP-ERROR: Pid update failed - retuning [device 0]
May 20 11:46:25 server vdr[28570]: [28601] SATIP-ERROR: Detected invalid status code 454: rtsp://10.6.66.254/ [device 0]
May 20 11:46:25 server vdr[28570]: [28601] SATIP-ERROR: Detected invalid status code 454: rtsp://10.6.66.254/ [device 0]
May 20 11:46:25 server vdr[28570]: [28601] SATIP-ERROR: Pid update failed - retuning [device 0]

It seems as if the EXIP418 did infact reboot here. The uptime is 3:03h. Which corresponds to the time of the log error.

Any help is greatly appreciated.

Question: DVBViewer CI

is there any reference to the DVBViewer ciTnr paramater documentation on internet?

CA_PMT doesn't contain CA descriptors

If i use vdr-2.2.0 with satip-plugin (c07d921), dvbapi (git) can't decrypt some sky channels from the same transponder. Without satip-plugin, only with dual dvb card, the dvbapi-plugin has no problems to decrypt the channels. So my setup for decrypt should be ok. I have testet this although with mld-5.4 testing and a self compiled vdr-2.4 with newest git versions of dvbapi and satip. The error exists there too.

I think vdr-satip-plugin doesn't deliver some necessary infos to dvbapi for decryption.
dvbapi_log.txt

question about your website

Hello Rolf,

Today I discovered that your home- and download site http://www.saunalahti.fi/*** is not reachable.
The email *** is also undeliverable,

Is this a failure or did you give it up? If yes, is there a new website and/or email or will I find everything on github from now on?
Please let us know.

Greetings from Berlin, Germany
Martin

CC @hd_brummy

Ring buffer overflows from cSatipDevice::WriteData()

Rather often the vdr blocks with ring buffer overflows when switching channels:

Apr 25 23:54:36 core vdr: video: 22:32:00.692  +14  608   0/\ms  65+2 v-buf
Apr 25 23:55:13 core vdr: [1305] epg data writer thread started (pid=3391, tid=1305, prio=low)
Apr 25 23:55:13 core vdr: [1305] epg data writer thread ended (pid=3391, tid=1305)
Apr 25 23:55:36 core vdr: video: 22:33:00.692  +14  536   0/\ms  53+2 v-buf
Apr 25 23:56:11 core vdr: [3400] channel 2 (SRF zwei HD) event Mo. 25.04.2016 23:55-00:50 (VPS: 25.04. 23:50) 'Lilyhammer' status 4
Apr 25 23:56:36 core vdr: video: 22:34:00.692  +14  536   0/\ms  59+2 v-buf
Apr 25 23:57:36 core vdr: video: 22:35:00.692  +14  513   0/\ms  55+2 v-buf
Apr 25 23:58:36 core vdr: video: 22:36:00.692  +14  584   0/\ms  61+2 v-buf
Apr 25 23:59:36 core vdr: video: 22:37:00.692  +14  561   0/\ms  61+2 v-buf
Apr 25 23:59:51 core vdr: [3391] switching to channel 2 (SRF zwei HD)
Apr 25 23:59:51 core vdr: [3391] [softhddev]SetPlayMode: 0
Apr 25 23:59:51 core vdr: [3391] [softhddev]SetVideoDisplayFormat: 1
Apr 25 23:59:51 core vdr: [3391] [softhddev]GetSpuDecoder:
Apr 25 23:59:51 core vdr: [5221] osdteletext-receiver thread ended (pid=3391, tid=5221)
Apr 25 23:59:51 core vdr: [3396] ERROR: 1 ring buffer overflow (1316 bytes dropped)
Apr 25 23:59:52 core vdr: video: decoder buffer empty, duping frame (68/273741) 0 v-buf
Apr 25 23:59:52 core vdr: video: --:--:--.---   +0    0   0/\ms   0+0 v-buf
Apr 25 23:59:53 core vdr: [3396] SATIP: Detected 1 RTP packet errors [device 0]
Apr 25 23:59:57 core vdr: [3396] ERROR: 525 ring buffer overflows (690900 bytes dropped)
Apr 26 00:00:03 core vdr: [3396] ERROR: 595 ring buffer overflows (783020 bytes dropped)
Apr 26 00:00:09 core vdr: [3396] ERROR: 595 ring buffer overflows (783020 bytes dropped)
Apr 26 00:00:15 core vdr: [3396] ERROR: 594 ring buffer overflows (781704 bytes dropped)
Apr 26 00:00:21 core vdr: [3396] ERROR: 595 ring buffer overflows (783020 bytes dropped)
Apr 26 00:00:27 core vdr: [3396] ERROR: 595 ring buffer overflows (783020 bytes dropped)

By adding additional debug code to device.c, I managed to identify cSatipDevice::WriteData() as the source of the error message.

The Sat->IP server is a recent version of minisatip. I tried to debug the issue using svdrpsend PLUG satip trac 0x8000, but this creates enormous amount of log data and the vdr hits CPU limits (on a rather recent i5 machine...).

Cheers

250ms delay between commands is missing sometimes

In order to figure out way my EXIP418 still reboots at least once a day(after the fixes in the past couple of days), I added a few lines to the code for debugging:

diff --git a/rtsp.c b/rtsp.c
index 63e6dfa..75cf281 100644
--- a/rtsp.c
+++ b/rtsp.c
@@ -12,6 +12,15 @@
 #include "common.h"
 #include "log.h"
 #include "rtsp.h"
+#include <sys/time.h>
+
+long long current_timestamp() {
+    struct timeval te;
+    gettimeofday(&te, NULL); // get current time
+    long long milliseconds = te.tv_sec*1000LL + te.tv_usec/1000; // calculate milliseconds
+    // printf("milliseconds: %lld\n", milliseconds);
+    return milliseconds;
+}

 cSatipRtsp::cSatipRtsp(cSatipTunerIf &tunerP)
 : tunerM(tunerP),
@@ -231,6 +240,7 @@ bool cSatipRtsp::Receive(const char *uriP)
 bool cSatipRtsp::Options(const char *uriP)
 {
   debug1("%s (%s) [device %d]", __PRETTY_FUNCTION__, uriP, tunerM.GetId());
+  error("%lld|OPTIONS|%s|[device %d]", current_timestamp(), uriP, tunerM.GetId());

The "error" line was added to each RTSP function , in order to see when a command was issued.
The cleaned up log then looked like this:

1622310691339|OPTIONS|rtsp://10.6.66.254/|[device 3]
1622310691340|SETUP|rtsp://10.6.66.254/?src=1&freq=11597&pol=v&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=22000&fec=56|[device 3]
1622310691341|DESCRIBE|rtsp://10.6.66.254/STREAM_ID|[device 3]
1622310691587|DESCRIBE|rtsp://10.6.66.254/STREAM_ID|[device 1]
1622310691989|PLAY|rtsp://10.6.66.254/STREAM_ID?addpids=201|[device 2]
1622310692252|PLAY|rtsp://10.6.66.254/STREAM_ID?delpids=201|[device 2]
1622310692342|DESCRIBE|rtsp://10.6.66.254/STREAM_ID|[device 3]
1622310692502|PLAY|rtsp://10.6.66.254/STREAM_ID?addpids=202|[device 2]
1622310692588|DESCRIBE|rtsp://10.6.66.254/STREAM_ID|[device 1]
1622310692844|PLAY|rtsp://10.6.66.254/STREAM_ID?addpids=18|[device 3]
1622310692951|PLAY|rtsp://10.6.66.254/STREAM_ID?delpids=202|[device 2]
1622310693095|PLAY|rtsp://10.6.66.254/STREAM_ID?addpids=0,16,17,20|[device 3]
1622310693096|PLAY|rtsp://10.6.66.254/STREAM_ID?addpids=18,20|[device 1]
1622310693202|PLAY|rtsp://10.6.66.254/STREAM_ID?addpids=662|[device 2]
1622310693347|PLAY|rtsp://10.6.66.254/STREAM_ID?addpids=0,16,17|[device 1]
1622310693543|PLAY|rtsp://10.6.66.254/STREAM_ID?addpids=1090|[device 3]

After I pulled a day worth of log data from VDR, a few lines of Python code showed, that the commands being sent to a particular device sometimes come in without any delay:

waiting: 250.0ms
command: PLAY
uri: rtsp://10.6.66.254/STREAM_ID?delpids=18
device: [device 2]

waiting: 1.0ms
command: PLAY
uri: rtsp://10.6.66.254/STREAM_ID?src=1&freq=11685&pol=v&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=22000&fec=56
device: [device 2]

The standard 250ms delay always seems to be missing right before a new channel is requested.

I also found that after a TEARDOWN, the plugin did not wait before issuing OPTIONS, SETUP & PLAY:

command: TEARDOWN
uri: rtsp://10.6.66.254/STREAM_ID
device: [device 3]

waiting: 1.0ms
command: OPTIONS
uri: rtsp://10.6.66.254/
device: [device 3]

waiting: 1.0ms
command: SETUP
uri: rtsp://10.6.66.254/?src=1&freq=10802&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&sr=22000&fec=34&plts=on
device: [device 3]

waiting: 0.0ms
command: PLAY
uri: rtsp://10.6.66.254/STREAM_ID
device: [device 3]

create satip.h

Hello,

w_scan_cpp uses satip in his project. Right now in its Makefile it creates a satip.h header file based on what is in satip.c
Would it be possible to split this ?

This would

ease the reuse of your plugin by other projects
permit to reference it as a dependency in package management systems like on debian

detectsatip.py issue

Hi,
detectsatip.py will not find Panasonic TV's, the plugin did found it.

OS Ubuntu 18.04
this is the output, the Panasonic is not shown

./detectsatip.py
[
  {
    "frontends": {
      "DVBC": 2, 
      "DVBC2": 2, 
      "DVBS2": 4, 
      "DVBT2": 2
    }, 
    "name": "minisatip"
  }, 
  {
    "frontends": {
      "DVBC": 4
    }, 
    "name": "FRITZ!Box 6490 Cable"
  }
]

CU
9000h

Bugs with Megasat SAT>IP Server 2

Hi,
I tried your plugin with the Megasat SAT>IP Server 2
and discovered some bugs.

The Megasat SAT>IP Server 2 identifies itself as
'Dvbs2-4' but the cDvbTransponderParameters it
is reported as dvbs (not dvbs2).

SatIp Spec 1.2.2 specifies, that
Roll-Off, Modulation Type and Pilot Tones
shall be given in the client request. If they are
not given, the Megasat device reports a 'Internal Server Error'
in the Setup phase.

There is a bug with the rtsp session id. The first character of
the session id gets lost somewhere. It is extracted correctly
in the cSatipRtsp::HeaderCallback but somehow it gets lost
in the curl calls. Note, if I set it correctly in the Tuner: SetSessionTimeout
using rtspM.SetSession(SkipZeroes(*sessionM)); it works, but
I get CURL errors in the syslog.

For now I only have hacky workarounds, for the 1.03 version.
If I come up with a real patch, I will report back.

Wrong URI for x_pmt if it's the only parameter

When using the plugin with a Octopus NET it sometimes tries to do requests like rtsp://[ip]/stream=1&x_pmt=2000 for encrypted channels. This request looks wrong because there should be a ? instead of &. The Octopus NET answers with a status code 400.

Is there a check missing here?

vdr-plugin-satip/tuner.c

Line 512 in 299296b

uri = cString::sprintf("%s&x_pmt=%d", *uri, pid);

The check is done some lines above:

vdr-plugin-satip/tuner.c

Line 499 in 299296b

 uri = cString::sprintf("%s%sdelpids=%s", *uri, addPidsM.Size() ? "&" : "?", *delPidsM.ListPids()); 

caid replace possibility

Hello

is it possible to implement a setting for a default caid replacement to 1a or somethings else which enables the possibility to choose the channel on vdr connected to satip server with serverside decryption.

Otherwise u always have to hack channels.conf (as u remember from prior streamdev times) to switch vdr.

thanks
Pitty

code bug in frontend selection

Hi!

First of all thanks for that plugin, which enables me to return from a short tvheadend trip! ;)

But as it seems, I might be the only one requiring the "frontend selection feature", cause I think I found a bug in the source code preventing this from working at all:
In param.c#L167 if using a RID > 100, the query string gets started with "&fe=%d" and then in the next line followed by "src=%d&", which results in a URL path like /?&fe=2src=2&freq=..., which is obviously not correct.

I fixed it by move the ampersand to the end, like this "fe=%d&". I'm not sure if that's a correct fix though, as I didn't verify what else happens to the query string before and after.

Background:
I'm using a Digibit Twin device with two LNBs aligned to different satellites. In order to be able to use channels from both satellite positions, I need to pin them to the corresponding frontend (=tuner), since I haven't found a way to tell the device about different sources (=satellite positions).

BR,
hubsif.

PIDs are added and removed again within milliseconds

Trying to figure out why my EXIP418 sometimes stops working and reboots, I noticed that PIDs are added and removed constantly within milliseconds? Since my VDR is idle most of the day, it is probably busy doing EPG scans most of the time.

In the example here, VDR switched to 11347H on Astra 19.2E (during EPG-scan I presume). As you can see quite clearly, PIDs 6500, 6600 and 6700 are constantly added and removed again.
According to my channels.conf, those PIDs do not exist on this transponder. How come they are being used here?
Is this the way it is supposed to work? I though that PIDs are added once lock was acquired and deleted upon switching to another channel.

This is my current conf for satip:

[satip]
-d 4
-s 10.6.66.254:554|DVBS2-4|EXIP418:0x40
-p 4000-4007

This is an excerpt from the tcpdump taken today:

No.	Time	Source	Destination	Protocol	Length	Info
4862	10:58:38,661184	10.6.66.42	10.6.66.254	RTSP	282	PLAY rtsp://10.6.66.254/stream=72?src=1&freq=11347&pol=v&ro=0.35&msys=dvbs2&mtype=8psk&sr=22000&fec=23&plts=on RTSP/1.0
4863	10:58:38,662046	10.6.66.254	10.6.66.42	RTSP	177	Reply: RTSP/1.0 200 OK
4864	10:58:38,662057	10.6.66.42	10.6.66.254	TCP	70	10514 → 554 [ACK] Seq=241830 Ack=175507 Win=73856 Len=0 TSval=1825035826 TSecr=19306978
4865	10:58:38,662104	10.6.66.42	10.6.66.254	RTSP	205	PLAY rtsp://10.6.66.254/stream=72 RTSP/1.0
4866	10:58:38,662661	10.6.66.254	10.6.66.42	RTSP	177	Reply: RTSP/1.0 200 OK
4867	10:58:38,662667	10.6.66.42	10.6.66.254	TCP	70	10514 → 554 [ACK] Seq=241965 Ack=175614 Win=73856 Len=0 TSval=1825035827 TSecr=19306979
4868	10:58:38,912907	10.6.66.42	10.6.66.254	RTSP	227	PLAY rtsp://10.6.66.254/stream=72?addpids=0,16,17,18,20 RTSP/1.0
4869	10:58:38,913622	10.6.66.254	10.6.66.42	RTSP	177	Reply: RTSP/1.0 200 OK
4870	10:58:38,913643	10.6.66.42	10.6.66.254	TCP	70	10514 → 554 [ACK] Seq=242122 Ack=175721 Win=73856 Len=0 TSval=1825036078 TSecr=19307230
4871	10:58:41,823950	10.6.66.42	10.6.66.254	RTSP	218	PLAY rtsp://10.6.66.254/stream=72?addpids=6500 RTSP/1.0
4872	10:58:41,824497	10.6.66.254	10.6.66.42	RTSP	177	Reply: RTSP/1.0 200 OK
4873	10:58:41,824505	10.6.66.42	10.6.66.254	TCP	70	10514 → 554 [ACK] Seq=242270 Ack=175828 Win=73856 Len=0 TSval=1825038988 TSecr=19310140
4874	10:58:42,143170	10.6.66.42	10.6.66.254	RTSP	218	PLAY rtsp://10.6.66.254/stream=72?delpids=6500 RTSP/1.0
4875	10:58:42,143665	10.6.66.254	10.6.66.42	RTSP	177	Reply: RTSP/1.0 200 OK
4876	10:58:42,143672	10.6.66.42	10.6.66.254	TCP	70	10514 → 554 [ACK] Seq=242418 Ack=175935 Win=73856 Len=0 TSval=1825039308 TSecr=19310460
4877	10:58:42,393852	10.6.66.42	10.6.66.254	RTSP	218	PLAY rtsp://10.6.66.254/stream=72?addpids=6600 RTSP/1.0
4878	10:58:42,394380	10.6.66.254	10.6.66.42	RTSP	177	Reply: RTSP/1.0 200 OK
4879	10:58:42,394392	10.6.66.42	10.6.66.254	TCP	70	10514 → 554 [ACK] Seq=242566 Ack=176042 Win=73856 Len=0 TSval=1825039558 TSecr=19310710
4880	10:58:42,645236	10.6.66.42	10.6.66.254	RTSP	218	PLAY rtsp://10.6.66.254/stream=72?delpids=6600 RTSP/1.0
4881	10:58:42,645766	10.6.66.254	10.6.66.42	RTSP	177	Reply: RTSP/1.0 200 OK
4882	10:58:42,645779	10.6.66.42	10.6.66.254	TCP	70	10514 → 554 [ACK] Seq=242714 Ack=176149 Win=73856 Len=0 TSval=1825039810 TSecr=19310962
4883	10:58:42,895950	10.6.66.42	10.6.66.254	RTSP	218	PLAY rtsp://10.6.66.254/stream=72?addpids=6700 RTSP/1.0
4884	10:58:42,896430	10.6.66.254	10.6.66.42	RTSP	177	Reply: RTSP/1.0 200 OK
4885	10:58:42,896443	10.6.66.42	10.6.66.254	TCP	70	10514 → 554 [ACK] Seq=242862 Ack=176256 Win=73856 Len=0 TSval=1825040060 TSecr=19311212
4886	10:58:43,146473	10.6.66.42	10.6.66.254	RTSP	218	PLAY rtsp://10.6.66.254/stream=72?delpids=6700 RTSP/1.0
4887	10:58:43,146928	10.6.66.254	10.6.66.42	RTSP	177	Reply: RTSP/1.0 200 OK
4888	10:58:43,146935	10.6.66.42	10.6.66.254	TCP	70	10514 → 554 [ACK] Seq=243010 Ack=176363 Win=73856 Len=0 TSval=1825040311 TSecr=19311463
4889	10:58:43,397115	10.6.66.42	10.6.66.254	RTSP	218	PLAY rtsp://10.6.66.254/stream=72?addpids=6500 RTSP/1.0
4890	10:58:43,397746	10.6.66.254	10.6.66.42	RTSP	177	Reply: RTSP/1.0 200 OK
4891	10:58:43,397758	10.6.66.42	10.6.66.254	TCP	70	10514 → 554 [ACK] Seq=243158 Ack=176470 Win=73856 Len=0 TSval=1825040562 TSecr=19311714
4892	10:58:43,646693	10.6.66.42	10.6.66.254	RTSP	218	PLAY rtsp://10.6.66.254/stream=72?delpids=6500 RTSP/1.0

FRITZ!Box quirks

Hi,

can you please add/change the FRITZ!Box quirks

as reference:
http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/p1294442-iptv-fritzbox-erledigt/#post1294442

the Fritz!Box limits the also 1 source IP to one tuner
it would be also great if an additional quirk for this limit goes in like in TVH
https://tvheadend.org/boards/4/topics/18013?r=22619#message-22619

here a the 2 xml sample files

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<root xmlns="urn:schemas-upnp-org:device-1-0" configId="0">


<specVersion>

<major>1</major>
<minor>0</minor>
</specVersion>


<device>

<deviceType>urn:ses-com:device:SatIPServer:1</deviceType>
<friendlyName>FRITZ!Box 6490 Cable</friendlyName>
<manufacturer>AVM Berlin</manufacturer>
<manufacturerURL>http://www.avm.de</manufacturerURL>
<modelDescription>FRITZ!Box 6490 Cable</modelDescription>
<modelName>FRITZ!Box 6490 Cable</modelName>
<modelNumber>avm</modelNumber>
<modelURL>http://www.avm.de</modelURL>
<serialNumber/>
<UDN>uuid:663d5d6c-f9f7-4bb4-84d4-5C3979431C37</UDN>
<iconList></iconList>


<serviceList>



<service>

<serviceType>urn:ses-com:service:satip:1</serviceType>
<serviceId>urn:ses-com:serviceId:satip</serviceId>
<controlURL>/upnp/control/satip</controlURL>
<eventSubURL>/upnp/control/satip</eventSubURL>
<SCPDURL>/satipSCPD.xml</SCPDURL>
</service>
</serviceList>
<presentationURL>http://fritz.box</presentationURL>
<satip:X_SATIPCAP xmlns:satip="urn:ses-com:satip">DVBC-2</satip:X_SATIPCAP>
</device>
</root>

and the Fritz Repeater

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<root xmlns="urn:schemas-upnp-org:device-1-0" configId="0">



<specVersion>

<major>1</major>
<minor>0</minor>
</specVersion>


<device>

<deviceType>urn:ses-com:device:SatIPServer:1</deviceType>
<friendlyName>FRITZ!WLAN Repeater DVB-C</friendlyName>
<manufacturer>AVM Berlin</manufacturer>
<manufacturerURL>avm.de</manufacturerURL>
<modelDescription>FRITZ!WLAN Repeater DVB-C</modelDescription>
<modelName>FRITZ!WLAN Repeater DVB-C</modelName>
<modelNumber>avm</modelNumber>
<modelURL>avm.de</modelURL>
<serialNumber/>
<UDN>uuid:663d5d6c-f9f8-4bb4-84d4-3431C46D68B8</UDN>
<iconList></iconList>


<serviceList>



<service>

<serviceType>urn:ses-com:service:satip:1</serviceType>
<serviceId>urn:ses-com:serviceId:satip</serviceId>
<controlURL>/upnp/control/satip</controlURL>
<eventSubURL>/upnp/control/satip</eventSubURL>
<SCPDURL>/satipSCPD.xml</SCPDURL>
</service>
</serviceList>
<presentationURL>192.168.178.74</presentationURL>
<satip:X_SATIPCAP xmlns:satip="urn:ses-com:satip">DVBC-2</satip:X_SATIPCAP>
</device>
</root>

vdr-2.5.1 crash

I did try out the new vdr-2.5.1 but I get a crash

gdb --args vdr  -l3 -w 60 -P"satip -d2 -s 192.168.178.129|DVBS2-4,DVBC-2,DVBT2-2|minisatip " -P"softhddevice -l3 -f -v va-api -a default -c softvol -w alsa-driver-broken "
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vdr...
(gdb) r
Starting program: /home/bernd/vdr/vdr/vdr -l3 -w 60 -Psatip\ -d2\ -s\ 192.168.178.129\|DVBS2-4,DVBC-2,DVBT2-2\|minisatip\  -Psofthddevice\ -l3\ -f\ -v\ va-api\ -a\ default\ -c\ softvol\ -w\ alsa-driver-broken\ 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeb366700 (LWP 60019)]
[New Thread 0x7fffeab65700 (LWP 60020)]
[Thread 0x7fffeb366700 (LWP 60019) exited]
[New Thread 0x7fffeb366700 (LWP 60021)]
[New Thread 0x7fffea161700 (LWP 60022)]
[New Thread 0x7fffe975f700 (LWP 60023)]
[New Thread 0x7fffe8f5e700 (LWP 60024)]
[New Thread 0x7fffd3fff700 (LWP 60025)]
[New Thread 0x7fffd37fe700 (LWP 60026)]
[New Thread 0x7fffd2ffd700 (LWP 60027)]
[New Thread 0x7fffd27fc700 (LWP 60028)]
[New Thread 0x7fffd1003700 (LWP 60029)]
[New Thread 0x7fffd0802700 (LWP 60030)]
[Thread 0x7fffd1003700 (LWP 60029) exited]
[New Thread 0x7fffd1003700 (LWP 60031)]
[Thread 0x7fffd1003700 (LWP 60031) exited]
[New Thread 0x7fffd1003700 (LWP 60032)]
[Thread 0x7fffd1003700 (LWP 60032) exited]
[New Thread 0x7fffd1003700 (LWP 60033)]
[Thread 0x7fffd1003700 (LWP 60033) exited]
[New Thread 0x7fffd1003700 (LWP 60034)]
[Thread 0x7fffd1003700 (LWP 60034) exited]
[New Thread 0x7fffd1003700 (LWP 60035)]
[Thread 0x7fffd1003700 (LWP 60035) exited]
[New Thread 0x7fffd1003700 (LWP 60036)]
[Thread 0x7fffd1003700 (LWP 60036) exited]
[New Thread 0x7fffd1003700 (LWP 60037)]
[Thread 0x7fffd1003700 (LWP 60037) exited]
[New Thread 0x7fffd1003700 (LWP 60038)]
[Thread 0x7fffd1003700 (LWP 60038) exited]
[New Thread 0x7fffd1003700 (LWP 60039)]
[Thread 0x7fffd1003700 (LWP 60039) exited]
[New Thread 0x7fffd1003700 (LWP 60040)]
[Thread 0x7fffd1003700 (LWP 60040) exited]
[New Thread 0x7fffd1003700 (LWP 60041)]
[Thread 0x7fffd1003700 (LWP 60041) exited]
[New Thread 0x7fffd1003700 (LWP 60042)]
[Thread 0x7fffd1003700 (LWP 60042) exited]
[New Thread 0x7fffd1003700 (LWP 60043)]
[Thread 0x7fffd1003700 (LWP 60043) exited]
[New Thread 0x7fffd1003700 (LWP 60044)]
[Thread 0x7fffd1003700 (LWP 60044) exited]
[New Thread 0x7fffd1003700 (LWP 60045)]
[Thread 0x7fffd1003700 (LWP 60045) exited]
[New Thread 0x7fffd1003700 (LWP 60046)]
[Thread 0x7fffd1003700 (LWP 60046) exited]
[New Thread 0x7fffd1003700 (LWP 60047)]
[Thread 0x7fffd1003700 (LWP 60047) exited]
[New Thread 0x7fffd1003700 (LWP 60048)]
[Thread 0x7fffd1003700 (LWP 60048) exited]
[New Thread 0x7fffd1003700 (LWP 60049)]
[Thread 0x7fffd1003700 (LWP 60049) exited]
[New Thread 0x7fffd1003700 (LWP 60050)]
[Thread 0x7fffd1003700 (LWP 60050) exited]
[New Thread 0x7fffd1003700 (LWP 60051)]
[Thread 0x7fffd1003700 (LWP 60051) exited]
[New Thread 0x7fffd1003700 (LWP 60052)]
[Thread 0x7fffd1003700 (LWP 60052) exited]
[New Thread 0x7fffd1003700 (LWP 60053)]
[Thread 0x7fffd1003700 (LWP 60053) exited]
[New Thread 0x7fffd1003700 (LWP 60054)]
[New Thread 0x7fff97fff700 (LWP 60055)]
[New Thread 0x7fff8ad13700 (LWP 60056)]
[Thread 0x7fffeab65700 (LWP 60020) exited]
--Type <RET> for more, q to quit, c to continue without paging--c

Thread 1 "vdr" received signal SIGSEGV, Segmentation fault.
__memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:262
262	../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt
#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:262
#1  0x000055555568d2eb in memcpy (__len=2096952, __src=0x2, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#2  cRingBufferLinear::Put(unsigned char const*, int) (this=0x5555557c1060, Data=Data@entry=0x2 <error: Cannot access memory at address 0x2>, Count=2096952, Count@entry=1432441152) at ringbuffer.c:329
#3  0x00007ffff7155ccc in cSatipSectionFilterHandler::Write(unsigned char*, int) (this=0x555555e90f40, bufferP=0x2 <error: Cannot access memory at address 0x2>, lengthP=1432441152) at sectionfilter.c:456
#4  0x0000555555616057 in cDevice::GetDevice(cChannel const*, int, bool, bool) (Channel=0x5555558de030, Priority=<optimized out>, LiveView=<optimized out>, Query=<optimized out>) at device.c:356
#5  0x000055555561822a in cDevice::SetChannel(cChannel const*, bool) (this=0x555555ed4480, Channel=0x5555558de030, LiveView=<optimized out>) at device.c:881
#6  0x000055555561836a in cDevice::SwitchChannel(cChannel const*, bool) (this=0x555555ed4480, Channel=0x5555558de030, LiveView=<optimized out>) at device.c:809
#7  0x00005555555f59a8 in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at vdr.c:927
(gdb)

any ideas how to fix ?

Artifacts in vdr only when channels in same transponder

Reopens #51 (It was not only on low band, sorry.)

As mentioned in the old thread i tested with vlc and "pids=all". VLC is running without any problems, no artifacts at all.

1 | RTSP Dynamic | 192.168.178.23 | yes/yes | -38.75 | 100.00 | 11494H22000 | DVBS2/8PSK | 0,17,18,5100,5101,5102,5104

2 | RTSP Dynamic | 192.168.178.23 | yes/yes | -38.75 | 100.00 | 11493H22000 | DVBS2/8PSK | 5101,5102,5103,5104,5105,5106,18,20,0,16,17

Above status of webinterface of Selfsat IP36: 1 = VDR, 2= VLC

VLC started with

$ cat test.m3u
#EXTINF:0,1. Das Erste HD
rtsp://192.168.178.39/?src=1&freq=11494&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&plts=on&sr=22000&fec=23&pids=all

See https://files.pepre.de/vlc-satip.png for VLC mediainfo.

I don't know wether this is an issue of satip-plugin or vdr. But with the old HW (SAT TV pci-cards) this problem did not exist.

Any help would be greatly appreciated.

Thanks a lot for your time and efforts.

Glitches when switching channels

If multiple clients are connected there are glitches on switching channels.

Scenario:

Client 1 watches channel A
Client 2 watches channel B
Client 1 switches to channel C
Client 2 experiences a glitch (video distortion)

I narrowed it down to commit df81905.
Removing this commit removes the problem.

channel switching issue

Usually the first attempt to switch to a (encrypted) channel fails after the VDR was receiving for longer time from a different transponder:

Nov 10 09:43:42 core vdr: [1027] switching to channel 1 S13.0E-318-12300-17201 (SRF 1 HD)
Nov 10 09:43:42 core vdr: [1027] [softhddev]SetPlayMode: 0
Nov 10 09:43:42 core vdr: [1027] [softhddev]SetVideoDisplayFormat: 1
Nov 10 09:43:42 core vdr: [1027] [softhddev]GetSpuDecoder:
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesChannel(const cChannel*, int, bool*) const (1, 0, 1) [device 0]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesTransponder(const cChannel*) const (1) transponder=110971 source=S [device 0]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesSource(int) const (S) desc='2 Eutelsat Hot Bird 13B/13C/13D' [device 0]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesChannel(const cChannel*, int, bool*) const (1, 0, 1) [device 1]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesTransponder(const cChannel*) const (1) transponder=110971 source=S [device 1]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesSource(int) const (S) desc='2 Eutelsat Hot Bird 13B/13C/13D' [device 1]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesChannel(const cChannel*, int, bool*) const (1, 0, 1) [device 2]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesTransponder(const cChannel*) const (1) transponder=110971 source=S [device 2]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesSource(int) const (S) desc='2 Eutelsat Hot Bird 13B/13C/13D' [device 2]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesChannel(const cChannel*, int, bool*) const (1, 0, 1) [device 3]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesTransponder(const cChannel*) const (1) transponder=110971 source=S [device 3]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesSource(int) const (S) desc='2 Eutelsat Hot Bird 13B/13C/13D' [device 3]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesChannel(const cChannel*, int, bool*) const (1, 0, 1) [device 4]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesTransponder(const cChannel*) const (1) transponder=110971 source=S [device 4]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesSource(int) const (S) desc='2 Eutelsat Hot Bird 13B/13C/13D' [device 4]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesChannel(const cChannel*, int, bool*) const (1, 0, 1) [device 5]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesTransponder(const cChannel*) const (1) transponder=110971 source=S [device 5]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::ProvidesSource(int) const (S) desc='2 Eutelsat Hot Bird 13B/13C/13D' [device 5]
Nov 10 09:43:42 core vdr: [13911] SATIP9: virtual void cSatipDevice::CloseDvr() [device 0]
Nov 10 09:43:42 core vdr: [13911] device 1 receiver thread ended (pid=1027, tid=13911)
Nov 10 09:43:42 core vdr: [1027] CAM 1: assigned to device 1
Nov 10 09:43:42 core vdr: [20392] device 1 receiver thread started (pid=1027, tid=20392, prio=high)
Nov 10 09:43:42 core vdr: [20392] SATIP9: virtual bool cSatipDevice::OpenDvr() [device 0]
Nov 10 09:43:42 core vdr: [1031] SATIP9: bool cSatipFrontends::Detach(int, int) (0, 322) DVB-C2/#4
Nov 10 09:43:42 core vdr: [1031] SATIP9: bool cSatipFrontends::Attach(int, int) (0, 322) DVB-C2/#4
Nov 10 09:43:42 core vdr: [1031] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 09:43:42 core vdr: [1031] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 09:43:42 core vdr: [1031] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 09:43:42 core vdr: [1031] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::SetChannelDevice(const cChannel*, bool) (1, 0) [device 0]
Nov 10 09:43:42 core vdr: [1027] SATIP9: virtual bool cSatipDevice::SetChannelDevice(const cChannel*, bool) No suitable server found [device 0]
Nov 10 09:43:42 core vdr: [1027] ERROR: Transfer-Mode kann nicht gestartet werden!
Nov 10 09:43:42 core vdr: [1030] SATIP: Detected 1 RTP packet error [device 0]
Nov 10 09:43:42 core vdr: [1031] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 09:43:43 core vdr: [1031] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 09:43:43 core vdr: [1031] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 09:43:43 core vdr: [1031] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 09:43:43 core vdr: [1031] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 09:43:44 core vdr: [1027] switching to channel 33 C-1-15-1303 (Radio SRF 3)

In other cases the reception starts about a minute later:

Nov 10 10:20:00 core vdr: [23124] switching to channel 1 S13.0E-318-12300-17201 (SRF 1 HD)
Nov 10 10:20:00 core vdr: [23124] [softhddev]SetPlayMode: 0
Nov 10 10:20:00 core vdr: [23124] [softhddev]SetVideoDisplayFormat: 1
Nov 10 10:20:00 core vdr: [23124] [softhddev]GetSpuDecoder:
Nov 10 10:20:00 core vdr: [24103] SATIP9: virtual void cSatipDevice::CloseDvr() [device 0]
Nov 10 10:20:00 core vdr: [24103] device 1 receiver thread ended (pid=23124, tid=24103)
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesChannel(const cChannel*, int, bool*) const (1, 0, 1) [device 0]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesTransponder(const cChannel*) const (1) transponder=110971 source=S [device 0]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesSource(int) const (S) desc='2 Eutelsat Hot Bird 13B/13C/13D' [device 0]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesChannel(const cChannel*, int, bool*) const (1, 0, 1) [device 1]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesTransponder(const cChannel*) const (1) transponder=110971 source=S [device 1]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesSource(int) const (S) desc='2 Eutelsat Hot Bird 13B/13C/13D' [device 1]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesChannel(const cChannel*, int, bool*) const (1, 0, 1) [device 2]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesTransponder(const cChannel*) const (1) transponder=110971 source=S [device 2]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesSource(int) const (S) desc='2 Eutelsat Hot Bird 13B/13C/13D' [device 2]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesChannel(const cChannel*, int, bool*) const (1, 0, 1) [device 3]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesTransponder(const cChannel*) const (1) transponder=110971 source=S [device 3]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesSource(int) const (S) desc='2 Eutelsat Hot Bird 13B/13C/13D' [device 3]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesChannel(const cChannel*, int, bool*) const (1, 0, 1) [device 4]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesTransponder(const cChannel*) const (1) transponder=110971 source=S [device 4]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesSource(int) const (S) desc='2 Eutelsat Hot Bird 13B/13C/13D' [device 4]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesChannel(const cChannel*, int, bool*) const (1, 0, 1) [device 5]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesTransponder(const cChannel*) const (1) transponder=110971 source=S [device 5]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::ProvidesSource(int) const (S) desc='2 Eutelsat Hot Bird 13B/13C/13D' [device 5]
Nov 10 10:20:00 core vdr: [23124] CAM 1: assigned to device 1
Nov 10 10:20:00 core vdr: [25663] device 1 receiver thread started (pid=23124, tid=25663, prio=high)
Nov 10 10:20:00 core vdr: [25663] SATIP9: virtual bool cSatipDevice::OpenDvr() [device 0]
Nov 10 10:20:00 core vdr: [23128] SATIP9: bool cSatipFrontends::Detach(int, int) (0, 322) DVB-C2/#1
Nov 10 10:20:00 core vdr: [23128] SATIP9: bool cSatipFrontends::Attach(int, int) (0, 322) DVB-C2/#1
Nov 10 10:20:00 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:00 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:00 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:00 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:00 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:00 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:00 core vdr: [23124] SATIP9: virtual bool cSatipDevice::SetChannelDevice(const cChannel*, bool) (1, 0) [device 0]
Nov 10 10:20:00 core vdr: [23127] SATIP: Detected 24012 RTP packet errors [device 0]
Nov 10 10:20:01 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:01 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:01 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:01 core vdr: [23124] DVBAPI: 0.0 set CAM decrypt (SID 17201 (0x4331), caLm 4, HasCaDescriptors 1)
Nov 10 10:20:01 core vdr: [23124] [softhddev]SetPlayMode: 1
Nov 10 10:20:01 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:01 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:01 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:02 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:20:48 core vdr: video: --:--:--.---   +0    0   0/\ms   0+0+4 v-buf
Nov 10 10:21:01 core vdr: [23128] SATIP-ERROR: Detected invalid status code 404: rtsp://10.76.1.180/ [device 0]
Nov 10 10:21:01 core vdr: [23128] SATIP-ERROR: Keep-alive failed - retuning [device 0]
Nov 10 10:21:01 core vdr: [23128] SATIP-ERROR: Detected invalid status code 400: rtsp://10.76.1.180/ [device 0]
Nov 10 10:21:01 core vdr: [23128] SATIP-ERROR: Connect failed [device 0]
Nov 10 10:21:01 core vdr: [23128] SATIP9: bool cSatipFrontends::Detach(int, int) (0, 322) DVB-C2/#1
Nov 10 10:21:01 core vdr: [23128] SATIP9: bool cSatipFrontends::Attach(int, int) (0, 110971) DVB-S2/#1
Nov 10 10:21:01 core vdr: [23128] SATIP9: virtual void cSatipDevice::SetChannelTuned() () [device 0]
Nov 10 10:21:02 core vdr: audio/alsa: using device 'downmix'
Nov 10 10:21:02 core vdr: audio/alsa: start delay 500ms
Nov 10 10:21:02 core vdr: [softhddev] invalid PES video packet
Nov 10 10:21:02 core vdr: [softhddev] 8 invalid PES video packet(s)
Nov 10 10:21:03 core vdr: video: slow down video, duping frame
Nov 10 10:21:03 core vdr: video: 16:02:23.721 +116  612   0/\ms  55+4+4 v-buf
Nov 10 10:21:03 core vdr: video/vdpau: synced after 60 frames

The VDR has two servers available, one for DVB-S/S2 and one for DVB-C:

[satip]
--devices=6
--server=10.76.1.180|DVBS2-4|minisatip;10.76.1.173|DVBC2-4|OctopusNet

It seems this issue occurs very often on vdr-2.4.1 and current satip git 19e3057.

Returncode 404 from minisatip is not handled

I fixed an issue with minisatip and tuner sharing with one LNB. Now minsatip returns correctly the code 404 when I try to tune to a transponder on the slave tuner that can not be handled because the master tuner is busy on another band.

As 404 is not handled this results in a frozen screen. It would be better if the plugin could indicate to the vdr that the channel is not available when 404 is received. That way vdr would print a message "channel unavailable" and not tune to the new channel.

rofafor / vdr-plugin-satip Goto Github PK

vdr-plugin-satip's Introduction

vdr-plugin-satip's People

Contributors

Stargazers

Watchers

Forkers

vdr-plugin-satip's Issues

Recommend Projects

Recommend Topics

Recommend Org