no data sent for more than 1s

[9000h]

https://github.com/catalinii/minisatip/blob/f4a3400980a803e014ed29deee451121f47f7e70/src/stream.c#L1184-L1189 I do have some times "no data sent .." in my logs but there is data coming from the dmx, it seems in my setup it need at least up to 1.23s. I did increase the check to 1.5s and now it's not happen again.

[9000h]

hmm, it's still there also with 1.5s but not that often

Dec  1 21:47:10 localhost minisatip[28382]: [01/12 21:47:10.329 AD0]: read_dmx send=0, flush_all=0, cnt 0 called for adapter 0 -> 23688 out of 72192 bytes read, 1 ms ago (1498422 1498421)
Dec  1 21:47:10 localhost minisatip[28382]: [01/12 21:47:10.347 AD0]: read_dmx send=1, flush_all=1, cnt 0 called for adapter 0 -> 43428 out of 72192 bytes read, 19 ms ago (1498440 1498421)
Dec  1 21:47:10 localhost minisatip[28382]: [01/12 21:47:10.347 AD0]: process_dmx start called for adapter 0 -> 43428 out of 72192 bytes read, 19 ms ago
Dec  1 21:47:10 localhost minisatip[28382]: [01/12 21:47:10.348 AD0]: read_dmx send=0, flush_all=0, cnt 0 called for adapter 0 -> 22936 out of 72192 bytes read, 1 ms ago (1498441 1498440)
Dec  1 21:47:10 localhost minisatip[28382]: [01/12 21:47:10.366 AD0]: read_dmx send=1, flush_all=1, cnt 0 called for adapter 0 -> 43616 out of 72192 bytes read, 19 ms ago (1498459 1498440)
Dec  1 21:47:10 localhost minisatip[28382]: [01/12 21:47:10.366 AD0]: process_dmx start called for adapter 0 -> 43616 out of 72192 bytes read, 19 ms ago
Dec  1 21:47:10 localhost minisatip[28382]: [01/12 21:47:10.367 AD0]: no data sent for more than 1.5s (ctime - rtime 1666) sid: 0 for 192.168.178.114:46262
Dec  1 21:47:10 localhost minisatip[28382]: [01/12 21:47:10.367 AD0]: read_dmx send=0, flush_all=0, cnt 0 called for adapter 0 -> 22372 out of 72192 bytes read, 1 ms ago (1498460 1498459)
Dec  1 21:47:10 localhost minisatip[28382]: [01/12 21:47:10.385 AD0]: read_dmx send=1, flush_all=1, cnt 0 called for adapter 0 -> 44368 out of 72192 bytes read, 19 ms ago (1498478 1498459)
Dec  1 21:47:10 localhost minisatip[28382]: [01/12 21:47:10.385 AD0]: process_dmx start called for adapter 0 -> 44368 out of 72192 bytes read, 19 ms ago

[lars18th]

Great @9000h !

Regarding this part of code I'm not aware about it. However, I'm sure the interval is too short! I suspect that the objective is to detect errors in reception or handle slow streams. But is not very uncommon to receive signals with more than 1 second of interval between a chunk of packets. So I agree to increase the value, or else add some parameter to adjust it.

Regards.

[9000h]

or maybe rtime is not updated somewhere

[lars18th]

or maybe rtime is not updated somewhere

That's very difficult. At every sleep loop the rtime is updated. So it's not possible to receive data over a socket without updating this variable. So, IMHO your assumption doesn't have much sense.

[lars18th]

Regarding this, I have a question for @catalinii :

Why sometimes in the log appears such messages no data sent for more than 1s sid: when the DVR is reading packets?

[catalinii]

so the flow is something like: read from the dvr0 device (multiple times) -> read_dmx (multiple times) -> process_dmx (once) -> select data that needs to be send to the streams based on their selected pids -> write data to remote socket -> back in flush_stream* sid->wtime is updated.

You may check if something is sent to the output socket, but if process_dmx is called you should have sid->wtime updated.

[9000h]

can you see something unusual in the log? log.txt

[catalinii]

Went over the logs and there are 2 scenarios: 1) no data sent for stream 0 when adapter 6 (stream 1) is used - which is normal 2) the stream seems to stop with no apparent reason. 1 second later "no data ..."

Not sure why the stream is stopping ... which device are you using ? Why is the DVR buffer so small btw ? panasonic ?

[9000h]

I had not set any buffer option in minisatip, the client was VDR satip plugin.

[catalinii]

I meant the dvb hardware? Is this reproducible?

[9000h]

I do have DD cards with the git dddvb drivers

lsdvb 

        lsdvb: Simple utility to list PCI/PCIe DVB devices
        Version: 0.0.4
        Copyright (C) Manu Abraham

ddbridge (0:6 0:32) on PCI Domain:0 Bus:7 Device:0 Function:0
    DEVICE:0 ADAPTER:4 FRONTEND:0 (CXD2843 DVB-C/C2 DVB-T/T2) 
         FE_OFDM Fmin=47MHz Fmax=865MHz
    DEVICE:0 ADAPTER:2 FRONTEND:0 (STV090x Multistandard) 
         FE_QPSK Fmin=950MHz Fmax=2150MHz
    DEVICE:0 ADAPTER:7 FRONTEND:0 (CXD2843 DVB-C/C2 DVB-T/T2) 
         FE_QAM Fmin=47MHz Fmax=865MHz
    DEVICE:0 ADAPTER:0 FRONTEND:0 (STV090x Multistandard) 
         FE_QPSK Fmin=950MHz Fmax=2150MHz
    DEVICE:0 ADAPTER:5 FRONTEND:0 (CXD2843 DVB-C/C2 DVB-T/T2) 
         FE_QAM Fmin=47MHz Fmax=865MHz
    DEVICE:0 ADAPTER:3 FRONTEND:0 (STV090x Multistandard) 
         FE_QPSK Fmin=950MHz Fmax=2150MHz
    DEVICE:0 ADAPTER:1 FRONTEND:0 (STV090x Multistandard) 
         FE_QPSK Fmin=950MHz Fmax=2150MHz
    DEVICE:0 ADAPTER:6 FRONTEND:0 (CXD2843 DVB-C/C2 DVB-T/T2) 
         FE_QAM Fmin=47MHz Fmax=865MHz

