Trace flooding of "CRcvBuffer::readMessage(): nothing to read. Ignored isRcvDataReady() result"

[wmho24]

Hi,
I am experiencing trace flooding from this function despite having a steady connection stream (no drops, everything's working). Is it normal behavior? What could be wrong with the code (attached below)?

My stream:

ffmpeg -re -f lavfi -i testsrc=size=640x480:rate=25 -f lavfi -i sine=f=440:b=4 -f lavfi -i sine=f=432:b=4 -filter_complex "[1:a][2:a]amerge=inputs=2[a1]" -map 0 -map "[a1]" -c:v libx264 -preset ultrafast -tune animation -crf 32 -x264opts keyint=25:min-keyint=25 -c:a aac -b:a 32k -f mpegts -muxrate 1200k "srt://localhost:5000"

My stripped down (from original app) server listen code is attached.
srtsvr.c.gz
to build (inside srt cloned working copy root):

gcc srtsvr.c -I. -Isrtcore -o srtsvr -L. -lsrt

to run:

./srtsvr [listen_interface="0.0.0.0" [listen port=5000] ] 

[ethouris]

Which version of SRT is that?

I'm looing into the latest version and it doesn't look like there could be the reason of printing this message in a normal situation.

There is one that I could think of: if the blocking mode is in use and the timeout for reading is set. But in order to achieve flooding in this situation there would have to be reading timeout set to an extremely small value.

The readMessage() function is called in non-blocking mode only if isRcvDataReady() returns true, otherwise it isn't called at all. This is also called unconditionally in blocking mode, but only after the condition loop that should either:

• state the packet is available for reading
• get the timeout
• get the connection broken error

The call of this function then happens in case of broken connection or timeout and it might cause this warning log in this case, but then you should get the error from the call of srt_recv*. As I can see in the app, you are handling the timeout error. Let me check this app...

[ethouris]

Hmm, are you sure that you know what you are doing?

                int timeout = 0;
                CHK(srt_setsockflag(client, SRTO_RCVTIMEO, &timeout, sizeof(timeout)));

This is exactly the reason of this floding message.

Note also that it's weird that you are setting this:

   [blocking = 0];
    CHK(srt_setsockflag(listen, SRTO_SNDSYN, &blocking, sizeof(blocking)));

while your application isn't sending. If you wanted to have a non-blocking calls for srt_recv, you should have used SRTO_RCVSYN.

The timeout you set through SRTO_RCVTIMEO is the timeout for receiving in the blocking mode (in milliseconds), that is, up to how long it should wait until it states that there is no packet available for reading at the moment.

[wmho24]

Points noted! Setting RCVSYN does remove the trace flooding by returning SRT_ESYNRCV when srt_recv() has nothing in the reception buffer.

SNDSYN for a receive socket was an oversight in the inherited code and I missed this detail.