SOLVED: Server becomes unresponsive when transcoding for my phone

[magguzu]

Yes,and I also tried with the English (also AAC) track without subtitles.

I've been testing a bunch of different combinations of media today actually. Other videos in HEVC but not AAC, h264 but AAC, with and without SSA subtitles, etc. Mysteriously, it's only One Piece with the issue. I've tried other media that's as close as I can find.

I even tried another One Piece episode, sourced elsewhere from the one in the issue, that's in h264. It gave the same problem. Over 5-10 min of playing, the server gets slower and slower until it's unusable.

I'm not even sure it's hardware anymore, as the other services on my server actually continue working fine, and even though the CPU does spike somewhat, it's still just 60%ish.

But at the same time, another show that's also MKV, in HEVC, has SSA subs, and AAC audio, plays normally (transcoding just for the container, like One Piece). Those codecs and containers all match the One Piece episode my logs above have been from.

Worth noting I originally said this happened on my phone, but it seems to be anywhere where One Piece needs to transcode. It's just normally direct playing or remuxing on my other devices so, not a problem.

The only thing I can think of that makes One Piece unique (and I'm REALLY reaching here) is that I have its metadata set to absolute, and with four digit episode numbers (e.g. S17E0629) because JF wasn't getting metadata correctly the default way.

[magguzu]

Strange, to prevent my Jellyfin being down much longer for my family, I copied my whole directory to make a "dev" instance and now I can't reproduce the issue in my dev instance.

I'll keep trying to narrow this further.

[TheDreadPirate]

Maybe your database is borked. Did the disk with the database fill up at any point recently?

[magguzu]

Not recently, but this deployment is migrated from an old machine that regularly ran out of space. If it means anything, I had One Piece in the library back when JF was on that machine.

I'm not against a rebuild at this point, if that's a potential culprit? I have had other strange database behavior in the past.

[TheDreadPirate]

Since the clean install worked as expected, I'm thinking something just isn't right with your existing database(s).

Might be time to start clean.

[magguzu]

Oh sorry, it wasn't a clean install, it was a complete copy of the existing directory, including the database.

I have a few things I'm going to try to test later today, namely shutting off everything that might connect to Jellyfin (jellyplex, jellystat, etc), and setting all DNS to default rather than my Pihole.

In the meantime, I just recreated the issue again, and this time I'm seeing a lot of MediaBrowser.MediaEncoding.Attachments.AttachmentExtractor activity at the end. What's being extracted here? It's the episode I was watching:
https://pastebin.com/wGqSXaZv

Also a bunch of:

[matroska,webm @ 0x5595901a3f00] Could not find codec parameters for stream 41 (Attachment: none): unknown codec
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options


and one instance of

System.ObjectDisposedException: The CancellationTokenSource has been disposed.
at System.Threading.CancellationTokenSource.Cancel()
at MediaBrowser.Controller.Net.BasePeriodicWebSocketListener2.DisposeConnection(ValueTuple3 connection)
[14:10:25] [INF] [50] Emby.Server.Implementations.HttpServer.WebSocketManager: WS 192.168.1.230 closed
close
close


[TheDreadPirate]

You can try recreating the current container. Assuming that something within the temporary portion of Jellyfin is borked for some reason.

docker compose down jellyfin
docker system prune -a
docker compose up -d jellyfin

[magguzu]

I did the above (though this has occurred since before upgrading from another container too), I also turned off Jellyplex and Jellystat, and reinstalled Jellyfin for Android (been using the F-Droid version, FWIW).

I also removed the query limit on my Pi-Hole, and removed the YouTube mount that I wasn't using anymore.

It's only been a couple days and I haven't done heavy testing like before, but I haven't seen the issue return yet.

Other things I want to try if I see the issue return:

* Transcode to RAM (minimize writes while DB is being written to? I'm trying anything at this point)
* Disable webhook plugin

[TheDreadPirate]

Transcoding to RAM requires a pretty intimate understanding of how transcoding works in jellyfin, how big your original source videos are, etc. Not recommended for the faint of heart.

[magguzu]

This issue seems to not be returning anymore.

I can't say for absolute certain, but I think disabling the font mapping might have been the fix. I hugely appreciate the help!