BUG: Player glitches when using "satipc" #992
Comments
|
hi @lars18th, I did not see anything that can cause this. To get more info please add -l lock and you can see the messages related to locking maybe something comes up. |
|
Hi @catalinii , I doing a deep trace of the logs. However, something is strange: For every NEW stream, I see that after the first PLAY command (the remote SAT>IP server is minisatip too), the "satipc" module send THREE consecutive DESCRIBE commands: This has sense? |
|
if you can reproduce the describe issue, feel free to upload a fresh log as a separate issue. |
|
Feel free to provide the log adding -l lock to your previous command line. Also please indicate when this happens (timestamp). |
Hi @catalinii , Obviously something is going wrong: I'm checking what happens between the first read glitch with 110ms of delay, and the second of 1411ms delay. All done reading with RTSP_over_TCP from a remote minisatip SAT>IP server (one Enigma STB box). Any idea? |
|
Hi @catalinii , Full debug enabled (all modules in "-v", except dmx only in "-l"): This is the complete log trace for the block when the first glitch appears (~100ms instead of the regular 3-5ms). And my first concern is this line: It really has sense to READ zero bytes from the RTSP socket? |
|
Hi @catalinii , After more testing the problem IS NOT related to the use of the RTSP_over_TCP. So, when using the regular RTSP/RTP, the same problem appears. Futhermore, see this part of the LOG: As you can see the problem is that the READING socket of the "satipc" module is not receiving signals. And then it is stalled for exactly 200ms (45.670 AD1: event on socket index 10 --> 45.870 AD1: event on socket index 10), that is the timeout value of the socket. And this is true on ALL conducted tests. Additionally, I see that the "iteration number" of the "Read OK" debug line has in this log a gap: from 12489 it changes to 27. I observed this only with the regular RTP transport. This new log is using RTP and not TCP as used in privious one. And finally, I can assert that if the RTSP socket is already opened, then the problem doesn't appear. So, if you open the second client, and then close it... if you restart to any other channel (in a different transponder) before the "adapter" is closed, then in this case all is clean. Please, remember that the closing of the RTSP socket in the "satipc" moduel has a 30 seconds grace time. Therefore, when the socket is already opened nothing is goining wrong. That said, could it then be that the creation of the client TCP socket to connect to the RTSP port causes a problem in the global socket structure? |
|
Hi @catalinii , More info: Compiling and running inside WSL (Ubuntu 21.10) then the same behaviour appears. Futhermore, running without threads (with "-T" parameter). So the problem is there for all environments. To reproduce it is quite easy: open a local minisatip connecting to TWO different SAT>IP servers through the "satipc" module. First wait until all the tuners will be closed (around 30-40 seconds). Then open 1 client (http or rtsp, don't care) with any FTA channel and when the program is playing, open another client in a differnt transponder... you'll see EVERYTIME that the first client is interrupted for around 1-2 seconds. I hope we can fix this serious bug. |
|
Hi @catalinii , Any reason for this redundant line? Lines 1056 to 1057 in ec9c4c8 |
|
Hi @catalinii , Another bug, perhaps related (or not): when you start minisatip and not wait until all the tuners will be closed, then if you open one channel, all other tuners will not be closed as expected. I'm speaking about "remote adapters" configured with the "satipc" module. |
|
Hi @catalinii , If I remove the comments in lines 729 & 735 in "socketworks.c" then: Lines 729 to 735 in ec9c4c8 Any idea why something is blocking the polling until the timeout? |
|
Hi, Poll timeout means none of the handles submitted to poll call had anything to read. I would suggest doing a tcpdump and see if there is any traffic coming at that time to minisatip |
1 similar comment
|
Hi, Poll timeout means none of the handles submitted to poll call had anything to read. I would suggest doing a tcpdump and see if there is any traffic coming at that time to minisatip |
|
Hi @catalinii , For sure the problem is not the server, and the data is comming from it. I discovered today that the problem could be related to the CA management. When using transponders without pid 1 (CAT) then the problem doesn't appears. I'll provide more information. |
|
Hi @catalinii , After more testing the problem doesn't seem to be related to the CA management. However, the problem appears related to the TCP WINDOW SIZE. Even if the problem appears when using RTP transport as well... with the "tcpdump" tool running in the SAT>IP server (the E2 box) I see that the window size of the TCP packets changes when the second client connects to the central minisatip server. So, perhaps the problem is something related to this:
However, I can't understand why? Any idea? |
|
If you can reproduce the issues on both tcp and udp then probably the issue is not related to the tcp window. The window is just a way of determining how much data can be sent without acknowledging the received data and is meant to be dynamic. On a system with no packet loss the window should just increase up to a max value (and should not drop to a low value). What is the satip server running on e2 box? |
|
Hi @catalinii , I discovered the root cause of the glitch! 🎖️
Therefore, I've this suggestion to circunvent this problem: One "direct" solution is to not use at all the DiseqC parameter "-0" and the rest. But if your infrastructure really needs it, then what we can do is to send an additional parameter to the "slave" device to open the tuner and tune to the frequency without sending any DiseqC command. For example, with this syntax:
So, when receiving this "optional" parameter in the tune request the idea is then to "block" all diseqc commands. And then is quite easy that the central minisatip SAT>IP server (that uses the "satipc" module) will send this command if it's managing an slave tuner. Or perhaps you prefer to use a more generic parameter like |
|
Please, no more slave tuner related hacks 😄 |
|
Hi @Jalle19 ,
My proposed solution will be completly transparent to all users. Think on this scenario: What I say is that the "central minisatip" could add to the request the parameter
So fully transparent. For the receiver it's only a new optional parameter to parse. And for the server is only a new functionality that the user can enable optionally. What's the problem? |
|
This resolution is again very not standard and will become clutter as more and more people move to unicable which does not have this issue. |
|
Hi @catalinii , I'm convinced that the only solution to solve this issue is to enable the option of sharing information between different minisatip instances. Therefore, in order to provide a method that it will be clean and safe, I suggest this strategy:
This method will be fully transparent because additional header lines will not generate troubles with any server. And the best is that this could be used not only for resolve this issue, but to support any future enhancement that we need. Example of this header:
And one example inside one RTSP request sended by the So the idea is quite simple: the master could add different eXtendend CoMmanDs to requests, and the slave only need to process them. The best is that you can pass multiple commands for future uses: What you think about this generic data sharing between different minisatip instances? |
|
#992 (comment) my stance on this remains unchanged |
Hi @Jalle19 . I appreciate your comment. However, in some cases (like in my environment) the master-slave mode is necessary. Remember: Using a central minisatip instance receiving streams from different (more than one) SAT>IP servers it's very common for a multi-frequency tuner support. And if these SAT>IP servers are cheap STBs with minisatip on it (with one or two tuners) then you're in the group that needs master-slave support. Not all people has FBC tuners drived by one unique minisatip instance. However, the previous is not directly related to my last proposal: provide a method to send specific commands from one minisatip instance to another... when using the satipc module. I think this is a great enhancement, and it can be used to other functionalities. Perhaps you don't use the |
Hi,
I've advanced a litte more with the trouble that I've described a lot of time ago: When connecting with multiple users at the same time, in some cases the already playing user observes a glitch in the play when the second client starts.
Here my configuration:
Here how yo reproduce the glitch:
I see in the LOGs (with -v satipc) that the thread that is MANAGING data from the first SAT>IP client, is stalled for sometime when the thread of the second tuner makes the call to the other SAT>IP server. So more or less you see (1 is first satipc thread, 2 is the second one):
1111111111111111111111111111111122222222222222222222222222221212121212121212121212121212121212But what you're expeting is something like :
1111111111111111111111111111111122121212121212121212121212121212121212121212121212121212121212Therefore, I suspect that in the implementation of the "satipc" module, something is blocking the READING SOCKET, or the writing in this socket, I don't know. Any idea @catalinii ?
The text was updated successfully, but these errors were encountered: