Recording - Preview release

Can I ask why it’s only the last three minutes of the process? We have gone from using FFmpeg ( no longer seems to work with VMware machines, interrupting selectors, and doesn’t look to be non-legacy convertible) been looking for a solution for this and this seems amazing, but if it’s only the last three minutes we will miss most of our hours-long processes, and be able to watch it handle error reporting only. Needs to be expanded to the whole video and reduced for the process after 3 months to errors only.
will be interested to see where this goes.

1 Like

thanks Andrew for the question and feedback! As the main use-case of the video recording feature is to troubleshoot faulted jobs, last 3 minutes would cover most failures. When you say you will “miss hours-long processes”, what was the use-case for those hour-long recordings?

As the customer, it is essential for you to have a complete and accurate understanding of the processes running in your organization. Video recording the entire process provides you with the ability to watch and review all stages of the process, including identifying issues that occurred throughout.

While the ability to record the last three minutes of a job is useful in some cases, it is not a sufficient solution for identifying the root cause of an issue that may have occurred hours earlier in the process. By only recording the last three minutes of a job, you may miss important information that occurred earlier in the process.

Additionally, being able to review the entire process E2E and then focus only on the errors at your discretion provides you with greater flexibility and control. It also allows you to have a comprehensive view of the process, which is especially important when dealing with complex workflows that involve multiple systems and stakeholders.

Therefore, as the customer, you should have the ability to choose whether to record the entire process or only the last three minutes, depending on your specific needs. By offering a whole recording, UiPath provides you with the ability to have a complete and accurate view of your processes, which is essential for efficient and effective operations.

2 Likes

thanks Andrew for the detailed feedback!

I have previously developed and used a video recording scope activity and have been using it for a few years at my organisation. It was giving us an advantage over competitors but I see that will now be ending :stuck_out_tongue:

My advice, based on long experience, is you should provide a few extra features. I am willing to share my tips as if I no longer have the advantage with my video features I’d like the UiPath ones to be as feature rich as mine.

My screen recordings can have the frame rate configured, which can really help with file size since as low as 1 frame per second is enough.

I have all the log messages that occur whilst the recording is happening end up as colour coded subtitles on my video track. I can toggle the log level with subtitle tracks (Trace, Info, Error etc is each its own track), this is very nice, especially to see the red errors when they occur.

I have it so that I can control the highlight on screen, the option you can toggle usually only in Studio. In this way I can have it highlight elements even on unattended bots. I have this so it can be toggled on or off, its extremely useful for debugging to see what elements the bot found.

Because my activity is a scope activity, it is able to be used discretely. We use it to record each transaction and for certain phases such as ‘start up’ (logging in). We also use it in documentation for recording unit tests.

I think it would be great if you allowed similar functionality to record discrete parts of the process, via a scope activity, which could then get attached to the job in the same way.

If we apply it to the reframework we could then have a recording around the job startup, around any job restarts and around the job close, then, per transaction, a recording.

This level of granularity is extremely useful.
I’d also strongly urge you to consider allowing the video recordings to be stored locally rather than always uploaded to the cloud in order to satisfy nervous IT security people and also allow a longer data redundancy policy.

2 Likes

Hi @Adrian_Tamas
We used Screenshots property of job recording. In our case, the duration is 80 seconds and frequency is 3 seconds. With detailed;

Process start time : 11:21:45

Start time of getting first Screenshot : 11:24:20
Last time of getting screenshot : 11:33:05

Error time of getting screenshot : 11:25:34

As a result, we obtained 25 screenshots. What does the connection between duration and frequency to obtained this 25 result?

hi Aygun,

I’m glad you tried the feature. Will use the details in our documentation and hope that it clearly explains how to set the feature and what each setting does. If not, it’s good feedback for us to perhaps explain it better:

Whenever a job fails, screenshots illustrating the last moments of the execution are available for download. […]

The following settings are available:

  • Scaling - Enables you to set the scaling of the screenshots in percent. The maximum value is 100. By default, this field is set to 100.
  • Frequency - Enables you to configure the time interval between screenshots, in milliseconds. The minimum value is 250. By default, this field is set to 500.
  • Duration - Enables you to configure the length of time before failure to start the recording, in seconds. The maximum value is 120. By default, this field is set to 40.

So working backward from the failure, if you’ve set the duration to 80 seconds (length before failure to start the capture) and a frequency of 3 seconds (3000 milliseconds, the frequency to capture the screenshots between failure time and duration set), I think you should have ~26 screenshots, so 25 seems about right.

The “Frequency” setting determines how often the screenshots are taken. If the frequency is set too low, there may not be enough screenshots to accurately diagnose the issue. Conversely, if the frequency is set too high, it can result in too many screenshots, which may be difficult to analyze. As a rule of thumb, it is recommended to set the frequency to a value that captures a reasonable number of screenshots without overwhelming the troubleshooting process. Knowing what your process does is key to getting this right.

The “Duration” setting specifies the length of time that the automation should be monitored before the screenshot feature is activated. This ensures that the screenshots capture the relevant information leading up to the failure. The duration should be set long enough to capture the critical steps leading up to the failure, but not so long that it captures irrelevant or unnecessary information.

Hope it’s clearer now. Let me know if further assistance is needed.

All the best,
Adrian

1 Like

Hi Adrian,

I’m trying to follow all new releases :slight_smile: Thanks for your detailed explanation.
I got how this property is used.

1 Like

Hello, I activated the recording function on one of my processes, however the has recording remains false. Do you have a solution ?

Hi Dimitri,

Please check that you have the right permissions. Please make sure you are executing on Cloud Robots - Serverless or your Robot versions are 2023.2 or above. Also make sure you selected well what you want to record - only failed or successful as well.

Thanks,
Adrian

1 Like

Doesn’t work with other Runtimes? I run my processes on Virtual Machines hosted in my company.

what Robot version do you have on the VMs?

Where can we see the versions of the robots? Thank you for your answers

@Adrian_Tamas ,
Can we make use of this feature if we have Robot hosted in company server and having Robot assistant version 2023.4 ?

Yes, it works with on-prem robots connected to Automation Cloud, as long as the version is 2023.4.

Is this capability available for Orchestrator on-prem 2023.10? i do not see the option when configuring a process. Do i need to enable anything at the tenant or server level?

thanks,
Ivan