UE5.5 jobs re-rendering frames — output check racing ahead of file write/sync
2 views
Skip to first unread message
Henrik Bach Christensen
Jun 5, 2026, 9:18:37 AM (2 days ago) Jun 5
to Royal Render Knights Tavern
Setup:
- Royal Render 9.1.16
- Render app: Unreal Engine 5.5 (Movie Render Queue)
- Output goes to local NAS.
Problem:
Some jobs render their frames a second time. The frames render very fast, and my read of it is that the rrServer's output check runs before the freshly written frames are fully flushed/visible on the share. The server sees them as missing (or too small), flags those frames, and reissues them to a client — so they render twice.
Questions:
1. Is there a way to make the rrServer wait a configurable number of seconds before performing the frame existence/size check after a client reports a segment done? If so, is it a per-job setting or a global rrServer/rrConfig value in 9.1.16, and where exactly is it?
2. Is the file-size check the more likely trigger here, and what's the cleanest way to set/relax the expected minimum size for UE5 MRQ output?
3. Is there a recommended UE5-specific setup for this (e.g. local render-out + copy) to avoid the file-visibility race entirely?
I can pull the frame log showing the re-send reason if that helps narrow down whether it's the existence check or the size check firing.
- Royal Render 9.1.16
- Render app: Unreal Engine 5.5 (Movie Render Queue)
- Output goes to local NAS.
Problem:
Some jobs render their frames a second time. The frames render very fast, and my read of it is that the rrServer's output check runs before the freshly written frames are fully flushed/visible on the share. The server sees them as missing (or too small), flags those frames, and reissues them to a client — so they render twice.
Questions:
1. Is there a way to make the rrServer wait a configurable number of seconds before performing the frame existence/size check after a client reports a segment done? If so, is it a per-job setting or a global rrServer/rrConfig value in 9.1.16, and where exactly is it?
2. Is the file-size check the more likely trigger here, and what's the cleanest way to set/relax the expected minimum size for UE5 MRQ output?
3. Is there a recommended UE5-specific setup for this (e.g. local render-out + copy) to avoid the file-visibility race entirely?
I can pull the frame log showing the re-send reason if that helps narrow down whether it's the existence check or the size check firing.
Thanks!
H
Reply all
Reply to author
Forward
0 new messages