Unsure if the following is expected behaviour, but I doubt it is.

Reproduce:

• Start voxl-streamer listening to hires_front_small_encoded
• Connect to the stream (e.g., ffplay -i rtsp://<voxl ip>:<port>/live)
• Confirm that the stream looks good
• Disconnect from the stream (CTRL-C the ffplay command)
• Within 60 seconds, re-run the same ffplay command
• Observe that the stream looks good but will freeze within 60 seconds (e.g., the command is restarted 15 seconds after initially closing the connection. The new stream will freeze after 45 seconds
• Observe that voxl-streamer outputs Removed 1 sessions
• Disconnect from the new stream (CTRL-C ffplay)
• Observe that voxl-streamer outputs Removed 1 sessions again after 60 seconds

Based on behaviour and source code, what I think is happening:
When the first connection is closed, voxl-streamer detects this and decrements the number of clients. However, it takes 60 seconds for the gstreamer session to time out and close. During this time, if another client connects, there are now 2 gstreamer sessions and 1 voxl-streamer client. 60 seconds after the first connection is closed, the inactive gstreamer session is cleaned up. Since voxl-streamer doesn't know that this session was already inactive, when it closes, voxl-streamer decrements its number of clients even though the one client it has still has an active gstreamer session.

@Alex-Kushleyev Great, I'll be updating with how the tests go

Update: the filter was absolutely the difference maker

Awesome, thanks!

@Alex-Kushleyev
https://docs.modalai.com/voxl2-mini-linux-user-guide/
https://docs.modalai.com/voxl2-mini-connectors/#j7---camera-group-1-specific-pinout
The linux user guide says that i2c0 is on J7, but the connectors page only has i2c4 on pins 34/36. Could you confirm the correct bus and pin numbers here? I'm assuming i2c4 was on an older system image, in which case are the correct pins still 34/36?

Also, turns out we're only using one camera so J7 will be free. As for QUP0, that makes sense, thanks

Sort of a 2-part question:

On a VOXL2 mini, if I have both an M0155 and an M0181 on J6 and J7, is there any way to access i2c-0 on J7? I'm assuming if the coax adapter is on J7, there's no way to break out the i2c pins?

If not, then my other option is to use QUP0 on J19. I'm not running px4. Is it possible to somehow use that i2c bus from the apps proc? I've looked at libqrb5165-io and there doesn't seem to be anything for that. There's functions for accessing slpi UARTs, but only one port at a time?

Thanks

@modaltb As far as I can tell, I'm building a perf kernel. These are my changes:

MODAL_REPO_BRANCH=v1.8.02 in bin/qrb5165-common.sh

I've added the following lines to ./lu.um.1.2.1/apps_proc/poky/meta-voxl2-bsp/recipes-kernel/linux-msm/files/fragments/m005x.cfg:

CONFIG_MACVLAN=y
CONFIG_VLAN_8021Q=y

And then building:

./qrb5165-build.sh -m M0054

@Alex-Kushleyev Thanks for the info. For now, we're going to swap the sensor for one with the filter to see how it performs. I'll be updating results here

@Alex-Kushleyev To be sure, I cleaned the workspace and rebuilt the docker image as well. I re-synced, ensuring that the tag for the repos is v1.8.02. My voxl is also on SDK 1.4

Is this behaviour reproducible?

@Alex-Kushleyev I've tried the other driver, and the result looks largely the same. It's a bit brighter. (Cropped for file size)
My sensor indeed doesn't have the IR filter.