search

catalinii / minisatip

minisatip is an SATIP server for linux using local DVB-S2, DVB-C, DVB-T or ATSC cards
https://minisatip.org
325 stars 78 forks source link

BUG: Tuning to the same frequency with some default parameters implies the solection of a different tuner. #1011

Closed lars18th closed 1 year ago

lars18th commented 1 year ago

Hi @catalinii ,

I discovered that when using the "satipc" module, if some client requests a transponder with a small different parameters, but for the same frequency, then the "satipc" module requests a different SETUP for the remote SAT>IP server. Then this will open a different tuner, even for the same frequency. This is for example what receives the remote server:

SAT>IP: SETUP rtsp://192.168.1.53:554/?src=1&freq=11236&msys=dvbs&mtype=qpsk&pol=h&sr=0&pids=none RTSP/1.0
SAT>IP: SETUP rtsp://192.168.1.53:554/?src=1&freq=11236&msys=dvbs&mtype=qpsk&pol=h&sr=27500&fec=56&ro=0.35&plts=off&pids=none RTSP/1.0

Why not "compact" the request in this case?

The first SETUP is sended by the "satipc" module when the client requests only "src", "freq", "pol", "msys" and "mtype", with default values for the rest. And the second SETUP correspond to the request from the "satipc" module when a different client wants the same transponder but indicates all values ("sr", "fec", "ro" and "plts").

These different SETUPs are interpreted as different tunning parameters in the remote SAT>IP server. And then implies to use two tuners.

Any idea to fix this?

Jalle19 commented 1 year ago

Is the behavior identical (two tuners are used) if satipc is not involved? Or will the tuner get reused then?

lars18th commented 1 year ago

Hi @Jalle19 ,

I think you're right. After thinking more on it, I suspect that the problem is not related with the "satpic" module, but with the tuner selection. However, I discovered this issue using this module.

More or less, the problem could be related with the function compare_tunning_parameters(): https://github.com/catalinii/minisatip/blob/792820fab4e8bd722e5a47fc378371fe91bd1902/src/adapter.c#L1206-L1226

So, the solution perhaps implies to store the "default" (aka "not indicated") value in some part, and use this information to compare the tunning data.

What you think @catalinii ?

catalinii commented 1 year ago

Probably the issue is in compare_tunning_parameters but the values of fec, ro, plts are not compared. Can you print if compare_tunning_parameters is really the issue?

lars18th commented 1 year ago

Probably the issue is in compare_tunning_parameters but the values of fec, ro, plts are not compared. Can you print if compare_tunning_parameters is really the issue?

Hi @catalinii ,

The problem is the SR value. The others seems to not be relevant in the check. But the "Simbol Rate" is the one that generates the issue. Perhaps the solution is to store a value that signifies "auto", and use this value as valid when comparing to any other value.

Jalle19 commented 1 year ago

Do you have a log where the lines "new parameters" and "old parameters" can be seen? (tp->sr > 1000 && tp->sr != ad->tp.sr) must evaluate to true for minisatip to choose a new adapter, which implies that ad->tp.sr is not set, which could be a bug.

lars18th commented 1 year ago

Hi @Jalle19 ,

I've discovered the bug. Please check my solution #1037 .

lars18th commented 1 year ago

I close this because the issue is fixed.