minisatip icon indicating copy to clipboard operation
minisatip copied to clipboard

Incorrect mappings in UI links of streams

Open lars18th opened this issue 2 years ago • 6 comments

Hi,

I discovered today a new small bug in the UI: the links provided in the STREAMS colum has incorrect values for FE and SRC when you're using "mappings" of different sources to different adapters. In fact the errors are:

  1. The "fe=" parameter is inserted, even when this value should not be used by clients. So it needs to be removed from the link.
  2. The "src=" parameter not corresponds to the "input" value send by the client, but to the one used to request it to the "adapter". So it doesn't correspond to the correct value.

I report this to fix it at some point. Regards.

lars18th avatar Oct 02 '22 11:10 lars18th

I've noticed the same as well

Jalle19 avatar Oct 02 '22 17:10 Jalle19

not new :-) https://github.com/catalinii/minisatip/issues/562

9000h avatar Oct 02 '22 18:10 9000h

not new :-) #562

Ok. So I'll try to fix it in the future... 😉

lars18th avatar Oct 03 '22 11:10 lars18th

The fe= parameter is now fixed in master. I do not understand the issue with src= can u provide more info/logs ?

catalinii avatar Oct 03 '22 20:10 catalinii

Hi @catalinii ,

I do not understand the issue with src= can u provide more info/logs ?

When we use the option -A --virtual-diseqc mapping_string to configure multiple SAT>IP servers with different orbital positions, then the SRC= value in the link is incorrect. Example:

  • You want to configure SAT>IP server X with two sat positions A,B.
  • You configure another SAT>IP server Y with other different sat positions A,B.
  • So A in X is different than A in Y. And idem for B.
  • Then from client SRC=1 is A in server X, SRC=2 is B in server X, SRC=3 is A in Y, SRC=4 is B in Y.
  • And the error is that any link with a request to sources 3 and 4, are including the values 1 and 2 because they are the "target" source values used in the request sended to the remote SAT>IP server. So client request src=4 and the link has src=2.

It's necessary then to fix this bug setting the "src=" value in the link to the "requested" value from the client, and not with the "tunning" value used by the adapter.

I hope it's more clear now. 😉

lars18th avatar Oct 05 '22 20:10 lars18th

Hi @catalinii ,

To fix the SRC bug, I've a question for you:

  • You prefer that ad_pos continues to be the TARGET src value and add one ad_opos with ORIGIN src value; or viceversa?

The question is because we need to store both value:s the value previous to calculate the absolute_table[] mapping, and the target value. Or use the mapping table to search for the target value and obtain the original value. But in any case, it seems that both values requires to be shared with the external symbols of the UI.

What you think?

lars18th avatar Oct 08 '22 11:10 lars18th

I would introduce a new symbol

Jalle19 avatar Nov 07 '22 21:11 Jalle19

I would introduce a new symbol

Great! Then you will share ad_pos and ad_req_pos (or any other name)?

lars18th avatar Nov 09 '22 16:11 lars18th

Maybe something like ad_mapped_pos

Jalle19 avatar Nov 09 '22 17:11 Jalle19

Fixed. Closed too.

lars18th avatar Feb 21 '23 17:02 lars18th