Remind user to record stream on vehicle arming

[ArturoManzoli]

• On first time arming the vehicle there will be a popup asking the user to configure the auto recording parameters;
• Later, the user can find this settings at the Video Configurations menu;
• Persistent and non persistent settings can be applied. If remember my choice checkbox is marked, settings will persist.

https://github.com/user-attachments/assets/4e525f14-5a75-4925-81c1-725ae34c6c54

Closes #947

[rafaellehmkuhl]

Super cool!

[ArturoManzoli]

Last patch:

• Added an option to set a reminder for starting stream recordings. The reminder can have a custom delay relative to vehicle arming;
• The reminder has a distinct visual style compared to regular snackbar messages.

https://github.com/user-attachments/assets/bb7e1d49-050a-41c2-8a01-f447716d9252

[ES-Alexander]

Will review tomorrow, but just flagging that this shouldn’t occur if there are no video streams available - I haven’t checked whether that case is already handled.

[rafaellehmkuhl]

I didn't end up seeing a configuration popup on the first arm after a video stream was available, but that's likely because I had already gone in and played with the settings while I didn't have a video stream.

I think there's actually a bug around the cold usage. It didn't work here as well, and I didn't have accessed the configuration page yet.

@ArturoManzoli it worked after I've accessed the reminder config dialog for the first time. I think it's something related to that.

[rafaellehmkuhl]

If a user opens Cockpit and the vehicle is already armed, is the reminder going to kick in? The same for the auto-recording?

Since the feature isn't working here, I couldn't check this case, but I suspect it could be not doing it based on the watch logic, but I can be wrong.

After opening the dialog config and making the feature work, I could confirm that it does remind if Cockpit is open with the vehicle already online! Great!

[ArturoManzoli]

I didn't end up seeing a configuration popup on the first arm after a video stream was available, but that's likely because I had already gone in and played with the settings while I didn't have a video stream.

I think there's actually a bug around the cold usage. It didn't work here as well, and I didn't have accessed the configuration page yet.

@ArturoManzoli it worked after I've accessed the reminder config dialog for the first time. I think it's something related to that.

There was indeed a problem. It's fixed now!

[ArturoManzoli]

Almost everything is working. The only thing that is not is that if I open Cockpit with the vehicle already armed, it does not auto-record, nor sends recording reminders.

I misunderstood your first message about this issue. Now it's implemented correctly :)

[ArturoManzoli]

Almost everything is working. The only thing that is not is that if I open Cockpit with the vehicle already armed, it does not auto-record, nor sends recording reminders.

I misunderstood your first message about this issue. Now it's implemented correctly :)

Kapture.2025-03-27.at.12.58.14.mp4 Problem appears to still be there.

Ah, that's because the stream wasn't available yet when Cockpit finished booting. I'll take a look

[ArturoManzoli]

@rafaellehmkuhl ,

• Rolled back the object name to the original and changed the propriety to the suggested one;
• Changed to momentary and persistent configs on the video.ts store and vue component;
• Fixed the snackbar on single line.

[ArturoManzoli]

The code is good now and the functionalities are all working.

There's one big problem thought, probably related to the separation between the persistent and momentary settings: changes to the settings are not being reactively saved in the ref variable that uses the settingsSyncer composable, and thus any changes made (and saved) by the user are not being sent to the vehicle during that session, but only in the next one, causing an automatic change on startup, and thus a conflict, both undesirable.

I see what you mean.

In my understanding, copying the modified settings object (1) to the variable (2) that uses the blueOsStorage/settingsSyncer would be enough to write the new parameters on the vehicle.

(1) 
const handleCloseModal = (): void => {
  let currentOptions = { ...optionsSelectedByTheUser }

  **if (rememberChoice.value) {
    cockpitAutoRecordStreams.value = currentOptions
  }**

  videoStore.momentaryAutoRecordOptions = currentOptions
  visible.value = false
  emit('close')
}

(2) const cockpitAutoRecordStreams = useBlueOsStorage<AutoRecordVideoStreams>('cockpit-auto-record-streams', defaultAutoRecordingOptions)

Should it be done in a different way? Or is there something else interfering with the data saving?

[rafaellehmkuhl]

The code is good now and the functionalities are all working. There's one big problem thought, probably related to the separation between the persistent and momentary settings: changes to the settings are not being reactively saved in the ref variable that uses the settingsSyncer composable, and thus any changes made (and saved) by the user are not being sent to the vehicle during that session, but only in the next one, causing an automatic change on startup, and thus a conflict, both undesirable.

I see what you mean.

In my understanding, copying the modified settings object (1) to the variable (2) that uses the blueOsStorage/settingsSyncer would be enough to write the new parameters on the vehicle.

(1) 
const handleCloseModal = (): void => {
  let currentOptions = { ...optionsSelectedByTheUser }

  **if (rememberChoice.value) {
    cockpitAutoRecordStreams.value = currentOptions
  }**

  videoStore.momentaryAutoRecordOptions = currentOptions
  visible.value = false
  emit('close')
}

