Jellyfin Instability and Crashes

[TheDreadPirate]

Just so we are clear, every time in the Jellyfin logs when Jellyfin is restarting that is YOU initiating the restart? If so, when you initiated the restart did you confirm whether the container was still running or not? Is this a case of Jellyfin crashing or just becoming unavailable on the network?

Another Unraid user had similar issues as you're describing, though I don't recall them mentioning Tailscale usage.

https://forum.jellyfin.org/t-solved-jell...-is-played

AFAICT, both in your case and this other user's case, Jellyfin doesn't appear to be the source of the problem. But I've only just started trying out Unraid.

You might be better served asking for Unraid specific help on the Unraid forum.

[Jam]

Correct, every single hold up with the container, I am manually restarting. The container will stay in a broken state until I physically fix it or my server backs up the container at 5AM.

The container is running yes, and often shows a load of we socket closing stuff. I am also able to use other services at the same time.

What is odd to me though is I’ve had this exact setup since the lifetime of my unraid server and not once had this ever occurred. This has only started happening within the last 2 weeks.

[Jam]

So i've just had my latest hold up, I didn't let it get to the point of crashing but everything was seizing up as usual.

I have captured another log file, incase anything shows.
https://gist.githubusercontent.com/JamsR...tfile1.txt

Also, this time I took a look at system usage and I see that Jellyfin is using a LOT more than than it normally does. It normally grabs about 9GB max, we're now up to 16.



Also, you can't see it too clearly in these next photos but Jellyfin is spiking up and using a lot of CPU power too.





I also went as far as rolling back to the previous Unraid version to rule out the factor of it being that update that could've potentially caused it, as the last one was where I had the most stability and it still occurs.

You can also see the CPU_TOTAL alert ran for a total of 2 hours and 13 minutes with 98% CPU usage.

I'm leaning more towards there's an underlying cause within Jellyfin.

[TheDreadPirate]

I see some direct streams going on near the end of the log where the audio is being transcodes, which happens on the CPU.

Code:

-codec:a:0 libfdk_aac

I'm not sure if output you are looking at also lists the processes jellyfin spawn. I know when I run btop on my host machine, I see the ffmpeg processes that my jellyfin container spawns.

It also looks like there were sometimes two simultaneous streams for the same content? Syncplay? Or just watching at the same time without syncplay?

Also, do you know if your monitoring distinguishes between reserved and cached memory usage?

Can you check if this docker environment variable is set?

MALLOC_TRIM_THRESHOLD_

[Bramble]

Recently I've also started getting this issue. The entire application grinds to a halt without any indication on what is happening in the logs - No jobs were running either. Has there been any changes since 10.9.6 that could have caused this?

[Jam]

Yeah, there's always a couple streams that are "Direct streaming" but this has never been an issue in the 6+ months i've been using this server, I had 10 friends watching all at once (as anymore is past my connection constraints) last night to stress test if it was anything related to that and was running perfectly fine, no issues at all.

Possibly, a few use SyncPlay instead of streaming on Discord, just easier and better that way but also could be a happy coincidence that two are watching at the same time, especially if it's a new/airing show.

I'll use btop to look the next time it happens, that way you're familiar with it. Those screenshots I sent are from Glances.

Code:

root@Home:~# docker inspect jellyfin | grep -i MALLOC_TRIM_THRESHOLD_
"MALLOC_TRIM_THRESHOLD_=131072",

[Jam]

Just happened again, using btop this time you can see everything just gets hammered by Jellyfin.



I'm also attaching my transcode settings, incase it's anything to do with that.

[Bramble]

EDIT: Fixing image and adding note that I am using linuxserver and not the default docker image like the OP.

Had a crash again this before which I cannot figure out the cause. Please could you take a look? I've attached logs as it happened and logs for startup after I had to restart the container. I had 4 connections at the time. Two re-muxming, a direct play and direct streaming.




Logs leading up and at the crash when users disconnect: https://pastebin.com/riK0AULq

Logs at startup after crash: https://pastebin.com/16X8YRRw

Any advice would be greatly appreciated. I can confirm after restarting the container, all the streams have re-connected and Jellyfin is operating as expected. What could be causing this?

[TheDreadPirate]

Can both of you enable debug logging in Jellyfin?

For the official image the logging config path is /config/config/logging.default.json. For the LSIO image it is /config/logging.default.json

At the top of the file you will see these lines.

Code:

{
    "Serilog": {
        "MinimumLevel": {
            "Default": "Information",
            "Override": {
                "Microsoft": "Warning",
                "System": "Warning"
            }
        },

Change "Information" and "Warning" to "Debug". Restart jellyfin after saving the changes. Replicate the problem then share the new log with us.

[Jam]

Hi!

It hadn't happened for the last day so I tried to replicate myself by opening some content that I had seen people watching at the time and i've managed to replicate!

It seems by opening a specific file type is where it causes the entire hanging process to occur. However, ending the session playback doesn't seem to stop the spiralling effect and it eventually will crash the Jellyfin container.

The file also seems to be "Direct streaming" is where it seems to happen, it's not a "specific" file, it's just one that seems to be effected.

I am unable to find a paste site that can take the payload but when I do, I'll post the extended log here.