[catalinii]

Can you reproduce the issue?

[9000h]

yes, it's still happen also with the git from today.

[catalinii]

What is going on on the clinet side?

[9000h]

nothing really special except the RTP error, but I did test over WLAN I do use the fork https://github.com/REELcoder/vdr-plugin-satip as the there is a silly bug upstream

Dec 31 13:44:49 localhost vdr: [9883] SATIP poller thread started (pid=9880, tid=9883, prio=high)
Dec 31 13:44:49 localhost vdr: [9880] SATIP: Adding server '192.168.178.129|DVBS2-4,DVBC-2,DVBT2-2,DVBC2-2|minisatip' Bind: default Filters: none CI: yes Quirks: RtpOverTcp,CiXpmt
Dec 31 13:44:49 localhost vdr: [9880] SATIP: Creating device CardIndex=0 DeviceNumber=0 [device 0]
Dec 31 13:44:49 localhost vdr: [9884] SATIP#0 tuner thread started (pid=9880, tid=9884, prio=high)
Dec 31 13:44:49 localhost vdr: [9885] SATIP#0 section handler thread started (pid=9880, tid=9885, prio=high)
Dec 31 13:44:49 localhost vdr: [9880] SATIP: Creating device CardIndex=1 DeviceNumber=1 [device 1]
Dec 31 13:44:49 localhost vdr: [9887] SATIP#1 tuner thread started (pid=9880, tid=9887, prio=high)
Dec 31 13:44:49 localhost vdr: [9888] SATIP#1 section handler thread started (pid=9880, tid=9888, prio=high)
Dec 31 13:44:50 localhost vdr: [9880] SATIP: Using CURL 7.64.0 rtsp
Dec 31 13:44:53 localhost vdr: [9883] SATIP: Detected 1 RTP packet error [device 0]
Dec 31 13:45:21 localhost vdr: [9883] SATIP poller thread ended (pid=9880, tid=9883)
Dec 31 13:45:21 localhost vdr: [9885] SATIP#0 section handler thread ended (pid=9880, tid=9885)
Dec 31 13:45:21 localhost vdr: [9884] SATIP#0 tuner thread ended (pid=9880, tid=9884)
Dec 31 13:45:22 localhost vdr: [9888] SATIP#1 section handler thread ended (pid=9880, tid=9888)
Dec 31 13:45:22 localhost vdr: [9887] SATIP#1 tuner thread ended (pid=9880, tid=9887)
``

[catalinii]

Does this happen if you use wget http://parameters..?

[9000h]

I did not notice this when using http up to now. The strange is when it happens there are still some udp packet coming through but only 60 bytes per packet and every second. RTCP is fine. .

[9000h]

a capture of the issue

no-data-1s.pcapng.gz no-data-1s.log.gz

on the client side VDR satip plugin Jan 8 22:30:58 localhost vdr: [21375] SATIP poller thread started (pid=21372, tid=21375, prio=high) Jan 8 22:31:01 localhost vdr: [21375] SATIP: Detected 1 RTP packet error [device 0] Jan 8 22:34:12 localhost vdr: [21375] SATIP: Detected 1 RTP packet error [device 1] Jan 8 22:36:54 localhost vdr: [21375] SATIP poller thread ended (pid=21372, tid=21375

my impression is it could be also a client issue.

[lars18th]

The strange is when it happens there are still some udp packet coming through but only 60 bytes per packet and every second.

This is an empty RTP packet (12 bytes is the length of the RTP header).

my impression is it could be also a client issue.

My impression is the opposite. I see this kind of errors time to time in my environment, and I don't use VDR at all. Perhaps the problem is related to this: if the incoming stream fails for any hidden reason (perhaps a bug), then the output stream sends an empty RTP packet when an internal flush command is triggered. Please @catalinii can you check this?

[9000h]

I would expect if there is a RTP packet coming from minisatip than it's a valid one in any case and not a header only, so there is a issue anyway in that case, The RTCP packet are fine at the same time.

[lars18th]

I would expect if there is a RTP packet coming from minisatip than it's a valid one in any case and not a header only, so there is a issue anyway in that case, The RTCP packet are fine at the same time.

Sure! An empty RTP packet from the minisatip is an error.

[lars18th]

Hi @9000h ,

The empty packet is generated by this line: https://github.com/catalinii/minisatip/blob/43ec825a76b40bb506d05d0c4c6ef23a0a6c85ba/src/stream.c#L1154

So, this special packet is generated only when this message appears. And then is not a bug, it's only a KEEP empty RTP packet.

In any case the problem is to determine the cause of the empty input stream. I see this time to time. And my feeling is that something about pid filtering is running bad. Perhaps some workaround can be done to restart the reading stream when this message appears. What do you think @catalinii ?

[9000h]

so this seems to be the only known major bug now, and we should give it priority we have at least me and @lars18th seeing this issue, but I believe there are more users out which do not care what's in the logs. maybe we can abstract the debug a bit better to get behind the issue. on my side I do have DD cards with the git dddvb driver on kernel 5.3 and do not use minisatip as client. what can we try? different kernel, I can try with 4.15.0-74-generic strace -tts on the sockets? ...

[lars18th]

so this seems to be the only known major bug now, and we should give it priority

With one exception: another major bug is the jitter problem using the SAT>IP client mode. But if you use internal tuner cards only, then that's true!

we have at least me and @lars18th seeing this issue, but I believe there are more users out which do not care what's in the logs. maybe we can abstract the debug a bit better to get behind the issue. on my side I do have DD cards with the git dddvb driver on kernel 5.3 and do not use minisatip as client. what can we try? different kernel, I can try with 4.15.0-74-generic strace -tts on the sockets? ...

My environment is very different: old debian 7 64bit in a low power x64 system shared with other processes, and reading everytime from a low budget SAT>IP server (in fact a STB). So I'm quite sure the problem is not related with the kernel/network. The problem is inside the internal logic: at some point the stream readed from the DVR socket it's incorrectly filtered.

To prove my assumption a simple test can be used: put some hardcoded lines to pass everytime a fixed list of pids. For example pids 0 and 8191. Using these pids it's expected to receive almost 1 packet every second. So if the message appears, then some bug in the loop exists.

What do you think @catalinii ?

[catalinii]

So the empty packet is not really a bug, but according to the specs it needs to be sent every second (see the code @lars18th pointed out).

The real problem is that the stream stops. To be able to confirm this, feel free to add -l dmx or -v dmx, you should see the log line from: https://github.com/catalinii/minisatip/blob/master/src/stream.c#L1075

If those stops then minisatip is not reading. If that is the case a strace can help: strace -f -s 200 -o /tmp/file.out ./minisatip ...

[catalinii]

You can try wget ... you may not be able to reproduce it. I think it may be driver related.

[lars18th]

So the empty packet is not really a bug, but according to the specs it needs to be sent every second (see the code @lars18th pointed out).

Hi @catalinii . I'm not sure where the specs say this. Please, can you point them? I feel the requirement is to send one packet almost every second... but a TS packet, not a RTP packet. So instead of an empty RTP perhaps you need to send a RTP packet with one NULL TS packet (pid 8191). Can you please confirm this?

[9000h]

should ad->dvr not set to -1 here https://github.com/catalinii/minisatip/blob/c6fa544f386acb9d14f7da74b43c89e4bce0d007/src/adapter.c#L456 and ad->dmx also

[9000h]

I believe I have found a way to reproduce the issue with VDR, if I watch a channel on DVB-C for at least 5 minutes and then switch to a DVB-S channel then I got no picture and the "no data" did start on the DVB-S adapter. I did also try different driver version on different kernels and setting the adapter timeout to "--adapter-timeout *:0", but nothing helps.

[catalinii]

@lars18th , section 3.5.3: "The content of the delivered data depends on the actual tuning process. If the media stream object was fully and correctly defined in the SETUP and PLAY process, the requested satellite data will be available. If however no signal is available, the signal is lost or the media object was not correctly defined (e.g. no PIDs available), the server will nevertheless deliver an empty RTP packet (not containing a TS packet) every 100 ms. The RTCP data stream will also be available in parallel and indicate the data and signal characteristics."

@9000h can you reproduce with wget ?

Also correct for ad->dvr = -1 (and ad->dmx = -1)

[lars18th]

@lars18th , section 3.5.3: "The content of the delivered data depends on the actual tuning process. If the media stream object was fully and correctly defined in the SETUP and PLAY process, the requested satellite data will be available. If however no signal is available, the signal is lost or the media object was not correctly defined (e.g. no PIDs available), the server will nevertheless deliver an empty RTP packet (not containing a TS packet) every 100 ms. The RTCP data stream will also be available in parallel and indicate the data and signal characteristics."

:+1: Thank you @catalinii ! Then in this case I suggest to change the timeout to 100ms, instead of 1sec. So, here:

https://github.com/catalinii/minisatip/blob/f4a3400980a803e014ed29deee451121f47f7e70/src/stream.c#L1184-L1189

change to if (sid->do_play && ctime - rtime > 100) and flush every time, but log every second only.

You agree?

[9000h]

is this anything harmful

Jan 12 22:59:39 localhost minisatip[2363]: [12/01 22:59:39.947 AD6]: mutex_leak: Expected 0x55a6690e4d88 got 0x55a6690c0ea8
Jan 12 22:59:39 localhost minisatip[2363]: [12/01 22:59:39.947 AD6]: leak detected 0 1!!!
Jan 12 23:00:38 localhost minisatip[2363]: [12/01 23:00:38.826 AD6]: mutex_leak: Expected 0x55a6690e4d88 got 0x55a6690c0ea8
Jan 12 23:00:38 localhost minisatip[2363]: [12/01 23:00:38.826 AD6]: leak detected 0 1!!!
Jan 12 23:00:42 localhost minisatip[2363]: [12/01 23:00:42.533 AD6]: mutex_leak: Expected 0x55a6690e4d88 got 0x55a6690c0ea8
Jan 12 23:00:42 localhost minisatip[2363]: [12/01 23:00:42.533 AD6]: leak detected 0 1!!!
Jan 12 23:00:43 localhost minisatip[2363]: [12/01 23:00:43.138 AD6]: mutex_leak: Expected 0x55a6690e4d88 got 0x55a6690c0ea8
Jan 12 23:00:43 localhost minisatip[2363]: [12/01 23:00:43.138 AD6]: leak detected 0 1!!!
Jan 12 23:00:53 localhost minisatip[2363]: [12/01 23:00:53.403 AD6]: mutex_leak: Expected 0x55a6690e4d88 got 0x55a6690c0ea8
Jan 12 23:00:53 localhost minisatip[2363]: [12/01 23:00:53.403 AD6]: leak detected 0 1!!!
Jan 12 23:04:22 localhost minisatip[2363]: [12/01 23:04:22.861 AD6]: mutex_leak: Expected 0x55a6690e4d88 got 0x55a6690c0ea8
Jan 12 23:04:22 localhost minisatip[2363]: [12/01 23:04:22.861 AD6]: leak detected 0 1!!!
Jan 12 23:09:41 localhost minisatip[2363]: [12/01 23:09:41.876 AD7]: mutex_leak: Expected 0x55a6690eabb8 got 0x55a6690e5978
Jan 12 23:09:41 localhost minisatip[2363]: [12/01 23:09:41.876 AD7]: leak detected 0 1!!!

[9000h]

I'm still testing and try to isolate/reproduce the issue, but PR https://github.com/catalinii/minisatip/pull/695 seem to fix it.

[9000h]

should this not consistent int64_t or uint64_t ?

grep "int64_t ctime" *.c
ddci.c: uint64_t ctime = getTick();
dvbapi.c:       uint64_t ctime = getTick();
pmt.c:  int64_t ctime = getTick();
pmt.c:  int64_t ctime = getTick();
pmt.c:  uint64_t ctime = getTick();
pmt.c:  uint64_t ctime = getTick();
pmt.c:  int64_t ctime = getTick();
pmt.c:                  int64_t ctime = getTick();
satipc.c:   int64_t ctime = getTick();
stream.c:int send_rtcp(int s_id, int64_t ctime)
stream.c:int flush_stream(streams *sid, struct iovec *iov, int iiov, int64_t ctime)
stream.c:   int64_t ctime, rttime, rtime;

and also

grep "int64_t rtime" *.c
adapter.c:  int64_t rtime = getTick(), max_close = rtime - ad->adapter_timeout + 2000;
stream.c:   int64_t rtime = ad->rtime;
stream.c:   uint64_t rtime = getTick();

pmt.h:  uint64_t time;

[catalinii]

Yes it should be int64_t.

Do you understand why the stream stops and how the PR fixes it?

[9000h]

unfortunately I'm still try to catch the root cause, but the PR seem to help a bit

[9000h]

there was something strange in my logs

SERVER_ARGS=" -D5 -o 192.168.178.129:2000 -Y 4:dvbt2,5:dvbt2,6:dvbc2,7:dvbc2 -u 0:4-984[-48],1:5-1020[-23],2:6-1056[-88],3:7-1092[-204] -m 0040caa2c79d  -l general,http,dmx"

ver=1.2;tuner=1 this should be only tuner 7 or 8 for dvbc as all the others, it seems there get something mixed up intermitted

Jan 15 00:27:36 localhost minisatip[11297]: a=fmtp:33 ver=1.2;tuner=7,0,0,0,450.00,8,dvbc,256qam,6900,0,,,;pids=
Jan 15 00:28:43 localhost minisatip[11297]: a=fmtp:33 ver=1.2;tuner=1,255,1,15,114.00,8,dvbc,256qam,6900,0,,,;pids=
Jan 15 00:34:30 localhost minisatip[11297]: a=fmtp:33 ver=1.2;tuner=8,0,0,0,570.00,8,dvbc,256qam,6900,0,,,;pids=
Jan 15 00:34:43 localhost minisatip[11297]: a=fmtp:33 ver=1.2;tuner=8,0,0,0,450.00,8,dvbc,256qam,6900,0,,,;pids=
Jan 15 00:35:46 localhost minisatip[11297]: a=fmtp:33 ver=1.2;tuner=7,0,0,0,450.00,8,dvbc,256qam,6900,0,,,;pids=
Jan 15 00:35:52 localhost minisatip[11297]: a=fmtp:33 ver=1.2;tuner=8,0,0,0,570.00,8,dvbc,256qam,6900,0,,,;pids=

[9000h]

hmm

Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.519 main]: SETUP rtsp://192.168.178.129/?freq=114&msys=dvbc&mtype=256qam&sr=6900 RTSP/1.0
Jan 15 00:28:43 localhost minisatip[11297]: CSeq: 2
Jan 15 00:28:43 localhost minisatip[11297]: Transport: RTP/AVP;unicast;client_port=47132-47133
Jan 15 00:28:43 localhost minisatip[11297]: User-Agent: vdr-satip/2.4.1-GIT-826dea4 (device 1)
Jan 15 00:28:43 localhost minisatip[11297]: #015
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.519 main]: detect_dvb_parameters (S)-> freq=114&msys=dvbc&mtype=256qam&sr=6900
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.519 main]: detect_dvb_parameters (E) -> src=0, fe=0, freq=114000, fec=9, sr=6900000, pol=0, ro=3, msys=1, mtype=5, plts=2, bw=8000000, inv=2, pids=NULL - apids=NULL - dpids=NULL x_pmt=NULL
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.519 main]: Setup stream -1 parameters, sock_id 13, handle 13
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.519 main]: stream.c:200 get_sid returns NULL for s_id = -1
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.519 main]: Mutex init 0x555574030088
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.519 main]: set_sock_lock: sock_id 13 locks also mutex 0x555574030088
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.519 main]: Mutex init 0x555574028828
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.519 main]: sockets_add: handle -2 (type 0) returning socket sock 14 [:0] read: 0x5555735231b7
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.519 main]: set_sock_lock: sock_id 14 locks also mutex 0x555574030088
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.519 main]: Setup stream done: sid: 1 for sock 13 handle 13
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: copy_dvb_param start -> src=0, fe=0, freq=0, fec=9, sr=0, pol=0, ro=3, msys=0, mtype=6, plts=2, bw=8000000, inv=2, pids=NULL, apids=NULL, dpids=NULL x_pmt=NULL
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: copy_dvb_parameters -> src=1, fe=0, freq=114000, fec=9 sr=6900000, pol=0, ro=3, msys=1, mtype=5, plts=2, bw=8000000, inv=2, pids=NULL, apids=NULL, dpids=NULL x_pmt=NULL
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: Updating stream 1 time to 9277354, current time 9277354
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: decode_transport ->type 2, ttl 0 new socket to: 192.168.178.114:47132
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: New UDP socket 21 bound to 0.0.0.0:5502
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: New UDP socket 21 connected to 192.168.178.114:47132
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: Mutex init 0x555574028ac8
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: sockets_add: handle 21 (type 0) returning socket sock 15 [192.168.178.114:47132] read: 0x5555735231b7
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: output socket buffer size for socket 21 is 1048576 bytes
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: New UDP socket 25 bound to 0.0.0.0:5503
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: New UDP socket 25 connected to 192.168.178.114:47133
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: Mutex init 0x555574028c28
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: sockets_add: handle 25 (type 6) returning socket sock 16 [192.168.178.114:47133] read: 0x5555735231b7
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: reply -> 13 (192.168.178.114:46650) CL:0 [sock_id 13]:
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.520 main]: RTSP/1.0 200 OK
Jan 15 00:28:43 localhost minisatip[11297]: Date: Tue, Jan 14 23:28:43 2020 GMT
Jan 15 00:28:43 localhost minisatip[11297]: CSeq: 2
Jan 15 00:28:43 localhost minisatip[11297]: Server: minisatip/1.0.2-c6fa544
Jan 15 00:28:43 localhost minisatip[11297]: Transport: RTP/AVP;unicast;destination=192.168.178.114;source=192.168.178.129;client_port=47132-47133;server_port=5502-5503
Jan 15 00:28:43 localhost minisatip[11297]: Session: 0943947739;timeout=30
Jan 15 00:28:43 localhost minisatip[11297]: com.ses.streamID: 2
Jan 15 00:28:43 localhost minisatip[11297]: #015
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.525 main]: read RTSP (from handle 13 sock 13, len: 160, sid 1):
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.525 main]: DESCRIBE rtsp://192.168.178.129/stream=2 RTSP/1.0
Jan 15 00:28:43 localhost minisatip[11297]: CSeq: 3
Jan 15 00:28:43 localhost minisatip[11297]: Session: 0943947739
Jan 15 00:28:43 localhost minisatip[11297]: Accept: application/sdp
Jan 15 00:28:43 localhost minisatip[11297]: User-Agent: vdr-satip/2.4.1-GIT-826dea4 (device 1)
Jan 15 00:28:43 localhost minisatip[11297]: #015
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.525 main]: Updating stream 1 time to 9277360, current time 9277360
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.525 main]: adapter.c:1334: get_adapter returns NULL for adapter_id -1
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.525 main]: reply -> 13 (192.168.178.114:46650) CL:241 [sock_id 13]:
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.525 main]: RTSP/1.0 200 OK
Jan 15 00:28:43 localhost minisatip[11297]: Date: Tue, Jan 14 23:28:43 2020 GMT
Jan 15 00:28:43 localhost minisatip[11297]: Session: 0943947739
Jan 15 00:28:43 localhost minisatip[11297]: CSeq: 3
Jan 15 00:28:43 localhost minisatip[11297]: Server: minisatip/1.0.2-c6fa544
Jan 15 00:28:43 localhost minisatip[11297]: Content-type: application/sdp
Jan 15 00:28:43 localhost minisatip[11297]: Content-Base: rtsp://192.168.178.129/
Jan 15 00:28:43 localhost minisatip[11297]: Content-Length: 241
Jan 15 00:28:43 localhost minisatip[11297]: #015
Jan 15 00:28:43 localhost minisatip[11297]: v=0
Jan 15 00:28:43 localhost minisatip[11297]: o=- 0943947739 0943947739 IN IP4 192.168.178.129
Jan 15 00:28:43 localhost minisatip[11297]: s=SatIPServer:1 4,2,2
Jan 15 00:28:43 localhost minisatip[11297]: t=0 0
Jan 15 00:28:43 localhost minisatip[11297]: m=video 0 RTP/AVP 33
Jan 15 00:28:43 localhost minisatip[11297]: c=IN IP4 0.0.0.0
Jan 15 00:28:43 localhost minisatip[11297]: a=control:stream=2
Jan 15 00:28:43 localhost minisatip[11297]: a=fmtp:33 ver=1.2;tuner=1,255,1,15,114.00,8,dvbc,256qam,6900,0,,,;pids=
Jan 15 00:28:43 localhost minisatip[11297]: b=AS:5000
Jan 15 00:28:43 localhost minisatip[11297]: a=inactive

