Summary
Creating a Full Rig (Joints and Blend Shapes) for a MetaHuman Character consistently fails. The request is accepted and issued a job ID, reaches 75% / RUNNING, then the status poll never returns. The editor times out at 300 seconds, reports “Server Error”, and returns the character to the unbound state.
The detail I want to flag is the poll itself:
LogHttp: Warning: HTTP request timed out after 300.00 seconds URL=https://mh-uemhc-autorig-service.eeeb.live.use1a.on.epicgames.com/v1/autorigs/?waitSeconds=10
LogMetaHumanCharacterEditor: Error: Auto-Rigging of Face failed with code ‘Server Error’
That is a long-poll requesting a maximum hold of 10 seconds. It hung for 300. Existing reports of this issue have read the 300s figure as evidence that the Full Rig solve is simply too slow, but waitSeconds=10 suggests the client is waiting on a poll that was never answered, which is a different problem.
Joints Only succeeds on the same machine in the same sessions, at 198.243s and 153.145s. Full Rig has failed 4 for 4, including under a separate Epic account.
What Type of Bug are you experiencing?
Animation
Steps to Reproduce
- Windows 11, Unreal Engine 5.8.1 (++UE5+Release-5.8-CL-56057345), MetaHuman Character and MetaHuman Live Link plugins enabled, signed in to an Epic account.
- Create a new project and a MetaHuman Character from a default preset, with no custom or conformed mesh.
- Run Joints Only. This succeeds in roughly 150-200 seconds.
- Run Full Rig (Joints and Blend Shapes).
- Observe the request is accepted, reaches 75% / RUNNING, then fails after 300 seconds with “Server Error”.
- Repeat. The failure reproduces every time, with a new job ID each attempt.
Expected Result
The AutoRig service returns the completed rig data, the MetaHuman Character becomes Full Rig bound, and the editor continues without an HTTP timeout or Server Error.
Observed Result
Four consecutive Full Rig failures, each with a distinct job ID, each timing out at exactly 300.00 seconds on a waitSeconds=10 status poll:
7ee070f5-fa85-489b-8cc7-c463ea95facc
dd672577-89b3-49df-9c92-c61b4aebb917
e8d7967f-480a-4d00-9c64-20d172c5f6ff
8bc76173-6046-43dd-a605-06bcc337dd3c (submitted under a separate Epic account)
Joints Only succeeded on the same machine in the same sessions:
198.243 seconds, default-preset character, project A
153.145 seconds, default-preset character, project B
There are no LogHttp connection errors in any of these runs. No dropped connections, partial reads, retries, or libcurl errors. The Joints Only transfers completed cleanly to the same host in the same sessions, so the route to us-east-1 is healthy.
Variables tested and eliminated: two separate machines, two default-preset characters with no custom or conformed mesh, two separate fresh projects, and two different Epic accounts.
Affects Versions
5.8
Platform(s)
Windows
Additional Notes
On testing the account variable: switching Epic accounts requires signing out inside the MetaHuman Cloud Authentication dialog specifically. Signing out of the Epic Games Launcher is not sufficient. The plugin reuses its own cached credential and silently re-authenticates the previous user, while the launcher UI shows the new one. I confirmed the switch had actually taken via the LogMetaHumanAuth “User name is” line and a differing AccountId before running the fourth attempt.
One caveat on that fourth run: the second account is newly created and returned errors.com.epicgames.eos.auth.user_not_found on an EOS TokenGrant call. I do not believe this is causal, since the AutoRig service still accepted the request and issued a job ID, but noting it for completeness.
Per an earlier report on this issue, [HTTP] timeout values in DefaultEngine.ini have no effect. The request still times out at exactly 300.00s regardless of configured values, so the limit appears to be enforced inside the plugin rather than read from config.
Request: the four job IDs above should be inspectable server-side. Determining whether those jobs completed, stalled, errored, or were never scheduled would distinguish a genuinely long solve from a status endpoint that stops responding. If it is the latter, raising the client timeout will not fix this.
Related threads: