Hi all,
I just notice one of our system continue to record the video feed on the Blueos SD CARD once cockpit start on windows even if i no start recording button is pressed.
Is there any way to stop it?
Hi @SubseaLED,
Which BlueOS version are you running?
The BlueOS 1.5 betas have some experimental onboard recording functionality that originally was always recording, then switched to recording while the vehicle is armed, and more recently there’s some in-progress work so that it only starts recording when triggered to by Cockpit (in line with the surface recording). Note that using beta software is not recommended unless you are intentionally beta testing. It may be possible to disable the recorder service entirely from the BlueOS settings (via the cog at the bottom of the sidebar).
There are also a few Extensions for onboard video recording, which have different triggering conditions.
HI Elliot,
thanks for the quick reply.
In fact, i’m using the 1.5 Beta 35.
Is that affected by the autorecording?
Yes, as mentioned, there is onboard recording functionality being tested in the BlueOS 1.5 betas at the moment, and it is not currently controlled/triggered by the user.
Can you help to find the button to disable the recording?
I haven’t found anything into the system setting of blueos
Hi @SubseaLED -
I’ve only disabled the recorder process via AI SSH intervention. Can I ask what feature is driving you to still want to use 1.5 Beta versions? As Eliot mentions, you’re best suited to be using stable BlueOS, unless you’re testing a specific feature that 1.5 brings?
We would like to use the 1.5 as seems that with the 1.4.3 stable we have some weird behavior with 2 x DWE CAMERAS that costantly lose frames and drops the bitrate. With the 1.5 Beta seems that this is not present.
What’s the command to use for disable the recording?
As you’re already using a Beta version (1.5), I would recommend moving to 1.4-dev. This version is planned to be tagged as stable in the next weeks. It is much more stable than 1.5 and has the same video benefits, as it runs the same updated version of the video server (mavlink-camera-manager).
Hi @rafael.lehmkuhl ,
I made further test and seems that the stream problem Is caused by the latest cockpit 1.18 stable doesnt matter if i use Blueos 1.4.3 or 1.5.
Switching back to Cockpit 1.17 both dwe camera stream are again consistent.
Also, what’s the difference between blueos 1.4.4 and 1.5? Why is it keeping both versions under development instead to continue with only one?
Are you using the Desktop or Web version of Cockpit?
And are the streams using RTSP or WebRTC? You can check by right clicking your video player widget and clicking options.
Can you confirm the problem only occurs in 1.18, even if using the same version of BlueOS (ideally 1.4-dev, not 1.5 nor 1.4.4). I ask that because there were no changes in the video pipeline from 1.17 to 1.18, unless you’re using RTSP (which does not exist in 1.17).
1.5 has lots of changes, including some very significant and somewhat experimental ones.
1.4.4 is intended to get BlueOS to the point of fully supporting our upcoming RadCam camera, as well as enabling BlueOS+Cockpit to fully replace QGroundControl for most if not all of our ROV users. It’s a subset of the new features, but we still need to make sure it’s well tested and fixes any relevant gripes before we release it as stable.
While we would prefer not to split our development and testing efforts, we also don’t want to have unrelated software features holding up product releases. It’s also not uncommon for software to have a maintained stable release while a different version gets the full set of latest features - especially if some of those new features may not be compatible with older / lower spec hardware (e.g. it seems unlikely that onboard HD video recording will work for Raspberry Pi 3B CPUs, or vehicles without much onboard storage space on their SD card).
Cockpit used is the windows version.
Stream is WEBRTC.
I confirm that once downgraded again to 1.17 i’ve got stable streaming. No bitrate jumping or fps loss
Very interesting.
The only thing I can think about initially is around application performance itself, not directly related to the video, with the video being affected by consequence.
Could you share a log from 1.18 (/menu/settings/dev) and tell me your topside computer specs? CPU model, memory and GPU.
Also, if you could check the Task Manager during 1.18 usage and see how much (percentage) of the CPU is being used, that could help a lot. Even better if you can get a comparison with 1.17.
Hi Rafael,
log attached.
Both DWE camera are set to WEBRTC. Cockpit jitter set to 0 (With 1.17 was working good) Both TCP and UDP check are flagged ( With 1,17 was working good)
What i notice from the “Stats for Nerd” Bitrate jumps higher than the setpoint and frames also goes lower and higher than 30fps ( which is 15Mbit for one camera and 10Mbit for another - Constant bitrate)
Cockpit (May 15, 2026 - 11꞉06꞉02 GMT+2).syslog (684.2 KB)
PC processor load is lower than 20% ( i5 12th with 32GB ram)