.....
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: PLAY rtsp://192.168.178.129/stream=2?addpids=0,18,20 RTSP/1.0
Jan 15 00:28:43 localhost minisatip[11297]: CSeq: 4
Jan 15 00:28:43 localhost minisatip[11297]: Session: 0943947739
Jan 15 00:28:43 localhost minisatip[11297]: User-Agent: vdr-satip/2.4.1-GIT-826dea4 (device 1)
Jan 15 00:28:43 localhost minisatip[11297]: #015
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: detect_dvb_parameters (S)-> addpids=0,18,20
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: detect_dvb_parameters (E) -> src=-1, fe=-1, freq=-1, fec=-1, sr=-1, pol=-1, ro=-1, msys=-1, mtype=-1, plts=-1, bw=-1, inv=-1, pids=NULL - apids=0,18,20 - dpids=NULL x_pmt=NULL
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: Setup stream 1 parameters, sock_id 13, handle 13
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: copy_dvb_param start -> src=1, fe=0, freq=114000, fec=9, sr=6900000, pol=0, ro=3, msys=1, mtype=5, plts=2, bw=8000000, inv=2, pids=NULL, apids=NULL, dpids=NULL x_pmt=NULL
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: copy_dvb_parameters -> src=1, fe=0, freq=114000, fec=9 sr=6900000, pol=0, ro=3, msys=1, mtype=5, plts=2, bw=8000000, inv=2, pids=NULL, apids=0,18,20, dpids=NULL x_pmt=NULL
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: Updating stream 1 time to 9277615, current time 9277615
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: Play for stream 1, type 2, rsock 21, adapter -1, sock_id 13, rsock_id 15, handle 13
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: stream.c:271: get_adapter returns NULL for adapter_id -1
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: adapter.c:1185: get_adapter returns NULL for adapter_id -1
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: adapter.c:2223: get_adapter returns NULL for adapter_id -1
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: stream.c:280: get_adapter returns NULL for adapter_id -1
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: get free adapter 0 - a[0] => e:1 m:0 sid_cnt:1 f:11229000 pol=1 sys: dvbs undefined
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: Mutex init 0x555573f8d0a8
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.780 main]: trying to open [6] adapter 6 and frontend 0
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.782 main]: opened DVB adapter 6 fe:12 dvr:26
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.784 main]: DVR buffer set to 5775360 bytes
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: deleting pids on adapter 6, sid -1, pids=NULL
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: Mutex init 0x555574029978
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: sockets_add: handle 26 (type 5) returning socket sock 17 [:0] read: 0x55557352310e
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: set_socket_thread: thread 7fecabfff700 for sockets 17
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 AD6]: Starting select_and_execute on thread ID 7fecabfff700, thread_name AD6
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: No CA device detected on adapter 6: file /dev/dvb/adapter6/ca0
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: done opening adapter 6 delivery systems: dvbc2 dvbc undefined undefined
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: Got adapter 6 on stream 1 socket 13
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: set adapter 6 for stream 1 m:1 s:1
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: setting DVB parameters for adapter 6 - master_sid 1 sid 1 old f:0
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: deleting pids on adapter 6, sid -1, pids=NULL
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: copy_dvb_param start -> src=0, fe=0, freq=0, fec=9, sr=0, pol=0, ro=3, msys=0, mtype=6, plts=2, bw=8000000, inv=2, pids=NULL, apids=NULL, dpids=NULL x_pmt=NULL
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: copy_dvb_parameters -> src=1, fe=0, freq=114000, fec=9 sr=6900000, pol=0, ro=3, msys=1, mtype=5, plts=2, bw=8000000, inv=2, pids=NULL, apids=0,18,20, dpids=NULL x_pmt=NULL
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: adding pids to adapter 6, sid 1, pids=0,18,20
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: Dumping pids table for adapter 6, pid unknown 0
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: pid 0, fd 0, packets 13, d/c errs 0/0, flags 2, pmt -1, filter -1, sock -1, sids: 1 -1 -1 -1 -1 -1 -1 -1
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: pid 18, fd 0, packets 0, d/c errs 0/0, flags 2, pmt -1, filter -1, sock -1, sids: 1 -1 -1 -1 -1 -1 -1 -1
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: pid 20, fd 0, packets 11209, d/c errs 0/0, flags 2, pmt -1, filter -1, sock -1, sids: 1 -1 -1 -1 -1 -1 -1 -1
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: set_socket_thread: thread 7fecabfff700 for sockets 14
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: tuning to 114000000 sr:6900000 specinv:  delsys:dvbc mod:256qam ts clear = 9277620
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: deleting PMT 2, master PMT 2, name rbb Berlin HD
Jan 15 00:28:43 localhost minisatip[11297]: [15/01 00:28:43.785 main]: Destroying mutex 0x7fecb4005a48

[lars18th]

Hi @9000h ,

hmm

Sure you found a bug! The Stream 2, created after the SETUP is assigned to the tuner=1, that is not DVB-C. So the problem is related to the description of the tuner or with the selection function.

However, I feel the problem is different: after the SETUP command, the stream isn't running. So it isn't assigned to any tuner. Then the DECRIBE command sends and incorrect tuner, as it uses the initializacion value (1). So only after the PLAY command the tuner is correct.

I suggest to @catalinii to change this behaviour. Use -1 as the tuner initialization number, and when a DESCRIBE command is received and the stream is not playing (detected with the undefined tuner) then compose the response based on the real status (no tuner assigned).

I hope it helps.

[9000h]

hmm, tuner= is may not that important as clients should not use it under normal conditions, but the value must be 1-65535. what should happen is to show the wrong ver=1.x as some client may use it in a way we can only guess like the Panasonic TV's :-)

[9000h]

the only issue is as long as the stream is not active/play the adapter in unknown, all the other params are already in tp, so ver=1.2 for dvbc etc from setup_stream are fine a=fmtp:33 ver=1.2;tuner=1,255,1,15,114.00,8,dvbc,256qam,6900,0,,,;pids= https://github.com/catalinii/minisatip/blob/c6fa544f386acb9d14f7da74b43c89e4bce0d007/src/adapter.c#L1386-L1388 signal by sendonly (adapter assigned) and no signal by inactive and no adapter assigned is explained here: https://github.com/catalinii/minisatip/blob/c6fa544f386acb9d14f7da74b43c89e4bce0d007/src/adapter.c#L1327

