jellyfin crashing the whole nas

[adam12345]

anyone else using jellyfin with hardware transcoding crashes the whole system ? might be a memory i/o problem
didn't see something on the jeleyfin logs however ffmpeg seems to hog the memory until there is no i/o and the system just freezes

using native app 10.11.8.0 with qsv transcoding everything is on
f2-424 16gb

[TMzethar]

We are currently investigating a similar issue. If you try temporarily disabling QSV, does the crash still occur?

[adam12345]

well ill try to disable alltogather or to change to vaapi ?

[EriChan]

To rule out this variable, please disable hardware transcoding first. If the issue is resolved, upgrade Jellyfin to the latest version 10.11.15 and test again.

Also, could you let me know your current TOS system version?

Thank you for your cooperation.

[adam12345]

Hey,
i have not disabled the hardware transcoding yet
i noticed it only happens in large file i.e 40-50GB videos with 200MB chunks ,
cause it hasn't happened in a couple of days and i did not view anything which is more the 10gb

[EriChan]

Thank you for your feedback!

Please keep monitoring this issue. If the system freeze reoccurs when playing large files, please provide us with more details—such as your TOS system version, Jellyfin logs—so we can investigate further.

[adam12345]

i am using 7.0.804
here is alog and kern/syslog digest by claude :

Timeline

17:39:05 — kernel logs a mostly-benign warning: perf: interrupt took too long (2521 > 2500), lowering kernel.perf_event_max_sample_rate to 79000. This is often an early sign the system is under enough load that interrupt handling is getting delayed.
17:40:xx–17:41:33 — TOSDaemon is polling normally every ~5s (cpu/mem/net/disk/temp topics), right up to the last line at 17:41:33.
17:41:33 → 17:49:39 — complete silence. No shutdown sequence, no "System is powering down", no kernel panic, no oops, no watchdog trip, no pstore crash-dump recovered on the next boot. The syslog just stops mid-poll and resumes 8 minutes later with a fresh kernel boot (Linux version 6.12.63+ ... #15).

That pattern — a clean, mid-cycle stop with nothing logged before or after, and no panic captured — usually means the whole machine froze hard enough that it couldn't even write to disk/flush the log buffer, and it either sat there until a hardware watchdog reset it, or (more likely, given the multi-minute gap) someone had to power-cycle it.

What the ATOP snapshot (17:41:19, right before the freeze) points to as the likely trigger:

MEM: only 200MB free out of 15.4G (11.8G in cache — reclaimable, but still tight), with 225.9M dirty (unwritten data)
PAG: 203,264 pages scanned and 203,264 stolen in that single 30s window — that's the kernel aggressively reclaiming memory, essentially thrashing
PSI: iosome 24%, iofull 23% — a quarter of that window, tasks were stuck waiting on I/O
Top process: ffmpeg (jellyfin transcode), PID 40681, with RDELAY 8.28s (it waited over 8 seconds just to get scheduled) and heavy read/write (176M read, 208M written) during the sample

The full atop raw log confirms and sharpens the picture — and it also confirms atop's own logging went dark at exactly the same moment, meaning this wasn't a syslog quirk, the whole box actually froze.

What the raw atop data shows (times are UTC in the log, add +3h for your local time):

Time (local) Free RAM I/O pressure (PSI iofull) What's happening
17:35:19 3.76 GB — Baseline, healthy
17:35:49 860 MB — Free RAM collapses in 30s
17:36:19 330 MB — Stays pinned near-empty
17:36:49–17:41:19 150–300 MB climbing 0% → 23% Sustained, worsening I/O stall
17:41:33 — — Log goes silent (atop, syslog, kernel — all of it)
17:49:39 — — Fresh boot, no panic/oops/watchdog trace anywhere

The trigger, pinpointed: Right as memory collapsed at 17:35, a Jellyfin ffmpeg hardware transcode (PID 40548) was caught in D-state — uninterruptible sleep, meaning it was stuck inside a kernel call (disk or GPU) and couldn't even be killed. It was running with VAAPI/QSV hardware acceleration on the Intel iGPU (-init_hw_device vaapi=... -init_hw_device qsv=...), doing a seek (-ss 01:14:01) into a Matroska file, with unusually large buffering flags (-probesize 1G -analyzeduration 200M).

That process exited seconds later and a replacement (PID 40681 — the same one your original ATOP snapshot caught with an 8.28s scheduling delay) took over and kept running, writing transcode output steadily, right up until the freeze. Meanwhile disk-I/O pressure (PSI iofull) climbed continuously from 0% to 23–24% over those 6 minutes and never let up — this wasn't a brief spike, it was a steadily worsening stall.

Memory reclaim (pgscans) was heavy but oomkills=0 and memory-PSI stayed near zero, so this wasn't a classic OOM — reclaim was keeping up. I/O was the strained resource, not memory, even though memory happened to collapse at the same instant.

Bottom line: this looks like a hardware-accelerated transcode/seek that got a kernel-level I/O (likely GPU/DRM ioctl or disk) wedged badly enough to eventually take the whole system down with it — not a memory leak, not a clean kernel panic (nothing was ever flushed to pstore), just a hard hang requiring a power cycle.

[EriChan]

We appreciate your detailed feedback. Could you please update the app to version 10.11.15 via the app center and confirm whether the issue still occurs?

To help us pinpoint the root cause and prevent it from happening again, we recommend enabling Debug Mode:

1. Enable Debug Mode: Go to TOS Web UI > Help & Support > Debug Mode and turn it on so the system can record detailed logs during abnormal events.

2. If the issue reoccurs:

• Restart the device first.

• Download the debug logs, then send them with any other relevant files to our technical support team at [email protected] and attach the forum link and your forum ID as well.

• If possible, please note the exact timestamp when the issue occurred, as this will greatly assist our team in troubleshooting.

Note on Log Downloads: The debug package contains three files (kern.log, syslog, and atop_log). Due to their file formats, your web browser might block them. If you notice any missing files after downloading, please check your browser's download manager to allow and complete the download.

[adam12345]

i did at the beginning, however it is not 10.11.15 because it does not exist when you install uyou can see it is 10.11.0 , you should fix that...
actually that latest official jellyfin version is only 10.11.11 so > https://github.com/jellyfin/jellyfin/releases
therefor 10.11.8 is newer

i can't find the jellyfin logs , however i don't think there was anything i saw there that can point the issue

[EriChan]

The version in the App Center is our customized build modified and adapted based on the official Jellyfin release, so please refer to the version displayed in the App Center.

Could you please check and confirm whether your currently installed version is indeed the latest 10.11.15 from the App Center?

If you have confirmed that you are on 10.11.15 and the system freeze reoccurs, please restart the NAS, collect and send us the debug logs so our engineering team can investigate further.