[REQUEST]: Smart "get_free_adapter()" functionality

[lars18th]

Hi @catalinii ,

At time the function adapter.c --> get_free_adapter() is quite simple. For example in this use case it will have troubles when:

• Three tuners, each one is a different SAT>IP server. And minisatip drives the tuners using the "satipc" module. The first tuner is a capable device with sufficient CPU to stream 50Mbps. But the two others devices can stream only up to 10Mbps.
• To this central minisatip server one user requests a service 1 from MUX1.
• Then another user requests service 2 from MUX2.
• Then another user requests a service 3 from MUX2.
• What happens? In this case the adapter1 (the good one) is streaming only 1 channel, but the adapter2 (basic device) is streaming 2 channels at time, and the streaming suffers.

My suggestion is to include some smart checking to select the "free" adapter based on more information. Then in the previous example, tuner1 will streams service 1 from MUX1, tuner2 service 2 from MUX2 and tuner3 service 3 from MUX2. And no problem appears. I don't want to introduce any advanced selection, just simple restrictions easy to handle.

The idea is then:

• When one adapter is running, you store the current bitrate, the number of pids, and the number of services. All data is at time already calculated.
• In the command line the user will have a new option to control the "adapter-performance-restrictions". Like: "limit bitrarte to...", or "no more than X pids", or "up to Z services".
• And then inside the get_free_adapter() these values could be used to "discard" some potential tuner and then go to the next.

In fact, it's more or less to put some limitations in the adapter selection when the current tunning parameters match, but you don't want to select this adapter because other restrictions apply.

What you think?

[Jalle19]

I vote no. The purpose of the function is to find a free tuner. A tuner being on a shitty device doesn't make it less free.

[lars18th]

Hi @Jalle19 ,

Why not? The idea is this:

• The current behaviour will continue equal to now if the user doesn't add any "restriction".
• The command line will be something like this: --adaptarter-limit 0:2:20:10000 that indicates: "for adapter 0, limit to 2 services, 20 pids and 10Mbps". By default the values will be -1:-1:-1 (aka no limit).
• The implementation will be a simple new function that checks the limits. And this function will be called inside the get_free_adapter(). Therefore nothing else will be changed.

Its clear, simple and non-intrusive. So, why not?

[Jalle19]

It increases complexity in an already quite complicated function, and the only people who would ever use it is people who buy Aliexpress Engima tuners that inevitable suck 🤷

[lars18th]

It increases complexity in an already quite complicated function, and the only people who would ever use it is people who buy Aliexpress Engima tuners that inevitable suck 🤷

False!

Please, consider this:

1. A new funtion not increases de complexity. It's just new code. The idea is to add a call to this new function when calling to compare_slave_parameters() that is a similar function.
2. A lot of closed source SAT>IP servers exist despite the Enigma boxes. A lot of users run minisatip inside a PC or Raspberry Pi connecting to physical SAT>IP servers that aren't Enigma boxes. A lot!!! And may of these servers have hardware limitations. With this simple enhancement these users (me included) could use these servers without troubles.

I understand your point of view. But this suggestion doesn't generate any side effect. Futhermore, the code will be simple and small. So why not?

[Jalle19]

For this to have any benefit, the user has to have a good tuner that they want to prefer over their bad ones. The solution is then to buy more of the good ones and throw away the bad ones. If all you have is bad tuners this change wouldn't bring much to the table.

compare_slave_parameters() is already quite complex

[lars18th]

For this to have any benefit, the user has to have a good tuner that they want to prefer over their bad ones.

No, no!! Think on this:

• Some SAT>IP servers can stream without problems around 15Mbps, but no more. And the pid list could arrive to 20 pids. This is sufficient to deliver 2 services without any problem. Therefore, instead of trying to stream a third channel in the same transponder a new tuner will be opened to do so. Or if no more free tuners will be available then the new request will not be served.

The real difference of this change is the opening of a new tuner over the same MUX if the current adapter has no sufficient power. With the current implementation all new requests for the same transponder will go to the same adapter, and this is not the best option because the hardware limitation of the SAT>IP servers. For example, think you on one transponder with a net bandwith of 80Mbps. Only a small number of SAT>IP servers can handle all this throughput without troubles. And with the current code if you request more and more services of the same transponder then you don't have the option of configure your tuners to serve the half of the mux from one adapter and the other half form another adapter.

Please be more open-minded. 😉

[Jalle19]

I am categorically against supporting inferior hardware. If you have a need to stream more than 15 Mbps from the same transponder, buy hardware that can handle that.

[lars18th]

I am categorically against supporting inferior hardware. If you have a need to stream more than 15 Mbps from the same transponder, buy hardware that can handle that.

OK. I respect your opinion. And it will be usefull if all SAT>IP hardware can handle: "pids=all", "a pid list of almost 1KB", "100Mbps bandwith", "DVB-S2X", etc. etc. etc. But the fact is only a small part of hardware can handle it. Therefore, it has sense that minisatip can work with all these common limitations.

So regarding your sentence of "If you have a need to stream more than 15 Mbps from the same transponder..." The problem is not this! The problem is: if we have 4 tuners, but with low performance (up to 1 UHD service only), and the users request two channels on the same transponder... what happens? With the current code you receive the 2 channels with errors, while the other 3 tuners are off. This is not the best strategy! It's more simple to use two tuners to server one channel each. Even if the transponder is the same. That's the key point. Do you think so?

And regarding the purchase of any hardware, for sure I recommend to get the best you can. In my case I've: Panasonic, Mirage, ALi, Edision (nino+ and pro), Digital Devices, and now one James Donkey. The only one that I always recommend it's the Digital Devices. However, DD is not the only SAT>IP that exist.

Regards.

[catalinii]

I am with @Jalle19 on this one.
Basically those are devices with no support from vendor thrown on the market at low price to ensure they sell.
But leaving this point aside the issue is that supporting them prevents makes the SW more complex and hard to support use cases that are really needed.

I do think now is a bad idea to support them, what do we do in 1 year when other devices with other quirks are launched.

Except edision on arm everything else is with kernels < 4.1-4.8 for enigma2 boxes.

[lars18th]

Hi @catalinii ,

Thank you for your response. However, I feel you're thinking that my request is only to support some low cost devices. And that's not the real objective. A simple example: imagine you want to limit one adapter to 2 channels, and other different adapter to 4 channels. With the current code it's impossible. And the code necessary is VERY simple. I've done the implementation... just few lines. And it works. So I need only to complete the parameters configuration. So please stay on hold.

[Jalle19]

Are there any expensive devices with limitations like this?

[lars18th]

Hi,

This functionality is already implemented in PR #1117. Waiting to close this issue when the code is merged.

Regards.