Jan 15 00:28:43 localhost minisatip[11297]: a=control:stream=2
Jan 15 00:28:43 localhost minisatip[11297]: a=fmtp:33 ver=1.2;tuner=1,255,1,15,114.00,8,dvbc,256qam,6900,0,,,;pids=
Jan 15 00:28:43 localhost minisatip[11297]: b=AS:5000
Jan 15 00:28:43 localhost minisatip[11297]: a=inactive

.....

Jan 15 00:35:52 localhost minisatip[11297]: a=control:stream=1
Jan 15 00:35:52 localhost minisatip[11297]: a=fmtp:33 ver=1.2;tuner=8,0,0,0,570.00,8,dvbc,256qam,6900,0,,,;pids=
Jan 15 00:35:52 localhost minisatip[11297]: b=AS:5000
Jan 15 00:35:52 localhost minisatip[11297]: a=sendonly

same can happen to different delsys like DVB-T2 here (should be tuner=5 or 6 in my case)

Jan 12 23:00:59 localhost minisatip[2363]: a=fmtp:33 ver=1.1;tuner=1,255,1,15,554.00,8,dvbt2,16k,qpsk,19128,,0,0,0;pids=
Jan 12 23:03:09 localhost minisatip[2363]: a=fmtp:33 ver=1.1;tuner=1,255,1,15,554.00,8,dvbt2,,,,23,,0,0;pids=0,4112,4113,4114,4115,4116
Jan 12 23:03:26 localhost minisatip[2363]: a=fmtp:33 ver=1.1;tuner=1,255,1,15,554.00,8,dvbt2,,,,23,,0,0;pids=0,4112,4113,4114,4115,4116

I have no idea how we can have a correct value for tuner= here, maybe the first adapter per delsys as workaround. or should we ignore it? @catalinii do you have any idea?

[9000h]

additionally I have found this one on DVB-C, I have a channel in which got maybe automatically add by VDR to the channels.conf

this channel is from my DVB-C provider described as

D114 114 MHz | Downstream für Video-on-Demand (256QAM, 6900 KSym/s)

wget "http://192.168.178.129:8080/?freq=114&msys=dvbc&mtype=256qam&sr=6900;pids=0" -O /dev/null the stream did not start as there is nothing coming from read_dmx (same with rtsp)

