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.
Hi,
I discovered another ugly bug with the
satipcmodule. Here the info to reproduce it:satipcmodule to a secondary minisatip running in a E2 box emulating pids=all.satipcand 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
satipcis 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 usepidsanddelpidsat the same time, onlyaddpidswithdelpids. And withaddpidsanddelpidsonly lists of numbers are permited. Therefore,pids=allandpids=noneis 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=nonewith 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=....satipcmodule 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.