Shared Tuner does not work.

[jojo61]

Hi

I have two shared tuners 0 and 1. When Master Tuner 0 is busy and I try to tune to a second stream with differend Polarity, then the slave tuner is used. But that is wrong. Here a excerpt from the log file where the slave tuner is selected even when the Polarity is different to the master.

[01/01 12:50:25.140]: get free adapter 0 - a[0] => e:1 m:0 sid_cnt:1 src:1 f:11493000 pol=2 sys: dvbs dvbs2
[01/01 12:50:25.140]: Dumping adapters:
[01/01 12:50:25.140]: 0|f: 11493000 sid_cnt:1 master_sid:0 master_source:-2 del_sys: dvbs,dvbs2,undefined src_map: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (4294967294) [01/01 12:50:25.140]: 1|f: 0 sid_cnt:0 master_sid:-1 master_source:0 del_sys: dvbs,dvbs2,undefined src_map: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (4294967294) [01/01 12:50:25.140]: Dumping streams:
[01/01 12:50:25.140]: 0| a:0 rsock:13 type:2 play:1 remote:192.168.1.20:60064
[01/01 12:50:25.140]: 2| a:-1 rsock:18 type:2 play:0 remote:192.168.1.20:45098
[01/01 12:50:25.141]: new parameters: f:11347000, plp/isi:-1, diseqc:1, pol:1<-----------, sr:22000000, mtype:9 [01/01 12:50:25.141]: old parameters: f:11493000, plp/isi:-1, diseqc:1, pol:2<-------------, sr:22000000, mtype:9 [01/01 12:50:25.141]: new parameters: f:11347000, plp/isi:-1, diseqc:1, pol:1, sr:22000000, mtype:9 [01/01 12:50:25.141]: old parameters: f:0, plp/isi:-1, diseqc:0, pol:0, sr:0, mtype:6
[01/01 12:50:25.141]: delsys_match: adapter is NULL, delsys 6
Message repeated 59 times
[01/01 12:50:25.143]: get free adapter found slave adapter 1 <------- adapter is selected :-(

Further investigations I found that in adapter.c is a missing ! in get_free_adapter:

// No regular tuners available, check for slave tuners
for (i = 0; i < MAX_ADAPTERS; i++) {
    // first free slave adapter that has the same msys
    if ((ad = get_adapter_nw(i)) && ad->sid_cnt == 0 &&
        delsys_match(ad, msys) && ----------> ! is missing    compare_slave_parameters(ad, tp) &&
        ad->sources_pos[tp->diseqc])
    {
        LOGM("get free adapter found slave adapter %d", i);
        return i;
    }

My test show that the function compare_slave_parameters will always fail. The value tp->diseqc_param.lnb_switch is always 0 and so the hiband detection fails.

[9000h]

@catalinii can you agree with the finding when using shared dvbs tuners?

[Jalle19]

Can we consider simply removing support for slave adapters? We have multiple tickets open regarding them, and since it's a nische feature there is limited hope of ever finding the time and expertise to solve them. Furthermore, the whole concept is a hack that will always have certain drawbacks. Even further more, Unicable LNBs are available and widely supported, meaning these master/slave configurations are effectively legacy.

@9000h @lars18th @catalinii opinions?

[lars18th]

Hi @Jalle19 ,

Here my opinion: I'm sure that the best solution is to use Unicable LNBs for multiple tuners. So I agree with the idea to first support such types of configurations. I perfer to focus resources on improve the Unicable support that in other configurations. However, I don't feel it could be positive to remove the master/slave support. IMHO the current support is limited and requires to be improved. But the code doesn't generate other side effects. So perhaps at some time we will have time to fix/enhance it. Therefore in the meantime then we can comment that this functionality is work-in-progress. You agree?

[Jalle19]

I don't know, I wanted to take a stab at implementing "subscription weight" support but I gave up at first sight of this master/slave tuner concept. Code never exists in a vacuum - even though something works more or less it could be an impediment to change.

[lars18th]

Hi @Jalle19 ,

I've never used the "subscription weight" in TVHE. And I don't see the sense of it. However in the past I've provided some PR for improving the master/slave support. So from my point of view this model has full sense. Anyway if you can provide an alternative view, then perhaps it could be positive to describe it. Then we can discuss about the best option to implement it. 😉

[Jalle19]

The "weight" is important if you have many users sharing a single minisatip server, and you don't want one persons EPG scan to block another one who wants to actually watch something. Basically it acknowledges that not all tuning requests are equally important.

Anyway, my absolute main concern is that this project goes from being "mini" to being a complicated unmaintained mess like tvheadend, which is AFAICT effectively unmaintained these days, probably in part due to it supporting every single random user request under the sun. I don't want to see yet another software I use end up in that state.

[lars18th]

Hi @Jalle19 ,

I agree that TVHE is not good at these days. However, regarding minisatip it's a great SAT>IP server. And it's mature and mantained. So don't worry about it's development. And remember that it's not the only opensource SAT>IP server.

And regarding the "weight". My current opinion is that some functionalities could be implemented outside minisatip. For example, in my case, I've finally configured all my clients to use only HTTP and forget RTSP (as you can imagine I'm using it in my home LAN). Then, I put one IPTV lightweight server in front of it to control other functionalities, like for example the "QoS for tuners" (aka "weight"), EPG generation, etc. I feel this modular platform approach is more capable and flexible. Even more when the minisatip is not using at all any internal tuner. It only drives external tuners (SAT>IP servers and HDHR servers). Perhaps this model is quite complex for all scenarios, but in my case it's very powerful using only low-cost hardware.

[catalinii]

I think slave tuners is very useful for enigma or devices where a HW imput is connected to multiple oogical adapters.

Basically enigma FBC implementation relies heavily on slave adapters. Indeed slave adapters using diseqc and other non-unicable switches is hard to maintain because there could be a lot of edge cases. I think probably is best to fix the current implementation as there could be a lot of use cases relying on it.

I really hope one day most of the people will migrate to unicable one day but I do not see a much higher number of unicable users compared to normal switches asking questions. Maybe it just works or the adoption goes slower than expected.

[catalinii]

But yeah I agree with your points about maintainability of the project

[Jalle19]

I tried this scenario and it works as expected nowadays:

[24/06 21:54:05.819 main]: Play for stream sid 1, type 1, rsock 10, adapter -1, sock_id 10, rsock_id 10, handle 10
[24/06 21:54:05.819 main]: stream.c:262: get_adapter returns NULL for adapter_id -1
[24/06 21:54:05.819 main]: adapter.c:1222: get_adapter returns NULL for adapter_id -1
[24/06 21:54:05.819 main]: stream.c:271: get_adapter returns NULL for adapter_id -1
[24/06 21:54:05.819 main]: get _free adapter 0 - a[0] => e:1 m:0 sid_cnt:1 src:1 f:11216000 pol=1 sys: dvbs2 dvbs
[24/06 21:54:05.819 main]: Dumping adapters:
[24/06 21:54:05.819 main]: 0|f: 11216000 sid_cnt:1 master_sid:0 master_source:-2 del_sys: dvbs2,dvbs,undefined 
[24/06 21:54:05.819 main]: Dumping streams:
[24/06 21:54:05.819 main]: 0|  a:0 rsock:13 type:1 play:1 remote:127.0.0.1:41396
[24/06 21:54:05.819 main]: 1|  a:-1 rsock:10 type:1 play:0 remote:127.0.0.1:36090
[24/06 21:54:05.819 main]: new parameters: f:10903000, plp/isi:-1, diseqc:1, pol:1, sr:25000000, mtype:9
[24/06 21:54:05.819 main]: old parameters: f:11216000, plp/isi:-1, diseqc:1, pol:1, sr:25000000, mtype:9
[24/06 21:54:05.819 main]: delsys_match: adapter is NULL, delsys 6
Message repeated 61 times
[24/06 21:54:05.819 main]: no adapter found for src:1 f:10903000 pol:1 msys:6

This was with ./minisatip -f -y 8554 -s dvbs2:10.110.4.14 -s dvbs2:10.110.4.14 -S 1:0