SOLVED: Jellyfin becomes unresponsive when transcoding

[Henkow]

I have an issue that manifest itself when transcoding larger files. During playback a new tab will result in the spinning wheel. It appears the UI is technically still reachable as I can refresh a tab with a logfile open, but it's so slow that I can't get to the homepage. The playback itself also buffers occasionally and may even buffer indefinetly despite the transcoding being way ahead (it keeps transcoding at around 5x speed). I'm wired and if I try to read a file while also writing another to either the HDD which houses the movie or to the SSD were the transcoded file is stored, I have no issue reaching +100MB/s both ways so I doubt there is a network bottleneck. I can see how the transcoded folder keeps growing larger and larger while the UI is "down" and the playback is buffering. I tried limiting the threads used for transcoding with no change in behaviour.

It just seems the Jellyfin docker container becomes overwhelmed somehow. If I were to try to stop the container when this is happening it usually takes several minutes.

I'm on 10.8.12, but I've had the same issue with older releases.

In this log I started Movie A and then Movie B. Once the movies froze I stopped playback on movie B. At this point the UI is unresponsive and I had to manually kill ffmpeg (that kept spewing out transcoded files for Movie A and used up around 10-20% of CPU) and then wait 2-3 minutes to get the back the UI responsive again. I'd estimate the UI was unresponsive from around 20:08-20:15 +- a minute or two.

I get the same behaviour even if I don't start playback of Movie B to begin with.
I have around 10GB of available RAM and space to spare on the SSD.

I'll provide the ffmpeg log once I'm back home, but it didn't contain any errors, it just kept spewing out the transcoded files.

OS: OMV6 (Debian) with Docker on 128GB SSD.
CPU: Xeon E3-1265L V2
RAM: 16GB DDR3 ECC

[tmsrxzar]

ffmpeg log could be informative

recommended tests
speed test the transcode target drive https://www.cyberciti.biz/faq/howto-linu...dd-command
check resources usage with iotop during playback attempt https://www.geeksforgeeks.org/iotop-comm...h-examples

if ram is available and cpu usage is low; suspect ssd
move forward from the ffmpeg log and the recommended tests

[TheDreadPirate]

I can't say for certain, but your server might just be overwhelmed. Two transcodes without a GPU on an old CPU with only 4 cores.

Also, what are you playing these videos on that doesn't support H264?

[Henkow]

ffmpeg log could be informative

recommended tests
speed test the transcode target drive https://www.cyberciti.biz/faq/howto-linu...dd-command
check resources usage with iotop during playback attempt https://www.geeksforgeeks.org/iotop-comm...h-examples

if ram is available and cpu usage is low; suspect ssd
move forward from the ffmpeg log and the recommended tests

I also suspected the SSD at first, I did run an extended S.M.A.R.T. test on it and it looked good. I also tried to write and read to it concurrently and achieved speeds in excess of 100MB/s both ways.

Result from the speed test:
> dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.679026 s, 1.6 GB/s
> dd if=/dev/zero of=/tmp/test2.img bs=512 count=1000 oflag=dsync
1000+0 records in
1000+0 records out
512000 bytes (512 kB, 500 KiB) copied, 0.00308955 s, 166 MB/s

Output from iotop: https://ibb.co/TcxVbwf. It took about a minute or so before anything registrered on READ (despite this the playback was fine?). Then it jumped between reading and not reading anything between each iotop refresh. I suppose that makes sense as it receives the files in chunks? The playback seems to consistently stall around 2 minutes in on firefox and 40 seconds in on chrome.

I can't say for certain, but your server might just be overwhelmed.  Two transcodes without a GPU on an old CPU with only 4 cores.

Also, what are you playing these videos on that doesn't support H264?

I should have been more clear regarding the transcoding, only the audio is trancoded (direct streaming). I'm playing the movie back in firefox, I've tried chrome as well but firefox have worked better for me in the past. Around a year ago when I set up Jellyfin I was able to transcode 4 movies (blu-ray remuxes) concurrently without any issues. I tend to use Kodi for playback most of the time. I only noticed this issue now as I gave remote access to a family member and I noticed I couldn't access the Web UI while they were streaming. I was then able to reproduce it locally (I've turned off the reverse proxy for the time being).

