[Bug] Transcode failure on Intel A310 on TrueNAS

[prospartan2]

Current Behavior

Anytime I try to use my A310 to transcode using this Handbrake container setup it fails with the following error shown in the TrueNAS console:

Apr 6 11:23:57 truenas kernel: traps: HandBrakeCLI[1414611] general protection fault ip:7f8a1adbf8ae sp:7f8a18167310 error:0 in libmfx-gen.so.1.2.13[7f8a1ab19000+4a3000]

I do not know what this means but I do know that the card is functioning correctly. It is used many times daily to transcode media for a Jellyfin server running on the same machine in another container.

Expected Behavior

I expect it to successfully transcode media with hardware acceleration provided by my Intel A310 using the Handbrake app in the TrueNAS catalog.

Steps To Reproduce

Attempt to transcode using hardware acceleration on Intel A310

Environment

• OS: TrueNAS Scale
• OS version: ElectricEel-24.10.2.1
• CPU: AMD Ryzen 9 5900X
• Docker version:
• Device model:
• Browser/OS:

Container creation

Container log

[autovideoconverter] Change detected in watch folder '/watch'.
[autovideoconverter] Processing watch folder '/watch'...
[autovideoconverter] Waiting 5 seconds before processing '/watch/C1_t03.mkv'...
[autovideoconverter] Starting conversion of '/watch/C1_t03.mkv' (64efb419373384af55c21830828dcd4e) using preset 'AUTOMATED/SuperHQ-H265-QSV'...
[autovideoconverter] 1 title(s) to process.
[xvnc              ] Sun Apr  6 11:23:47 2025
[xvnc              ]  Connections: blacklisted: 127.0.0.1
[autovideoconverter] Encoding /watch/C1_t03.mkv: task 2 of 2, 0.00 %
[autovideoconverter] Encoding /watch/C1_t03.mkv: task 2 of 2, 3.33 %
[autovideoconverter] Encoding /watch/C1_t03.mkv: task 2 of 2, 5.67 % (286.47 fps, avg 363.71 fps, ETA 00h01m59s)
[xvnc              ] Sun Apr  6 11:23:57 2025

Container inspect

Anything else?

I am using the H265 10 bit Intel QSV encoder. Attached is the preset.

SuperHQ-H265-QSV.json

[TNFB]

Hello !

From your logs, I suspect either a OOM or a bug with xVNC.

Can you please provide the conversion.log located at /mnt/nvme-mirror/app-configs/handbrake/config/log/hb/conversion.log ?

Also, does Handbrake generate the final file with a size of 0kb ?

[prospartan2]

Here is that log file

conversion.log

The file it creates is usually about 10mb

EDIT: Thanks for looking at this.

[aolszowka]

@prospartan2 You might want to try the Nightly builds, You may be affected by this bug https://github.com/HandBrake/HandBrake/issues/6786 which is fixed when going to nightly which changes the way they perform QSV videos.

The "tell" for me was this line in your most recently attached logs:

[matroska @ 0x7f89559bcac0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 33 >= 0

I experienced similar behavior in which handbrake crashes as mentioned in my above bug report.

[prospartan2]

Appreciate the response. I hope that fix makes it into a release sometime soon. Is there some sort of timeline on that?

Everything I do on my TrueNAS system is about ease of maintenance. I spend a bunch of time at work on similar stuff and I just don't want to spend any more than I have to maintaining things for home that take more than just a couple clicks after first time setup. Since this is not a critical need for my home setup, I'll just wait till it gets fixed in a full release.

[aolszowka]

Appreciate the response. I hope that fix makes it into a release sometime soon. Is there some sort of timeline on that?

No clue, I can say that within Windows this fixes the issue using the nightly I posted on that bug report.

I am actually attempting to try the nightly from within this container and I'm getting the container crashing when even attempting to encode files that I know worked previously. I've open a new issue (#409) to see if anyone else has experience with attempting to use Nightly with QSV. I would love it if you would be willing to test on your end to see if you see the same behavior (all encode attempts using QSV crash/fail rather than just a select few).

[aolszowka]

@prospartan2 It might be worth pulling the latest version of this container which is built on 1.10.2 which has the fix shipped. I have tested it myself with success, and would be interesting to hear from another user (and perhaps close out the issue!).