fix quirks with recording controls

[beasteers]

The recording functionality on the dashboard had some issues around starting and stopping recordings and there was that bug where you'd need to refresh the page to start a new recording.

This version calls the start and stop endpoints directly and relies on a single source of truth about whether the recording is running which reduces the weird edge cases we were seeing.

Small thing is that using mutate doesn't seem to run at a strictly regular schedule so it can maybe use some tweaking but it is minor.

// update the recording info while it's active
useInterval(() => { mutate() }, recordingId ? 1000 : null)

[soniacq]

Apparently, the warning messages have been removed ( we actually want to keep them):
For example, if there is no connection with the server (there is no data streaming), we should keep displaying the message: "We couldn't connect with the server. Please try again!".
This is what is happening right now:

This is how was handled before (deployed version of the dashboard):

[beasteers]

I was having a bit of trouble understanding the conditional tree that was going on before.

Looking at what the dashboard shows and querying the API directly, it actually looks like it's showing errors when it shouldn't be - like when I hit stop recording on the dashboard it says "error please press again" but when I query the current recording via CLI (without pressing again), it says that the recording has been stopped - and the same thing goes with the start recording error.

You can try yourself if you'd like, just run

ptgctl recordings current

when an error pops up to see if it really was an error, or if the recording was really stopped/started.

I have a feeling that the previous version was reading too much into the return codes of the start/stop endpoints which reflects changes to the state in redis, but this newer version just uses the current recording query which should be a more reliable check.

[beasteers]

but to clarify, those status codes returned by the API don't look at whether or not data is coming in. So the recording should be active even without data and once you turn on the hololens it should start recording immediately.

[soniacq]

I understand your point. However, I still think we should prevent the user from hitting start recording if there is no data streaming. Otherwise, anyone who has access to the dashboard can hit the start button even though there is no hololens connected and we will start getting empty recordings.

[soniacq]

Opening issue #7. Prevent the user from hitting start recording if there is no data streaming.