(2) const cockpitAutoRecordStreams = useBlueOsStorage<AutoRecordVideoStreams>('cockpit-auto-record-streams', defaultAutoRecordingOptions)

Should it be done in a different way? Or is there something else interfering with the data saving?

It's probably a reactivity problem, since you're replacing the object instead of its options or instead of reassigning its values (take a look on similar implementations happen in the codebase, using Object.assign.

Also, I just noticed you actually have 3-4ish sources of truth for all those settings, and you also have two variables connected to the useBlueOsStorage composable. There's no need for it and it will more likely cause conflicts between those two states.

My suggestion: keep only the two variables you have in the store (persistentAutoRecordOptions and momentaryAutoRecordOptions), and use the momentary one directly in the dialog component. You don't need other variables in the component, you can directly connect the inputs on the momentary options. Using more than those two escalates the complexity of the feature quickly and without need, and any maintenance on it (like the one currently happening) gets complicated.

[ArturoManzoli]

The code is good now and the functionalities are all working. There's one big problem thought, probably related to the separation between the persistent and momentary settings: changes to the settings are not being reactively saved in the ref variable that uses the settingsSyncer composable, and thus any changes made (and saved) by the user are not being sent to the vehicle during that session, but only in the next one, causing an automatic change on startup, and thus a conflict, both undesirable.

Also, on a test version, removing the momentary options states and always saving the preferences on the videoStore's autoRecordOptions variable (that is linked to blueosStorage via useBluosStorage composable), I noticed the same problem. The settings are not being immediately stored to the vehicle. Only after a refresh

Do you have any thoughts on that?

[rafaellehmkuhl]

The code is good now and the functionalities are all working. There's one big problem thought, probably related to the separation between the persistent and momentary settings: changes to the settings are not being reactively saved in the ref variable that uses the settingsSyncer composable, and thus any changes made (and saved) by the user are not being sent to the vehicle during that session, but only in the next one, causing an automatic change on startup, and thus a conflict, both undesirable.

Also, on a test version, removing the momentary options states and always saving the preferences on the videoStore's autoRecordOptions variable (that is linked to blueosStorage via useBluosStorage composable), I noticed the same problem. The settings are not being immediately stored to the vehicle. Only after a refresh

Do you have any thoughts on that?

Yup. It's on the previous comment.

[ArturoManzoli]

Last patch:

• Implemented suggestions about multiple sources of truth and keeping a single variable on sync with BlueOS;
• Lint fix.

[rafaellehmkuhl]

@ArturoManzoli could you squash the commits and also rebase over master (as there are conflicts with it) before I test? Just to make sure I'm running the final version.

[ArturoManzoli]

@ArturoManzoli could you squash the commits and also rebase over master (as there are conflicts with it) before I test? Just to make sure I'm running the final version.

@rafaellehmkuhl Done!

[ArturoManzoli]

Arturo, I'm having a pretty consistent behavior with this PR causing my vehicle to disarm when I open Cockpit.

The test is: arm the vehicle, restart Cockpit, it will disarm during Cockpit's boot.

The behavior as well as my auto-record configs can be seen in the video below:

It happens after I arm the vehicle within this branch for the first time.

I cannot reproduce the same behavior on master.

Hmm, that's odd. I'll replicate here and investigate

[ArturoManzoli]

Arturo, I'm having a pretty consistent behavior with this PR causing my vehicle to disarm when I open Cockpit.

The test is: arm the vehicle, restart Cockpit, it will disarm during Cockpit's boot.

The behavior as well as my auto-record configs can be seen in the video below:

It happens after I arm the vehicle within this branch for the first time.

I cannot reproduce the same behavior on master.

I was able to see the disarming once, on the first run, but never again. I tried switching branches, reloading the server, resetting settings, deleting cockpit profiles on the bag of holding... It behaved normally on every boot after the first one.

Do you have any idea what else can be done to reproduce that?

Maybe @ES-Alexander could test it locally also

[ArturoManzoli]

@rafaellehmkuhl I wasn't able to reproduce the disarming bug anymore here. Were you force arming?

[rafaellehmkuhl]

@rafaellehmkuhl I wasn't able to reproduce the disarming bug anymore here. Were you force arming?

This bug appears to have disappeared! Nice!

[ArturoManzoli]

Right now there are only two things that are happening that need to be resolved:

1. If you have more than one video stream, one of them will not be processed.

That's odd.. I'll check

2. Not captured in this video, but if the video stream takes sometime to load, the user will receive a "Media stream not loaded" warning dialog. This happened to me with the Radcam apparently. It does not happen all the time, but when it happens, it appears like the auto-record does not work.

Kapture.2025-06-05.at.11.29.11.mp4

That makes sense. Will take a look

[rafaellehmkuhl]

@ArturoManzoli it would be cool to get this one finished. It's a desired feature for a long time. It would also be better to merge it before working on any external video recording integration (dashcam or MCM).