Potential Tdarr bug
Posted by PinkyBroham
Issue: Tdarr QSV hardware transcode failing with Device creation failed: -542398533 / Failed to set value 'qsv:hwany,childdevicetype=vaapi' for option 'inithwdevice' — happens on a specific file (~9.4GB, "Iron Man"), 2 GPU workers configured + 1 CPU worker. Environment: Generic NAS, SparkBox v1.6.511, TDARRHWACCEL=qsv, JELLYFINHWACCEL=intel, JELLYFINRENDERGID/JELLYFINVIDEOGID unset (defaults apply). Steps taken, in order: Checked host /dev/dri — card0 owned by video (GID 44), renderD128 owned by render (GID 105). Correct ownership. Checked sb-tdarr's base docker-compose.yml — no groupadd present. Found docker-compose.hw.yml overlay already adds groupadd: ["${JELLYFINVIDEOGID:-44}", "${JELLYFINRENDERGID:-105}"] — correct GIDs, applied automatically since JELLYFINHWACCEL=intel and /dev/dri exists. Mistakenly added a duplicate groupadd: ["105"] to the base compose file — caused sparkbox up tdarr to fail: services.tdarr.groupadd array items[0,2] must be unique. Reverted the base-file edit; overlay's groupadd was already correct and sufficient. Ran docker exec sb-tdarr id — container runs as root (uid=0), with groups 0(root),44(video),105(messagebus). GID 105 present; label "messagebus" is cosmetic (image's internal /etc/group naming, GID number is what matters). Confirmed /dev/dri/card0 and /dev/dri/renderD128 visible inside container with correct perms. Ran docker exec sb-tdarr vainfo — fully successful: iHD driver 24.3.4 loaded, VA-API 1.22, full profile list (H264, HEVC, VP9, AV1, encode entrypoints all present). Confirms GPU + driver + permissions are 100% functional inside the container. Conclusion: hardware access is NOT the problem. The failure is happening specifically at ffmpeg's -inithwdevice qsv:hwany,childdevicetype=vaapi call inside whatever Tdarr QSV plugin/flow is running the job — hwany device auto-enumeration appears to be failing even though direct VAAPI access works fine (confirmed via vainfo). Ask for Tom: Is this a known hwany flakiness in the ffmpeg/libmfx build shipped in
3 replies
Chris wrote:
Really appreciate the depth here -- you saved us a step, because everything you checked (the GID wiring, device passthrough, vainfo working) is exactly how our Tdarr GPU setup is supposed to work, and it's all correct. So you're right: hardware access is NOT the problem on our end. The hwany auto-enumeration call happens inside Tdarr's own QSV plugin, not anything our scripts touch, so I don't have a verified answer for the flakiness itself -- didn't want to guess. Sending your full writeup over to Tom since he's better placed to say whether that's fixable from our side.
PinkyBroham wrote:
If it helps, after a few tdarr restarts, it is transcoding fine now, so something was a bit finicky. Might still be worth a peak.
Chris wrote:
Good to know it cleared up on its own — that intermittent behavior is a useful clue on top of your writeup, since it points toward something timing- or state-related rather than a hard config problem. I've added this note to what's already been passed to Tom so he's got the full picture, restart-and-recover included. No action needed on your end for now, thanks for looping back.