Remote sample source uses wrong channel # for remote sink

[ijessen-mitll]

When changing settings within the remote sample source, the channel index used in the emitted API call to the remote sink is wrong (255 instead of 0).

The channel value should be set to 0 here, which is called during implicit default construction of RemoteInputUDPHandler::m_remoteInputBuffer, which ultimately provides the RemoteMetaDataFEC instance that holds the channel index value.

Capturing traffic during an attempt to change a setting (e.g. remote device Fc) from the remote sample source GUI, this is the resulting HTTP exchange:

[ijessen-mitll]

Seems to be a server (i.e. remote sink channel) issue - remote sink channel plugin is sending the incorrect channel # in the metadata element of the stream:

[ijessen-mitll]

Alright well - this is totally weird. I'm watching in the debugger as remotesinksink.cpp:135 is executed. The value of m_deviceIndex is 0. Executing the expression m_deviceIndex % 256 in the debugger results in 0. The line immediately preceding correctly sets metaData.m_deviceIndex to 0.

And yet - metaData.m_channelIndex is set to 255. Every time. Something is going on beyond my understanding.

gcc --version
gcc (Debian 12.2.0-14) 12.2.0

gcc -dumpmachine
aarch64-linux-gnu

[github-actions]

This issue is going to be closed due to inactivity

[srcejon]

Alright well - this is totally weird. I'm watching in the debugger as remotesinksink.cpp:135 is executed. The value of m_deviceIndex is 0. Executing the expression m_deviceIndex % 256 in the debugger results in 0. The line immediately preceding correctly sets metaData.m_deviceIndex to 0.

And yet - metaData.m_channelIndex is set to 255. Every time. Something is going on beyond my understanding.

If you're debugging optimised code, the debugger may mislead you. Probably better to output the value via qDebug().

I had a quick look, and the value seems to be (eventually) correct.