We did these tests on the same server (S1):
1> When using SRT to push data to S1, the SRS will be disconnected (ranging from a few minutes to several tens of minutes),error info:"srt: recvmsg : wait readable : srt socket 747664583 timeout";
2> It is normal for the same program to push SRT streams to SRT LIVER SERVER;
3> It is normal for the same program to push the SRT stream to the DEMO server( a simple SRT server I wrote myself);
The following are all the same programs, using the SRT default configuration provided by SRS, tested on three servers:
1> Pushing to server S1 using SRT will disconnect (ranging from a few minutes to several tens of minutes),error info:"srt: recvmsg : wait readable : srt socket 747664583 timeout";
2> Using SRT to push the stream to server S2 is normal;
3> Pushing to server S3 using SRT will disconnect (About once an hour).But after I changed the SRT configuration, it worked fine.The configuration is as follows:
srt_server {
enabled on;
listen 10080;
maxbw 1000000000;
connect_timeout 4000;
peerlatency 1000;
recvlatency 1000;
latency 1000;
tsbpdmode on;
tlpktdrop on;
sendbuf 16000000;
recvbuf 16000000;
}
4>After changing the SRT parameters as mentioned above(S3), although I did not disconnect again, the following information will be printed every hour:"@341595334:No room to store incoming packet seqno 659346161, insert offset 40. Space avail 0/10869 pkts. (TSBPD ready in -14235ms, timespan 14164 ms). GETTIME_MONOTONIC drift -1 ms."
5>After modifying the SRT configuration of S1 to be the same as S3, it still disconnects(ranging from a few minutes to several tens of minutes),error info:"srt: recvmsg : wait readable : srt socket 747664583 timeout";
Version
SRS/6.0.36
To Reproduce
My testing feels relevant to the environment and I cannot tell how to reproduce it. I can only confirm that using the SRT live server in the same environment is normal, and a simple SRT server I wrote myself is also normal. I have tested the input stream bitrates of 2Mbps and 8Mbps.
Expected behavior
I hope to solve this abnormal problem, whether it is' wait ready 'or' No room '
Describe the bug
We did these tests on the same server (S1): 1> When using SRT to push data to S1, the SRS will be disconnected (ranging from a few minutes to several tens of minutes),error info:"srt: recvmsg : wait readable : srt socket 747664583 timeout"; 2> It is normal for the same program to push SRT streams to SRT LIVER SERVER; 3> It is normal for the same program to push the SRT stream to the DEMO server( a simple SRT server I wrote myself);
The following are all the same programs, using the SRT default configuration provided by SRS, tested on three servers: 1> Pushing to server S1 using SRT will disconnect (ranging from a few minutes to several tens of minutes),error info:"srt: recvmsg : wait readable : srt socket 747664583 timeout"; 2> Using SRT to push the stream to server S2 is normal; 3> Pushing to server S3 using SRT will disconnect (About once an hour).But after I changed the SRT configuration, it worked fine.The configuration is as follows: srt_server { enabled on; listen 10080; maxbw 1000000000; connect_timeout 4000; peerlatency 1000; recvlatency 1000; latency 1000; tsbpdmode on; tlpktdrop on; sendbuf 16000000; recvbuf 16000000; } 4>After changing the SRT parameters as mentioned above(S3), although I did not disconnect again, the following information will be printed every hour:"@341595334:No room to store incoming packet seqno 659346161, insert offset 40. Space avail 0/10869 pkts. (TSBPD ready in -14235ms, timespan 14164 ms). GETTIME_MONOTONIC drift -1 ms." 5>After modifying the SRT configuration of S1 to be the same as S3, it still disconnects(ranging from a few minutes to several tens of minutes),error info:"srt: recvmsg : wait readable : srt socket 747664583 timeout";
Version SRS/6.0.36
To Reproduce My testing feels relevant to the environment and I cannot tell how to reproduce it. I can only confirm that using the SRT live server in the same environment is normal, and a simple SRT server I wrote myself is also normal. I have tested the input stream bitrates of 2Mbps and 8Mbps.
Expected behavior I hope to solve this abnormal problem, whether it is' wait ready 'or' No room '
Screenshots
Additional context
TRANS_BY_GPT4