[BUG] Message out-of-order mode: should not use first_seq to update group read state

[gou4shi1]

Describe the bug
In file mode, message api, inorder set to false, group receiver can read messages out of order, then update m_RcvBaseSeqNo beyond first_seq, then m_parent->m_GroupOf->updateReadState(m_SocketID, first_seq) will keep fail.

To Reproduce
Use file mode, message api, inorder false, group broadcast send, group receiver.

Expected behavior
Group receiver should always be marked as readable as soon as some messages received.

Desktop (please provide the following information):

• OS: Linux
• SRT Version / commit ID: master/88309439

[ethouris]

Wait! Nice that you found it, but we have never tested the groups in the file/message mode. It was intended to be used only in live mode.

The problem here is that this is likely not solvable, at least not in the current buffer implementation. This is because the group reader is currently implemented in the "application style", that is, it simply treats member links as independent links that just have the sequence number synchronization (that is, the packet with the same payload will have the same sequence number in all links), and this sequence synchronization will be used to make the group reader go forward on every particular link. The base condition for this thing to work is that sequence numbers from the read packets are MONOTONIC, and with a possibility to read messages out of order it definitely won't be. So this read-readiness problem is not the only problem here.

The problem is solvable in general, but it requires some of the key parts to be reimplemented, so for the time being it must be put aside.

[gou4shi1]

LOL, but "group reader ignore old messages" is ok for my usecase, so I temporarily use last_seq (instead or first_seq) to update group read state.