This issue is intended to consolidate and track the situation around the RCV loss list and concurrency.

The following issue was submitted for SRT v1.4.4 (#2192 (comment)):

When processData() received 899264404, it was added into the recv buffer, after recvbuf_acklock was unlocked, the tsbpd thread played 899264404 and dropped 899264403, then processData() immediately insert 899264403 back into loss list, after this, getFirstLostSeq() keep return 899264403
To fix the followin issue

PR #2195 introduced the m_iLargestSeq to resolve the bug.

It was later reported in #2873, that if a consecutive loss occurs after more than m_iSeqNoTH to the previous loss record (already removed from the loss list), the loss record is not recorded in the loss list. An ACK packet with a wrong seqno is sent as a result.

This issue was addressed in #2877 by resetting m_iLargestSeq to SRT_SEQNO_NONE if the list becomes empty.
@gou4shi1 later shared his concerns this may reintroduce the initial concurrency issue.