@michaelstrunz1814414 @paulfletcher5705292304 Thanks for sticking with this and reporting back after the 4.1.2.0 upgrade. The original upload-side defect on long sources is patched in 4.1.2.0, but what you’re describing now looks like separate issues — we’d like to dig into each one with you.
—
1) FabCloud — audio mostly silent after colorization (@michaelstrunz1814414)
This is the first report we have of audio loss specifically from Video Colorizer AI, but we already have several similar reports against other AI modules (RTX HDR, Face Enhancer, Smoother, Upscaler) where the remux step drops or desyncs the audio. So this is almost certainly a remux/container-side bug on our end — not your source, not your hardware.
To escalate it properly, please tell us:
- Source container + audio codec (MP4 / MKV / TS, AAC / AC3 / EAC3 / DTS / TrueHD / …)
- Source duration, and the segment length you uploaded
- Which third-party tool you used to “fix the header” — MKVToolNix? FFmpeg
-c copy? Something else? This is critical for us to reproduce.
- If you can still keep a copy of the broken FabCloud output plus the original source, that pair alone would let our dev team reproduce in one shot.
—
2) FabCloud 4.1.2.0 — does it still fail on long sources? What duration? (@michaelstrunz1814414)
You mentioned your first FabCloud attempt on a 39-minute segment stopped after about an hour, and only the second attempt succeeded. To confirm whether the 4.1.2.0 upload fix is actually holding up on the cloud side, could you answer:
- Was the segment that failed on the first cloud try still 39 minutes, or shorter?
- Was it a clear FAILED state, or a hang/crash like the old defect?
- Since upgrading to 4.1.2.0, have you tried a longer cloud source (say 50–60 minutes)?
If long-source FabCloud is still flaky on 4.1.2.0, that’s a regression we need to flag immediately.
—
3) Local 4.1.2.0 extremely slow (@paulfletcher5705292304)
15 hours for a 3-minute clip is far outside normal — on a mid-range NVIDIA card the local Colorizer usually runs from near real-time to a few times the source length. This kind of slowdown is almost always a hardware-acceleration problem (the model falling back to CPU, or running on an unsupported GPU path), not a defect in the colorizer itself. So we need to confirm your local environment first.
Please share:
- GPU model + driver version (e.g. “RTX 3060, driver 566.36”)
- CPU model and total system RAM
- During that 15-hour run, was GPU utilisation actually moving? Task Manager → Performance → GPU → check “Compute_0” or “3D” — if it stayed near 0% the whole time, that basically confirms CPU fallback.
- OS version (Windows 10 / 11, build number if you have it)
- The UniFab log from that run:
%AppData%\UniFab\UniFab.log
Once we have the log and GPU info, we can tell you whether to update the driver, switch model precision, or whether this is a genuine new bug on that GPU family that we need to chase.
—
Thanks again for the detailed reports — these are exactly the data points we need to track down both the remux audio issue and the local performance regression. We’ll follow up here as soon as the dev team has progress.