I believe this is correct, but it is one situation where tuning is fine but no data from read_dmx. the request will not stop or log the "no data"

Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 main]: copy_dvb_param start -> src=0, fe=0, freq=0, fec=9, sr=0, pol=0, ro=3, msys=0, mtype=6, plts=2, bw=8000000, inv=2, pids=NULL, apids=NULL, dpids=NULL x_pmt=NULL
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 main]: copy_dvb_parameters -> src=1, fe=0, freq=114000, fec=9 sr=6900000, pol=0, ro=3, msys=1, mtype=5, plts=2, bw=8000000, inv=2, pids=NULL, apids=NULL, dpids=NULL x_pmt=NULL
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 main]: set_socket_thread: thread 7fecab7fe700 for sockets 8
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 main]: tuning to 114000000 sr:6900000 specinv:  delsys:dvbc mod:256qam ts clear = 66059503
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 main]: Adding pid 0 to the list of pids as not explicitly added for adapter 6
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 main]: Dumping pids table for adapter 6, pid unknown 0
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 main]: pid 0, fd 0, packets 1198, d/c errs 0/0, flags 2, pmt -1, filter 4, sock -1, sids: -1 -1 -1 -1 -1 -1 -1 -1
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 main]: pid 4096, fd 0, packets 650, d/c errs 0/0, flags 2, pmt -1, filter -1, sock -1, sids: -1 -1 -1 -1 -1 -1 -1 -1
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 AD6]: Starting select_and_execute on thread ID 7fecab7fe700, thread_name AD6
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 main]: AD 6 [demux 6 0], setting filter on PID 0 for fd 10
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 main]: AD 6 [demux 6 0], setting filter on PID 4096 for fd 11
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 main]: reply -> 7 (192.168.178.129:40206) CL:0 [sock_id 7]:
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.649 main]: HTTP/1.0 200 OK
Jan 15 16:15:05 localhost minisatip[11297]: Date: Wed, Jan 15 15:15:05 2020 GMT
Jan 15 16:15:05 localhost minisatip[11297]: Server: minisatip/1.0.2-c6fa544
Jan 15 16:15:05 localhost minisatip[11297]: Content-Type: video/mp2t
Jan 15 16:15:05 localhost minisatip[11297]: Connection: close
Jan 15 16:15:05 localhost minisatip[11297]: #015
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.750 main]: New TCP socket 12 connected to 192.168.178.129:2000
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.750 main]: Mutex init 0x555573fe1528
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.750 main]: sockets_add: handle 12 (type 1) returning socket sock 10 [:0] read: 0x55557352310e
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.750 main]: select_and_execute[10]: Connected on socket 12 (sid:-1) from :0 - type tcp errno 11
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.750 main]: dvbapi read from socket 12 the following data (73 bytes), pos = 0, op FFFF0002, key 0
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.750 main]: dvbapi: server version 3, build 11571, found, name = OSCam v1.20_svn, build r11571 (x86_64-linux-gnu-ssl-libusb-pcsc);
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.885 AD6]: read_dmx send=1, flush_all=1, cnt 0 called for adapter 6 -> 188 out of 72192 bytes read, 236 ms ago (66059739 66059503)
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.885 AD6]: process_dmx start called for adapter 6 -> 188 out of 72192 bytes read, 236 ms ago
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.886 AD6]: PAT Adapter 6, Transponder ID 36692, version 2, len -1
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.886 AD6]: Processing done sid 0 at pos 0, rtp header 0, rtp_pos 0, total_len 0, rlen 188
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.985 AD6]: read_dmx send=1, flush_all=1, cnt 0 called for adapter 6 -> 188 out of 72192 bytes read, 100 ms ago (66059839 66059739)
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.985 AD6]: process_dmx start called for adapter 6 -> 188 out of 72192 bytes read, 100 ms ago
Jan 15 16:15:05 localhost minisatip[11297]: [15/01 16:15:05.985 AD6]: Processing done sid 0 at pos 0, rtp header 0, rtp_pos 0, total_len 0, rlen 188
Jan 15 16:15:06 localhost minisatip[11297]: [15/01 16:15:06.084 AD6]: read_dmx send=1, flush_all=1, cnt 0 called for adapter 6 -> 188 out of 72192 bytes read, 99 ms ago (66059938 66059839)
Jan 15 16:15:06 localhost minisatip[11297]: [15/01 16:15:06.084 AD6]: process_dmx start called for adapter 6 -> 188 out of 72192 bytes read, 99 ms ago
Jan 15 16:15:06 localhost minisatip[11297]: [15/01 16:15:06.084 AD6]: Processing done sid 0 at pos 0, rtp header 0, rtp_pos 0, total_len 0, rlen 188
Jan 15 16:15:06 localhost minisatip[11297]: [15/01 16:15:06.118 signal]: get_signal_new took 2 ms for adapter 6 handle 8 (status: 31, ber: 0, strength:108, snr: 0, force scan 0)
Jan 15 16:15:06 localhost minisatip[11297]: [15/01 16:15:06.183 AD6]: read_dmx send=1, flush_all=1, cnt 0 called for adapter 6 -> 188 out of 72192 bytes read, 99 ms ago (66060037 66059938)
J

[9000h]

I may have catch it when the client try an a in session change to a non working/unused transponder like src=2 is Hotbird 13E

PLAY rtsp://192.168.178.129/stream=2?src=2&freq=11137&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=27500&fec=34 RTSP/1.0

VDR send then DESCRIBE but there is no lock

an 15 22:36:35 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,0,0,0,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:36 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,0,0,0,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:37 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:39 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:40 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:41 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:42 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:43 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:44 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:45 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:46 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:47 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:48 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:49 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:50 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:51 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:52 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:53 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:54 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:55 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=
Jan 15 22:36:56 localhost minisatip[17951]: a=fmtp:33 ver=1.0;src=2;tuner=1,254,0,15,11137,h,dvbs,qpsk,off,0.35,27500,34;pids=

any comments/ideas ?

[catalinii]

