telemetry Issue;
I have a problem with the telemetry over lay on the videos has stopped working , it sometimes records the ASS file but most of the time it will not
What can the issue be ?
how can I resolve it ?
thanks murdo
Hi @Mac1
What version of cockpit are you using?
Is your connection to the vehicle normal during use?
Hi @kurty -
The .ass file needs to have an identical file name to the video file (except for the extension.) You csn open the .ass file in a text editor to verify the contents are present.
The BlueOS version wouldn’t impact this, but 1.4.3 beta 9 is not a focus of development - the 1.4.4 branchs and 1.5 branch is, and it is NOT recommended to run beta versions unless you need specific new features they contain.
Hi Tony,
The .ass file appears to have the same exact file name and appears to have content when opened by a text editor. Is VLC the best app to try and play it? It doesn’t do anything when I try to play the .ass file
.
I thought I needed to run at least 1.4.3 for RadCam. Is there a better version of BlueOS I should be running to support RadCam?
Hi @kurty -
VLC is the only media player I’m aware of that will show the subtitles - otherwise they need to be “burned in” via handbrake so they show in any player, without requiring a .ass file.
If you play that .mp4, does it not show subtitles? Very strange if not! The video file seems quite small? Maybe worth creating a new one to test?
The latest 1.4.4 beta is best suited for RadCam, or better yet the next.14 branch on Joaos’ repository:
joaoantoniocardoso/blueos-core
However the BlueOS version should have 0 impact on the creation or playback of subtitles - just the quality of the video stream and support for the latest version of the RadCam manager extension! Something else is likely going on - what version of Cockpit are you using?
@kurty @tony-white if the subtitles are not loading automatically, you can open the video in VLC and then drag the subtitle files to inside the player. This will load them.
You can also use MPV, which is the one I usually use.
If none work, please send us the telemetry file so we can take a look and see if there’s any problem with it.
4K streams have lots of pixels, so the default subtitle size will look quite small if you’re playing back the video on the same screen you’ve previously used to view smaller video resolutions.
You can adjust the subtitle font size in the Overlay Options section in the top left of Cockpit’s Telemetry settings.
Kurt! - You have a RadCam!? How are you liking it so far and how was the integration/installation process? We are waiting patiently…
Hi @tony-white-
I’m also having intermittent issues with the .ass overlay telemetry file being created in the videos folder in cockpit. I see a red error box in the bottom left of the screen, in the same place where you get the green status “video processing complete” stating “failed to generate telemetry overlay.” See below. We’re running 1.4.3 BlueOS and 1.17.0 Cockpit. There is a DWE camera and the stock USB lowlight camera installed. I have the issue with both camera streams and it doesn’t matter if I only record one at a time, I am still getting the error and no telemetry file on either camera feed.
A couple of notes that may or may not be relevant:
After updating the sub to 1.4.3/1.17.0/4.5.7 from 1.4.0/1.15.2/4.5.3 I saw a significant drop in my available overhead bandwidth on a 150 m tether. I was running 70 MBps down 60 up and I’m now in the 30 MBps down 40 up range on the identical hardware setup. It seems like there is a significant lag between getting the failed to generate telemetry overlay error pop up and stopping recording. And, of course, sometimes it works fine. Was there an answer to @Mac1 on his originally posted issue on 3-MAR?
As always, thank in advance for any assistance. Please let me know if any logfiles would be helpful.
Josh
Hi @VisionSubsea -
That looks like an issue with bandwidth to me - maybe in the quality of connection the Fathom-X is making? Can you install the tether diagnostic extension and share a screenshot of its interface?
If you’re running dual cameras, it is likely worth updating to the latest BlueOS 1.4-dev as it has many improvements to MavlinkCamera manager.
Can you share the specifications of the machine you’re running Cockpit with? Are you using the standalone version?
It is also worth updating to the latest 1.18 Cockpit beta - it is very close to being a stable release and has relevant changes vs. 1.17.
Hi @tony-white -
Thanks for the quick response. See below tether diagnostics screenshot
And below PC specs:
I did just realize the internal storage is getting full. I will delete older files to clear up at least 200 Gb of space. I will also update BlueOS and Cockpit as suggested and let you know if I see any change in either available overhead or the telemetry overlay file issue.
Josh
Talking specifically about the telemetry overlays and snapshot system, 1.18 is a huge improvement. As Tony said, you should try. The stable is planned for next week, so the current beta (16) is a pretty stable release.
Hi @rafael.lehmkuhl and @tony-white:
Thanks for sharing! I see the improvements in 1.18 beta 16. That is all very exciting.
Unfortunately it has not resolved the .ass file not saving issue. In fact, I had trouble even creating a video file in 1.18 b 16. It would flash “video processing complete” but the mini widget would not revert back to the red circle and the video feed: it would read 0:00:00 like it did in pre-1.17 builds while videos were processing. When I try to exit Cockpit it won’t let me because “Video Recording is in Progress”.
I did try updating BlueOS to both 1.4.4 beta 7 and 1.4.4 dev, but that gave me pixalated video issues on both camera feeds. Interestingly, it solved low available download bandwidth, but I’ve reverted back to 1.4.3 where I have clean video feeds. I also reverted back to 1.17. The first five test recordings I made after reverting had .ass files with them. The only note I have is that it seems to take a long time for the overlay file to populate in the Cockpit video folder and I suspect I still have a config issue somewhere as I still have slower than usual network tests; I don’t think it’s hardware because it went away with the BlueOS update to 1.4.4 versions.
For now the overlay file seems to be populating, though other than reloading BlueOS and re-installing cockpit I’m not sure that I did anything to affect the issue. I will circle back to the new builds as they come out as stable versions and advise if I have any further info on this issue.
Thanks,
Josh
That’s an interesting case. Could you send me the Cockpit logs from the 1.18 beta16 sessions? You can find them on menu/settings/dev.
Taking time for the video recorder to exit the 00:00:00 state after clicking to stop usually means your system is struggling, as this should usually take less than a second. Are you running any other software in parallel to cockpit? Maybe Chrome with several tabs open? Or a screen recorder? I would take a look at the System Manager, and see what is taking the most CPU and Memory during your usage of Cockpit, as this really seems like a system resource constrain.
If there’s anything other than resource problems happening, the logs will probably give us a clue.
Hi @rafael.lehmkuhl -
The only thing I noted regarding high usage was when I had to use Task Manager to close cockpit b/c I was unable to close out of it due to the “recording in progress” message there were 3 instances of Cockpit related functions running and the main function was consuming 47% cpu. This had my total CPU use at 72%.
Here are the logs. I’m not sure exactly which ones are 1.17.0 and which ones are 1.18; my apologies for the extras. Let me know if there is anything else that might help.
Josh
Cockpit (Apr 28, 2026 - 16꞉50꞉40 GMT-8).syslog (836.1 KB)
Cockpit (Apr 28, 2026 - 16꞉52꞉57 GMT-8).syslog (800.5 KB)
Cockpit (Apr 28, 2026 - 16꞉57꞉29 GMT-8).syslog (734.4 KB)
Cockpit (Apr 28, 2026 - 16꞉58꞉52 GMT-8).syslog (2.4 MB)
Cockpit (Apr 28, 2026 - 17꞉01꞉32 GMT-8).syslog (982.2 KB)
Cockpit (Apr 28, 2026 - 17꞉04꞉11 GMT-8).syslog (1.8 MB)
Cockpit (Apr 28, 2026 - 17꞉08꞉39 GMT-8).syslog (995.3 KB)
Cockpit (Apr 28, 2026 - 17꞉18꞉12 GMT-8).syslog (1.0 MB)
Cockpit (Apr 28, 2026 - 17꞉20꞉07 GMT-8).syslog (1.1 MB)
Cockpit (Apr 28, 2026 - 17꞉23꞉06 GMT-8).syslog (155.9 KB)
I have a few more but they will not upload. Let me know if you would like me to email.
On 1.17 the telemetry was indeed not being generated because of a bug, that was fixed on 1.18, but from your 1.18 logs there were actually no telemetry generation bugs happening. The application was just struggling to continue. The 72% CPU usage that you mentioned is for 1.17 or 1.18? It looks from the logs like it was probably close to 100%.
My recommendation would be to first of all try running 1.18 in another machine with better specs and see if the problem goes away. I imagine they will. We are putting work on reducing the system requirements on Cockpit, but specially when dealing with multiple cameras this can be difficult.
An extra check that it’s worth doing is taking a look in the GPU section of the Task Manager to confirm the video stream is being decoded on GPU, not on CPU (which would be a big burden). Putting Plotter widgets in Cockpit pointing to CPU and Memory usage will also tell you live if you’re operation on the edge.