From e215db2a576b71958412ede534e29ddd11cbc86a Mon Sep 17 00:00:00 2001 From: Gmer4Lfe Date: Sat, 23 May 2026 14:30:33 -0400 Subject: [PATCH] Warn that VRAM exhaustion masks --gpus fixes If PaddleOCR (or any GPU sidecar) holds all VRAM, --gpus will still appear to fail even when configured correctly. Added explicit callout: check nvidia-smi before concluding the GPU flag is wrong. --- Transcodes/Manual-Transcoding.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Transcodes/Manual-Transcoding.md b/Transcodes/Manual-Transcoding.md index 6af404a..69250a1 100644 --- a/Transcodes/Manual-Transcoding.md +++ b/Transcodes/Manual-Transcoding.md @@ -575,6 +575,16 @@ In EmbyCredits plugin settings, set the OCR endpoint to `http://localhost:8884`. The accuracy tradeoff is real (PaddleOCR is stronger on non-Latin scripts) but GPU starvation is not an acceptable failure mode for a live media server. +**If you just switched from `--runtime=nvidia` to `--gpus` and it still fails:** + +Check `nvidia-smi` before concluding `--gpus` is wrong. The flag may be correct and +something else may be holding all the VRAM. This is exactly what happens when the +EmbyCredits PaddleOCR container is running — PaddleOCR steals all available VRAM +while a credit scan runs and never releases it when the scan completes. Emby and +Jellyfin then have no GPU access regardless of how the GPU is passed to their +containers. The GPU assignment method is irrelevant when there is no VRAM left to +assign. Always confirm VRAM is actually free before troubleshooting container GPU flags. + --- ### Emby With NVIDIA GPU — bind-propagation=shared Fails to Start