Video choppy Jellyfin on Roku TCL TV

[lunarjelly]

I have a TCL Roku TV with the Jellyfin app (version 2.0.5) installed.  The Jellyfin server is version 10.8.13.  Playing a certain movie, the video is choppy (low framerate), audio is fine, there's no buffering.  The movie is 1080p HVEC SDR AAC 5.1.  I have other movies in the same format that play fine (I'm not too knowledgeable about movie formats though).  I can play this movie on a laptop (Browser client), PC (Browser client) and the Roku TV at the same time, and only the Roku is choppy, others play great. 

It doesn't seem to be a server issue.  CPU,Memory,IO wait and network are all barely touched, even transcoding two streams.  I would suspect the two browser sessions would be affected if it were a server or network issue.  All devices are connected to the same WiFi within 10 feet of each other. 

My typical way of fixing this is to just download a different movie, but I'd like to troubleshoot this one and see if I can fix the issue.

The only difference I can find is that the browser clients are transcoding, and the Roku is direct play.  Under Dashboard->Server->Playback->Transcoding, I've set "Encoding preset" to "ultrafast" for one of the browser clients.  

First question:  Does this setting apply only to this client/session, or does that setting apply to every Jellyfin client (or maybe just per user?)?
 
Is there a way to force a particular client to transcode?

Is there a way to get the logs from the Roku client, or are logs only on the server side?

The transcode logs obviously won't help, since the Roku is direct play.  The only logs I see that aren't transcode related are these:

[2024-03-29 14:00:44.060 -04:00] [WRN] Slow HTTP Response from "http://10.1.3.24:8096/Sessions/Playing/Stopped" to "192.168.1.205" in 0:00:01.9641607 with Status Code 204
[2024-03-29 14:01:47.056 -04:00] [WRN] Slow HTTP Response from "http://jellyfin.bit.local:8096/Sessions/Playing/Progress" to "192.168.1.204" in 0:00:01.6129092 with Status Code 204


The Jellyfin server is 10.1.3.24, and the DNS resolves to jellyfin.bit.local, so I'm not sure why one log line resolves the IP and one doesn't.  The Roku client is 192.168.1.204.  Does this mean there are networking issues with the Roku Jellyfin client?  That just takes me back to, how can I force the Jellyfin server to force transcoding on the Roku Jellyfin client?

Update:  I borrowed a Roku Streambar and put it on the same WiFi, and can play the same movie just fine, direct play, so it seems to only be the TCL Roku TV, and only that one movie.

[TheDreadPirate]

For the laptop and PC, they are almost certainly transcoding since just about all browsers can't play HEVC. If this is the case, is your Roku direct playing it? And is your video in a MKV container?

[lunarjelly]

Yes, the container is MKV. Yes, the browsers are transcoding and the Roku client is direct play, which is why I was asking about forcing a client to transcode.

[TheDreadPirate]

Perfect. The problem is most likely with the file itself. There is a command you can run on the server to "repackage" the file without re-encoding. Poorly authored MKVs can cause issues like what you are describing and repackaging the file resolves it.

Code:

/usr/lib/jellyfin-ffmpeg/ffmpeg -fflags genpts -i "/path/to/video.mkv" -map 0:v -map 0:a -map 0:s -map_chapters 0 -c:v copy -c:a copy -c:s copy outputFile.mkv

The paths are assuming your server is on Linux.

[lunarjelly]

That didn't fix it. I really just wanted to find a way to force transcoding on a specific client. I just re-encoded the video with Tdarr and that fixed it.

[TheDreadPirate]

You used the new file it created, correct? Not the original (which was unchanged)?

The only way I know of to force transcoding on a Roku is to set a global bit rate limit in the Roku app that is lower than the native bit rate of the video. Press * > Playback > Bitrate limit.