Increase Limit Open Recording

Help Orchestrator
, ,
1

Dear All,

today we found that open recording only records max from the last 15 minutes.

does anyone know how to increase it?

thanks,
Indra

2

@irahmat

Ideally it is last 3 minutes and that is jot configurable as well

I hope you are talking baout recording from orchestrator

IMG_6223
IMG_6223828×618 101 KB

Cheers

3

yes correct. I am talking about Orchestrator open recording - record all jobs.

my understanding about your share is I cannot extend the length of time. :disappointed_relieved:

I still don’t know what does it mean of Frequency.

Here is what I have from Open Recording- Record all jobs with duration time of 15 Minutes.

image
image1356×164 10.2 KB

Cheers

4

@irahmat

Frequency is for screenshots and not the video

And that is weird that you are getting 15 minutes but lucky again that is the max

https://docs.uipath.com/orchestrator/standalone/2023.4/user-guide/about-recording#video

cheers

5

that is why I am wondering.

FYI I am using OC V2023.4.1 on-prem and Robot V2023.4.2.

hopefully, there is a way to extend the length of time in the future.

Cheers

1 Like
6

How did you get to record the last 15 mins?

7

no idea. I am wondering as well.

8

My team just noticed that we will only have the last 15 minutes of a job as well even if the bot has been running the same job for a few hours. I checked the settings for the process in question and we have it set to record all jobs.

image
image440×268 13.3 KB

Although the documents page does not call this out, I believe that the maximum recording length when set to all jobs is about 15 minutes. I’m unsure if the 3 minute distinction is for the failed jobs or failed queue transactions options as the documentation is unclear.

9

As I understand it the screenshots are for the video. Its basically your ‘frames per second’.

If the frequency is 250 milliseconds it means it will take a screenshot 4 times a second, which will give you the highest frame rate. I think 1,000 is actually acceptable as if something appears for less than a second then its gonna be super hard to see anyway and reduces the CPU strain.

10

So I made my own recording scope quite some years before UiPath so I have quite some experience in this sort of stuff, I didnt decompile their code to check its the same but I am fairly confident based on what I saw that I can explain why the limits on time are there.

Basically what happens in the background (assumptions withstanding) is that it takes a screenshot every x milliseconds (this is the frequency), it will then keep that screenshot in memory.

So on default frequency for 3 minutes that is 360 screenshots.
For 15 minutes its 1,800 screenshots.

Now, if you keep going (I have done this) eventually you keep taking more and more screenshots until you crash the memory usage cause you just use gigabytes and gigabytes of memory keeping the screenshots so far.

This is because all of this information is not yet compiled.
Once the recording is done the video gets compiled and compressed. The compression massively reduces the file size as uncompressed is basically like having all the screenshots in a folder together.

So after explaining all the context, as a result on the above and crashing the machine by using up all the memory if you don’t impose a limit, I believe UiPath does some sort of garbage collection which will throw away screenshots once you hit the limit, replacing old ones with new ones. This is a good thing.

I think perhaps the solution here is to look at splitting up your process abit or some other way to capture what you want to earlier on, I don’t think relying on longer than 15 or even 3 minutes in the recording will be safe or reliable.

11

Hi Jon,

Thanks for the additional information. My team’s processes use the recommended State Machine setup for working through our queues. This allows for our bots to continue executing a single job but process hundreds of queue items within an execution until it reaches an error or there are no more transaction items left to process. For the work the bots are completing, this is the preferred setup as they often need to process thousands of transaction items in a single day using a combination of APIs and GUI screens where no API exists.

For our usage, it would make much more sense to have the recordings per transaction item to avoid the memory limitations like you mentioned; however, there is currently no option to record all transaction items, only the failed ones. We prefer to have record of everything as there have been some cases of false ‘Successful’ transaction items and having the recording as a reference has helped us identify exactly what went wrong, whereas the logs have failed to help us identify the issue.

As far as splitting up our processes, due to the nature of the work that the bots are being tasked with, the inability to translate them into fully headless processes, and the limited availability of development and robot resources, that just isn’t feasible for my team to accomplish. I hope this additional context helps - if you have any suggestions for how to get around the recording limits for failed transaction items only and create something that will split the recordings into their transaction item parts, I’d love to hear them!