Summary
On Live Link Face for Android (Beta) 1.2.0 (versionCode 139), takes larger than ~2 GB can neither be exported in-app nor downloaded via Live Link Hub’s Capture Manager. Smaller takes (tested up to ~1 GB) work fine on both paths.
Device: Google Pixel 7 Pro (Tensor G2), Android 16 (build CP1A.260405.005). Companion: Live Link Hub / Capture Manager, UE 5.8.1, Windows 11.
In-app export of a large take hard-crashes the app with a native SIGABRT:
Abort message: ‘Scudo ERROR: internal map failure (error desc=Out of memory)’
backtrace: libc abort → scudo::die → scudo::reportMapError → scudo::MemMapLinux::remapImpl → scudo::MapAllocator::allocate → scudo_calloc → libflutter.so (BuildId c5ad333303d9470f82282e3003bf27b0a32df737) → libapp.so (BuildId dbcf9df9721870ff12fa88920841e9f3)
Register state at abort included exactly 0x7FFFFFFF, suggesting a 2 GB signed-32-bit boundary in the packaging/streaming path. Reproduces immediately after device reboot with nothing else running — this is not ambient memory pressure; the export/transfer path appears to buffer the take (or one of its files) in memory instead of streaming it.
Capture Manager downloads of the same takes fail mid-stream with “Ingest failed : No pending data on socket (Error code : 4)” — each large take fails on every attempt, on both Wi-Fi and USB-tethered connections (so not a network issue).
Impact: long performance-capture takes (the exact MetaHuman Animator use case) become permanently trapped on the device — no export, no Capture Manager download, and Android app sandboxing offers no manual path. I cannot get the takes from a full day shoot.
Please store takes in shared/external storage on Android like the iOS app effectively does, so users aren’t dependent on the export code path. Then I could access the takes simply by plugging the phone into my computer and grabbing them, not relying on the app which is crashing.
What Type of Bug are you experiencing?
Virtual Production
Steps to Reproduce
- On a supported-or-not Android device (tested: Pixel 7 Pro, Android 16), record a video only take with an external UVC camera long enough to exceed 2 GB (~15+ minutes at 60 fps target).
2a. In the take browser, choose Export / save as zip. Observe the app crash partway through packaging (native SIGABRT, Scudo OOM — see Summary).
2b. Alternatively, connect the device to Live Link Hub’s Capture Manager and queue the same take on the Download pipeline. Observe the job fail mid-transfer with “Ingest failed : No pending data on socket (Error code : 4)”. - Repeat either path: the same take fails at the same offset every time, over Wi-Fi and over USB tethering. Repeat with a take under ~1-2 GB: both paths succeed.
Expected Result
Takes of any size export successfully and download successfully through Capture Manager, regardless of duration — or, the app records to a exposed folder so the take can be transferred through a file manager.
Observed Result
Takes over ~2 GB: in-app export crashes the app (native SIGABRT, “Scudo ERROR: internal map failure (error desc=Out of memory)”), and Capture Manager downloads fail mid-stream (“Ingest failed : No pending data on socket (Error code : 4)”) at a consistent per-take offset on both Wi-Fi and USB. The takes remain trapped in the app’s private storage with no way off the device. Takes under ~1-2 GB export and download normally.
Affects Versions
5.8
Platform(s)
Android
Upload an image
For crash reports, include your callstack
Build fingerprint: ‘google/cheetah/cheetah:16/CP1A.260405.005/15001963:user/release-keys’
ABI: ‘arm64’
Timestamp: 2026-08-13 14:27:18
Process uptime: 1456s
Cmdline: com.epicgames.facelink
pid: 24620, tid: 24620, name: cgames.facelink >>> com.epicgames.facelink <<<
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: ‘Scudo ERROR: internal map failure (error desc=Out of memory)’
x13 000000007fffffff (register at INT32_MAX)
backtrace:
#00 pc 00000000000754ec /apex/com.android.runtime/lib64/bionic/libc.so (abort+156)
#01 pc 000000000005b018 libc.so (scudo::die()+8)
#02 pc 000000000005bcfc libc.so (scudo::reportRawError(char const*)+28)
#03 pc 000000000005c42c libc.so (scudo::reportMapError(unsigned long)+172)
#04 pc 000000000005b8f0 libc.so (scudo::MemMapLinux::remapImpl(unsigned long, unsigned long, char const*, unsigned long)+208)
#05 pc 0000000000060cd8 libc.so (scudo::MapAllocator<scudo::SecondaryConfigscudo::AndroidNormalConfig>::allocate(…))
#06 pc 000000000005d5f4 libc.so (scudo::Allocator<scudo::AndroidNormalConfig, &scudo_malloc_postinit>::allocate(…))
#07 pc 000000000005d1f0 libc.so (scudo_calloc+48)
#08 pc 0000000000057478 libc.so (calloc+56)
#09 pc 000000000083b1a8 libflutter.so (BuildId: c5ad333303d9470f82282e3003bf27b0a32df737)
#10 pc 00000000008d143c libflutter.so
#11 pc 0000000000383e74 libapp.so (BuildId: dbcf9df9721870ff12fa88920841e9f3)
#12-#17 libapp.so (further app frames)
#35-#38 libflutter.so
#39+ Android runtime / Looper / ActivityThread.main
60 total frames — full tombstone (tombstone_30) available on request.
Additional Notes
The exact Live Link Hub error when downloading affected takes via Capture Manager is: “Ingest failed : No pending data on socket (Error code : 4)”. Identical over Wi-Fi and over USB tethering — while smaller takes download fine over both. Combined with the on-device SIGABRT during export, this looks like the app-side transfer/packaging path buffering file data in memory and aborting at a ~2 GB boundary, taking the socket down mid-stream.
Possibly related environment note: on the same setup, Live Link Hub 5.8.1 also crashes when loading any saved config or restoring an autosave (Assertion failed: IsValid() SharedPointer.h:1133) — reported separately: Live Link Hub 5.8.1 crashes loading ANY saved config or restoring autosave (Assertion failed: IsValid() SharedPointer.h:1133)
Tested on Live Link Face Android 1.2.0 (versionCode 139), minSdk 33 / targetSdk 36. The app’s external storage dir stays empty (takes live in internal app storage), so there is no manual recovery path on an unrooted device — a fix that makes existing takes transferable would rescue currently-trapped production takes.