I updated the server log as I ran a more controlled test with just a single movie.

[16:26] I start playback
[16:28] I open a new tab, which never load. At this time the movie also freeze. After about 90 seconds later it resumes playback but it then starts to play intermittently. (Edit: it appears the movie will stall regardless if I open a new tab or not.)
[16:32] I exit playback by pressing the back symbol in the Web UI.
[16:34] I manually kill ffmpeg which have now transcoded 37 minutes of the movie.
[16:37] Jellyfin becomes responsive again.

[TheDreadPirate]

Nothing is obviously wrong according to the log. Without seeing more stats, disk IO, overall memory usage, jellyfin/ffmpeg memory usage, its hard to diagnose.

[tmsrxzar]

well it's nothing to do with running out of ram, processor usage or disk failing everything looks normal (good even)

i wonder how much can be diagnosed on the client side (firefox) seems it's either that or a TCP thing

i don't have anything further to suggest on this

[TheDreadPirate]

My only other suggestion is to look through syslog or something for any system related errors.

[Henkow]

My only other suggestion is to look through syslog or something for any system related errors.

well it's nothing to do with running out of ram, processor usage or disk failing everything looks normal (good even)

i wonder how much can be diagnosed on the client side (firefox) seems it's either that or a TCP thing

i don't have anything further to suggest on this

I did try to transcode to ramdisk instead and while I couldn't get quite far enough in the movie where it would usually freeze (before running out of ram), a new tab did load. So there must be something with the access to the SSD. I tried upgrading my SMB share to v3 and connected my PC straight to the same switch as the server, bypassing the router, to see if something would change but got the same behaviour. I have other docker containers that occasionally want to access the SSD (mainly HA and Adguard), but surely that shouldn't be noticeable?
 
As a last resort I enabled throttle transcoding. When I tried this last year it didn't work well for me but now it works great and appears to fix everything. The Web UI stays responsive and I just tested 4 streams concurrently, 3 out of which needed the video transcoded as well. No buffering at all. I'm suprised this work as a lot of transcoding takes place in the beginning regardless if the transcoding is throttled or not. While I would like to get to the bottom of this eventually, I think I'll stick with this for now.

Thanks for all the suggestions, will keep using iotop!

[TheDreadPirate]

I did try to transcode to ramdisk instead and while I couldn't get quite far enough in the movie where it would usually freeze (before running out of ram), a new tab did load. So there must be something with the access to the SSD. I tried upgrading my SMB share to v3 and connected my PC straight to the same switch as the server, bypassing the router, to see if something would change but got the same behaviour. I have other docker containers that occasionally want to access the SSD like HA, but surely that shouldn't be noticeable?

Just to be clear, the SSD is local, right?  The SSD containing your docker directory is NOT an SSD over SMB?

[Henkow]

I did try to transcode to ramdisk instead and while I couldn't get quite far enough in the movie where it would usually freeze (before running out of ram), a new tab did load. So there must be something with the access to the SSD. I tried upgrading my SMB share to v3 and connected my PC straight to the same switch as the server, bypassing the router, to see if something would change but got the same behaviour. I have other docker containers that occasionally want to access the SSD like HA, but surely that shouldn't be noticeable?

Just to be clear, the SSD is local, right?  The SSD containing your docker directory is NOT an SSD over SMB?

Oh, no. it's in the server. The SSD is only accessed by the jellyfin webclient over SMB. Btw, did these messages not indicate any sort of issue? Seemed to happen around the time the video froze.

[16:27:57]  [INF] [58] Emby.Server.Implementations.Session.SessionWebSocketListener: Lost 1 WebSockets.
[16:27:45]  [INF] [82] Emby.Server.Implementations.Session.SessionWebSocketListener: Sending ForceKeepAlive message to 1 inactive WebSockets.

Finally, I looked in the syslog and while everything crawls to a halt, home assistant started spitting out some warning messages so it seems like the SSD may not be able to keep up despite what the tests said.

homeassistant[3892534]: #033[33m2023-11-21 16:30:21.208 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.adguard_home_dns_queries_blocked is taking over 10 seconds#033[0m