[15/01 00:28:43.525 main]: adapter.c:1334: get_adapter returns NULL for adapter_id -1 Which means adapter is invalid (-1). Then: https://github.com/catalinii/minisatip/blob/master/src/adapter.c#L1335 aid->0 When the tuner is printed, (ad && ad->tp.fe > 0) ? ad->tp.fe : aid + 1 is evaluated as aid + 1 which is 1. Yes the issues is that the adapter parameters are unknown, but if you find something useful in the specs how to handle this case, we can change the code.

[lars18th]

Yes the issues is that the adapter parameters are unknown, but if you find something useful in the specs how to handle this case, we can change the code.

Hi @catalinii ,

I'm not sure about this, but I feel the specs have this sense: when a new SETUP command is recived (a new is when no stream is asigned to it), the server creates a new stream. And then after a PLAY is received a tuner is assigned to the stream. And this is not dificult to handle. When the adapter_id is -1 (that's before a tuner is assigned) the DESCRIBE command requires to be in correspondence with the MSYS requested in the SETUP. So, if your tuner 1 is DVB-S2 and tuner 2 is DVB-C, then a SETUP of DVB-C requires to use some DVB-C tuner (in this case 2). Even if the adapter_id continues to be -1.

I hope it helps.

[9000h]

for the DESCRIBE I do not have any good idea atm

[9000h]

how can this happen?

Jan 16 18:05:03 localhost minisatip[30775]: [16/01 18:05:03.071 signal]: get_signal_new took 1 ms for adapter 6 handle -1 (status: 0, ber: 0, strength:103, snr: 92, force scan 0)

and later on

Jan 16 18:10:55 localhost minisatip[30775]: [16/01 18:10:55.308 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:10:56 localhost minisatip[30775]: [16/01 18:10:56.311 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:10:57 localhost minisatip[30775]: [16/01 18:10:57.413 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:10:58 localhost minisatip[30775]: [16/01 18:10:58.416 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:10:59 localhost minisatip[30775]: [16/01 18:10:59.518 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:00 localhost minisatip[30775]: [16/01 18:11:00.520 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:01 localhost minisatip[30775]: [16/01 18:11:01.723 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:02 localhost minisatip[30775]: [16/01 18:11:02.725 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:03 localhost minisatip[30775]: [16/01 18:11:03.728 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:04 localhost minisatip[30775]: [16/01 18:11:04.730 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:05 localhost minisatip[30775]: [16/01 18:11:05.732 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:06 localhost minisatip[30775]: [16/01 18:11:06.834 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:07 localhost minisatip[30775]: [16/01 18:11:07.836 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:08 localhost minisatip[30775]: [16/01 18:11:08.839 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:09 localhost minisatip[30775]: [16/01 18:11:09.941 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:10 localhost minisatip[30775]: [16/01 18:11:10.944 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:12 localhost minisatip[30775]: [16/01 18:11:12.046 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:13 localhost minisatip[30775]: [16/01 18:11:13.048 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:14 localhost minisatip[30775]: [16/01 18:11:14.251 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:15 localhost minisatip[30775]: [16/01 18:11:15.254 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:16 localhost minisatip[30775]: [16/01 18:11:16.931 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:18 localhost minisatip[30775]: [16/01 18:11:18.033 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:19 localhost minisatip[30775]: [16/01 18:11:19.036 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:20 localhost minisatip[30775]: [16/01 18:11:20.138 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:21 localhost minisatip[30775]: [16/01 18:11:21.141 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:22 localhost minisatip[30775]: [16/01 18:11:22.143 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:23 localhost minisatip[30775]: [16/01 18:11:23.245 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:24 localhost minisatip[30775]: [16/01 18:11:24.248 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:25 localhost minisatip[30775]: [16/01 18:11:25.250 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:26 localhost minisatip[30775]: [16/01 18:11:26.352 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:27 localhost minisatip[30775]: [16/01 18:11:27.355 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:28 localhost minisatip[30775]: [16/01 18:11:28.457 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:29 localhost minisatip[30775]: [16/01 18:11:29.459 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:30 localhost minisatip[30775]: [16/01 18:11:30.462 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:31 localhost minisatip[30775]: [16/01 18:11:31.564 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:32 localhost minisatip[30775]: [16/01 18:11:32.767 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:33 localhost minisatip[30775]: [16/01 18:11:33.769 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:34 localhost minisatip[30775]: [16/01 18:11:34.772 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:35 localhost minisatip[30775]: [16/01 18:11:35.874 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:36 localhost minisatip[30775]: [16/01 18:11:36.876 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398
Jan 16 18:11:38 localhost minisatip[30775]: [16/01 18:11:37.998 AD6]: no data sent for more than 1s sid: 1 for 192.168.178.114:36398

[9000h]

this log seem to be a good example log.txt.gz could it be a simple lock issue? Jan 16 22:13:43 localhost minisatip[24422]: [16/01 22:13:43.708 signal]: get_signal_new took 288 ms for adapter 0 handle 10 (status: 0, ber: 0, strength:255, snr: 248, force scan 0)

another example is this channel for VDR, by switching to this one the "no data" did start immediately and the adapter is locked as long as you stay on the channel

RTL7;CANALDIGITAAL:12343:hC34S0:S19.2E:27500:518+8190=2:90=dut@4:38:1817,100:2006:53:1097:0

is there a better way to stop this early an close the ad + notice the client with 404

[9000h]

maybe reporting no signal to the client in that case will convince the client to give up

[catalinii]

I mean in this example it seems the client did not ask any pids so is normal to not have any data send to it. Basically no data means nothing was sent to the client.

As I said there are 2 scenarios: 1) you do not send data from legitimate reasons (no pids, nothing coming from DVR - driver issue, no signal) 2) There is a certain problem in minisatip

• get_signal generally does not lock the adapter just uses the frontend to get the signal as far as I know. The other thing is: 1) What issues does this causes and with which client 2) Fixing that issue for that client does it break other clients? how ? 3) Can a strategy for all clients be found ?

If we just try to go outside of those questions, we may risk breaking clients which is not a good outcome.