You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I discovered another ugly bug with the satipc module. Here the info to reproduce it:
The environment is a master minisatip connected using the satipc module to a secondary minisatip running in a E2 box emulating pids=all.
One client connected to the master minisatip requests a channel.
Another client connects to the master minisatip and requests a "pids=all" for the same frequency.
Until here all works, because the slave minisatip receives the "pids=all" from the satipc and apply the emulation to add all pids.
However, when the client for pids=all stops, the slave minisatip continues sending all pids to the master minisatip.
In the log of the slave minisatip I see this interesting entry:
[22/02 20:28:49.140 main]: failed to remove pid 8192 to fd 7: errno 22, Invalid argument
[22/02 20:28:49.140 main]: clearing demux filter on PID 8192 FD 7, active_pids 56 [0 ms]
Therefore I suspect the problem is created because the slave minisatip doesn't know how to "undo" the pids_all_emulation. Because in the log we can see copy_dvb_param start -> [...], pids=NULL, apids=8192, dpids=8192 x_pmt=NUL. And this fails (obviously).
But this is not the only problem: the satipc is requesting to delete all pids, but it requires to maintain the list of the pids requested by the other client. From the specifications I feel is not possible to use pids and delpids at the same time, only addpids with delpids. And with addpids and delpids only lists of numbers are permited. Therefore, pids=all and pids=none is accepted, but not delpids=all. In this case, following the specification the correct way to disable all pids and set a running pid list will be: send first a pids=none with another request after with addpids=.... But I feel that with minisatip we can accept to process requests like &pids=none&addpids=0,1,16,17,20,.... That we can interpret with a semantic of: clear the pid list without removing the pids in the list. That in fact implies to clearing the pid list, add the new pids, and do one commit for all with the tuner.
Therefore multiple modifications are necessary:
With the pids_all_emulation fix the error when requesting to close all pids (unimplemented correctly at time).
Implement the support to properly interpret a request of the type &pids=none&addpids=....
Change the satipc module to handle correctly when a secondary user requests "pids=all" with an already used frequency sending a SAT>IP request with the previous syntax.
Regards.
The text was updated successfully, but these errors were encountered:
Hi,
I discovered another ugly bug with the
satipc
module. Here the info to reproduce it:satipc
module to a secondary minisatip running in a E2 box emulating pids=all.satipc
and apply the emulation to add all pids.In the log of the slave minisatip I see this interesting entry:
Therefore I suspect the problem is created because the slave minisatip doesn't know how to "undo" the pids_all_emulation. Because in the log we can see
copy_dvb_param start -> [...], pids=NULL, apids=8192, dpids=8192 x_pmt=NUL
. And this fails (obviously).But this is not the only problem: the
satipc
is requesting to delete all pids, but it requires to maintain the list of the pids requested by the other client. From the specifications I feel is not possible to usepids
anddelpids
at the same time, onlyaddpids
withdelpids
. And withaddpids
anddelpids
only lists of numbers are permited. Therefore,pids=all
andpids=none
is accepted, but notdelpids=all
. In this case, following the specification the correct way to disable all pids and set a running pid list will be: send first apids=none
with another request after withaddpids=...
. But I feel that with minisatip we can accept to process requests like&pids=none&addpids=0,1,16,17,20,...
. That we can interpret with a semantic of: clear the pid list without removing the pids in the list. That in fact implies to clearing the pid list, add the new pids, and do one commit for all with the tuner.Therefore multiple modifications are necessary:
&pids=none&addpids=...
.satipc
module to handle correctly when a secondary user requests "pids=all" with an already used frequency sending a SAT>IP request with the previous syntax.Regards.
The text was updated successfully, but these errors were encountered: