wabun

Thank you both for your responses. I've attempted a variety of potential fixes and may eventually open a new thread of my own to solicit advice if I don't work this out over the next couple days... @mhaaland For me, it seems to extend beyond just a browser issue--some kind of actual hardware crash/freeze. I'm unable to SSH into the system, either, and when I finally plugged in a monitor and keyboard, I found I was unable to interact with the command line on the actual system when the next crash came around. @robertkmy I'll try removing the docker image, redownloading containers, and removing/reinstalling plugins, too. Thanks for the ideas of other avenues to look into. For what it's worth to future readers, my diagnosis journey has included the following: Turned off Docker, VMs, SMB. For me, still crashed with all of these turned off, so I don't think they're an issue. Haven't yet tried aggressively removing plugins as @robertkmy suggested, nor of returning system settings to defaults. memtest86, once with a single pass, and once overnight for 6 passes. Still experienced several crashes in the hours/days following these tests. Removed and reseated RAM before the long, overnight test. I don't feel like I've ruled bad RAM out yet and will consider even longer, 24+ hour runs if necessary. Also haven't yet tried running the server on one stick of RAM and then the other and seeing if crashes appear in either or both scenarios. Changed docker network from macvlan to ipvlan. Still crashed after the change. Probably wasn't necessary, but also innocuous to my current setup. May eventually go back to macvlan as the need arises. Reseated PSU cables. Have yet to try reseating other cables (SATA, etc.), or to try removing the system from its case entirely. I don't remember experiencing any crashes before this mobo was mounted in its case and I had all the cables routed, and I believe I had the system running like that for several long, uninterrupted periods. Is something in the case shorting the mobo? Did I damage something during the move? I don't think so, but I haven't ruled it out yet. Removed an HDD that hadn't been connected before the crashes became apparent. Continued to crash even after this device was unattached. Moved to a new USB stick (by using a backup .zip/copying contents of old stick)** To be honest, the stick I started on was a junker, just to give this system a Trial license while moving data, with the end goal of swapping it to a better stick that was already tied to a license. Still crashed once on the new stick, so went a step further and rebuilt boot drive from scratch with Unraid USB Creator and copied over only the /config/ folder from the old stick. Took a look at scheduled events on the server (Mover, User Scripts) to see if crashes lined up or were occurring at any predictable time of day/event. Unresolved, but leaning toward the likelihood that crashes are happening at random times. Began capturing syslogs on USB and a local rsyslog server. Changed Unraid WebUI theme back to default (one of my syslogs was showing some weird style.css errors) Discovered a Reddit thread with a user reporting similar syslog errors. User followed up to say that in their case, it ultimately came down to a corrupt USB stick. In my case, no other suspicious syslog entries, at least that I can spot. Stress tested with Prime95 for a couple hours No crashes during the test, so either I've resolved it in one of the previous steps, or...? Will consider running Prime95 overnight if I experience yet another crash. And some other avenues yet to explore: Haven't yet tried running the server in Safe Mode to see if a crash still occurs in that condition. Considering pulling out an old nvme drive that I put in there to act as a write cache. Before the crashes began occurring, I had that disk set up as its own pool but with no data on it. Hunting around in BIOS settings/returning BIOS to factory defaults. I'm currently at about 12 hours with no crash, but I've had windows of stability that long before, so nothing conclusive yet. Edit (Oct 2025): Coming back to this for anyone who might stumble across it in the future. My issue ultimately seemed to stem from corruption on the USB boot drive. When I copied over the contents of the old boot drive to a new USB stick, the corrupted file was apparently copied over as-is, resulting in continued instability even when I was booting with the new USB stick. A proper rebuild resolved the issue (I can't remember after which step I finally achieved stability, but it was either after I'd used the Unraid USB Creator tool and copied over only /config/ as noted in the post above, or after I performed an OS update within the Unraid interface, as 7.1.3 had recently been released).

Hello, I just submitted a bug report on Github for an unrelated issue (regarding Japanese fonts), but was reading this thread. Actually, I also experience the same issue as @Wietsche , as well. If any paths are left filled in for the folder pair bars of [Last Session], the container will automatically run a Compare on these folder pairs on startup. My workaround has been to be careful to clear out the paths or to click "New Config" before shutting down the container, but I agree, it would be nice if this wasn't an issue. For what it's worth, I don't have any scheduled jobs or saved configs and have been typing in paths and running all my syncs manually for the time being, so I don't think this issue is related to cron/batch jobs. (And again, thank you for your work maintaining this container. It's awesome!)

@robertkmy Did you ever make any further headway on this? I'm experiencing similar symptoms (WebUI goes down, have to perform a hard shutdown) and have just begun the process of collecting syslogs. One pass of memtest came back clean (and half a dozen passes several weeks ago, before the server was more fully set up). Looking for any other ideas of where to look based on others' experiences.

I'd just like to chime in for others arriving at this page via web search that I was successfully able to enable Intel QuickSync transcoding for ghcr.io/binhex/arch-jellyfin (10.10.7-1-01) on Unraid 7.x by following these directions. My hardware is different than the thread title, but the steps worked nonetheless: This is with an Intel 12th gen with UHD 730. All of the comments and screenshots above were extremely helpful to me. My steps were as follows: While not necessary for the transcoding, this first step makes it easy to tell whether Jellyfin is successfully utilizing your GPU: In the unRAID Web UI, select Apps, then search "gpu statistics," and install first ich777's Intel-GPU-TOP and then b3rs3rk's GPU Statistics. Go to Settings (or Plugins) > GPU Statistics, and the top field (Unit ID for Dashboard) should now have a pulldown menu option for the Intel GPU. Select it, scroll down, and click "Apply." As @Glutao explains further up in the thread, open up the unRAID terminal (in the default theme, there's a button for it up in the top right of the unRAID Web UI) and run the following commands: sudo mkdir -p /etc/modprobe.d sudo sh -c "echo 'options i915 enable_guc=2' >> /etc/modprobe.d/i915.conf"The first command in Step 2 creates a folder called /etc/modprobe.d in your unRAID filesystem. The second creates a file called i915.conf inside that folder and populates it with the string: options i915 enable_guc=2 In my case, I skipped the first command: the i915.conf file did not exist on my unRAID system before running the command, but the modprobe.d folder did already exist. EDIT: On further reading (as per https://jellyfin.org/docs/general/post-install/transcoding/hardware-acceleration/intel/#low-power-encoding ), it looks like my 12th gen iGPU has enable_guc=3 on by default, so for my case, I'm removing this setting. In the unRAID Web UI, select Tools > System Drivers, and scroll down to find "i915." There should be an entry in the far right column (under the header "MODPROBE.D CONFIG FILE") that confirms creation of your new string. This needs to persist on reboot, so reboot your unRAID server and make sure it's still there afterward. Finally, it's time to modify the Jellyfin Docker config. Assuming you already have the container installed, click on the Jellyfin icon in the Dashboard, select "Edit," and in the config view: Scroll to the bottom, click on "Add another Path, Port, Variable, Label or Device" and in the Popup window: Config Type: Device Name: [whatever you want; this is just a label inside the Docker config view] Value: /dev/dri Description: [whatever you want; consider writing a memo to yourself that this was the flag you added to enable hardware transcoding] Click "Add" to dismiss the popup and then "Apply." Start the Jellyfin container and open up its Web UI. You'll need to be logged in with a Jellyfin administrator account, such as the one you created when you first set up the container. Click on the hamburger menu in the top left, select Administration > Dashboard On the new left-hand pane, select Playback > Transcoding For Hardware acceleration, select Intel QuickSync (QSV) from the pulldown menu For QSV Device, type in: /dev/dri/renderD128 Scroll down a bit, tick the box for "Enable Tone mapping" Scroll to the bottom, click "Save" Probably not necessary, but restart the Jellyfin container for good measure. After doing this, I was able to playback some media on Jellyfin Media Player, force a low kbps quality during playback, and confirm on my unRAID Dashboard that the GPU was being utilized by the Jellyfin container. I've noted @FRU's issue with HDR content and will keep an eye on it but haven't yet encountered issues myself. Hope this helps someone else in the struggle to enable hardware transcoding!