minisatip
minisatip copied to clipboard
Incorrect mappings in UI links of streams
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:
- The "fe=" parameter is inserted, even when this value should not be used by clients. So it needs to be removed from the link.
- 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.
I've noticed the same as well
not new :-) https://github.com/catalinii/minisatip/issues/562
not new :-) #562
Ok. So I'll try to fix it in the future... 😉
The fe= parameter is now fixed in master. I do not understand the issue with src= can u provide more info/logs ?
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 hassrc=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. 😉
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 onead_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?
I would introduce a new symbol
I would introduce a new symbol
Great! Then you will share ad_pos
and ad_req_pos
(or any other name)?
Maybe something like ad_mapped_pos
Fixed. Closed too.