Add Local- and Server- buffer Leds on the network settings page.

[pgScorpio]

Two reasons why we would want separate leds for Local and Server buffer under-runs on the network settings Jitter Buffer setup.
1: When manually setting the Jitterbuffers you wanna see which buffer has under-runs.
2: On android you can't even see the common Jitterbuffer Led on the client dialog while you are on the settings page.

[dcorson-ticino-com]

1. Your client does not know the buffer state of the server.
   That would require a protocol change which we are very reluctant to do if it is not absolutely necessary as it entails lots of program bloat to maintain backward compatibility.
   I am not sure if knowing this info would really help a whole lot, your best judge is your ears, not a led.
2. Having more leds will not make them more visible.

[ann0see]

I think there was an issue due to some strange Qt behaviour on macOS, but I can't remember. And it only happened in specific Qt widgets...

[pgScorpio]

@dcorson-ticino-com

1. That would require a protocol change which we are very reluctant to do if it is not absolutely necessary as it entails lots of program bloat to maintain backward compatibility.

I took a look at it and could actually be quite easy to implement this with full backwards compatibility:

Just use the PROTMESSID_JITT_BUF_SIZE message.

A new server can send a PROTMESSID_JITT_BUF_SIZE message with iJitBufSize = 0 on a buffer under-run.
On old client versions this message will just cause EvaluateJitBufMes to return "error", which is completely ignored.
On new versions EvaluateJitBufMes could emit a ServerJitterBufferError on receiving iJitBufSize = 0, and CChannel can connect to this event and set an error flag which can be checked by CCLient with a GetAndResetServerJittBuffError() function in CChannel.
If the server always sends this message during the connection setup phase it's also easy to detect that the server supports this message since the flag will be set when a connection is established, and with old servers the flag won't be set after connection so we can disable (hide) the led in that case.

EDIT: I implemented this solution and also did cross tests old server - new client and new server - old client, all combinations work as expected ;=)

[pgScorpio]

@ann0see

I think there was an issue due to some strange Qt behaviour on macOS, but I can't remember. And it only happened in specific Qt widgets...

I took a look at the dialogs and I think there is still a memory leak problem since in the dialog constructors there are several components created with new, but they are not deleted in a destructor. So without garbage collection you will always have a memory leak...

[ann0see]

Ok. Can you open an issue/PR with these fixed?

[pgScorpio]

Ok. Can you open an issue/PR with these fixed?

I must have to have a closer look first, maybe there is no problem if all of those components are only used as Qt child objects. In that case they should be deleted by the Qt parent object.
But I'll will dive into this as soon as the first step of the sound redesign is ready and merged (That is my first priority now ;=) ).