[Q] Selectable strategy for tuner selection

[lars18th]

Hi,

I open this thread to discuss about an idea that I want to implement. First of all, this IS NOT the same as #908 or #1114. Therefore, don't confuse with them.

• The idea is to support a new --adapter-select-alg X parameter to allow multiple adapter selection strategies.
• If X=0 (default): Select the next free adapter using strict number ordering. This is the current behaviour. Nothing changes by default.
• If X=1: Select the next free adapter using LRU algorithm. If multiple tuners are available the last used is selected.
• If X=2: Send the request to all unused adapters. After the first response from one of them, all others will be closed.

Considerations:

• The code will be quite simple. This will not be a complex implementation.
• The idea is to leave the responsibility for handling what happens if the request cannot be served to the clients. But with enough support from the minisatip server to provide multiple strategies.

Use cases:

1. Multiple remote tuners and the user wants to use all of them in a balanced mode. Then select LRU.
2. Each tuner uses a different wire and you want to provide some noise resilience (because your environment is 24/7 and you need High Availability). Then select all to send the same request to all tuners at the same time. The first with valid signal will be used (or with strong signal).
3. You have a local minisatip server using multiple SAT>IP servers in a shared environment (this case is when other clients can make requests to the SAT>IP servers and then you can receive 503 (No-More: frontends). In this case you can select all and several tuners will be requested at the same time. And when one is activated, the others are released.
4. Normal usage which is the default usage we are all using now. 😉

Please share your views.

[catalinii]

The only concern I have is with 2:

the issue is that the current signal thread is separate and processes the adapters in order. Relying on testing signal can produce non deterministic amount of time for the adapters to be tuned.

then if you have multiple requests at the same time you may have to reject some requests.

If signal is a concern you can cache the (adapter, src, freq) -> signal And use that to make a routing decision

[lars18th]

Hi @catalinii ,

Yes, I've proposals for this condition as well. My idea is this:

• In the case for expecting to mesure the signal, a "timer" will be used to poll for the signal. For example: if you use "0.5 seconds" then all requests will go to all (free) tuners. And after this half second we check all (requested) tuners. Then we use the one (active, because perhaps some can't complete the tunning process) with strong signal.

I think this strategy could be easy to implement, and powerful for the user.

But in any case, my idea it's to first implement use cases 1 and 4. Then the use case 3. And only at the end the use case 2 that is the most complex.