Jellyfin plugin extremely slow to start playback

[billkenney]

I’m trying to get the Kodi Jellyfin plugin to work through my domain on Fire TV Cube (because the Jellyfin hasn’t worked since 0.11.5), but it’s extremely slow. It takes at least a minute to start playing any video file (the last two files took 1:33 to start). It’s also extremely slow listing the contents of a synced folder. I’d be happy if the Jellyfin app still connected to my domain, but that stopped working years ago.

To Reproduce play any video file or navigate to any folder.

Expected behavior start playback or show folder contents in a few seconds (or at least less than a minute). The Jellyfin app (on the Fire TV Cube) does this almost instantly when connecting over the lan, and the iOS app and the web app also work almost instantly over my domain.

Logs I’m not aware of any relevant logs. The server seems to think everything is functioning normally. I did take some adb logs connecting to my domain with version 0.11.5 of the Jellyfin app, and failing to connect with versions 0.12 beta 1 debug and 0.16.7 debug, but I don’t know that those are relevant.

System (please complete the following information):

• OS: Ubuntu 22.04
• Jellyfin Server Version: 10.8.13
• Kodi Version: 22.05
• Addon Version: 0.7.12
• Playback Mode: Add-on

Additional context I’ve tried multiple caddy configurations (below). I’ve also tried turning https on and pointing it to a p12 certificate, changing the published uri to my servers lan address, etc., but nothing has worked.

1st config jelly.domain.com { tls /etc/caddy/certs/.domain.com/fullchain.cer /etc/caddy/certs/.domain.com/*.domain.com.key reverse_proxy http://127.0.0.1:8096 }

2nd config (jellyheaders) { header_up X-Forwarded-Ssl on header_up Host {host} header_up X-Real-IP {remote} header_up X-Forwarded-Port {server_port} header_up X-Url-Scheme {scheme} } jelly.domain.com { tls /etc/caddy/certs/.domain.com/fullchain.cer /etc/caddy/certs/.domain.com/*.domain.com.key reverse_proxy http://127.0.0.1:8096 { import jellyheaders } }

3rd config jelly.domain.com { tls /etc/caddy/certs/.domain.com/fullchain.cer /etc/caddy/certs/.domain.com/*.domain.com.key php_fastcgi unix///run/php/php8.1-fpm.sock reverse_proxy :8096 }

4th config (jellyheaders) { header_up X-Forwarded-Ssl on header_up Host {host} header_up X-Real-IP {remote} header_up X-Forwarded-Port {server_port} header_up X-Url-Scheme {scheme} } jelly.domain.com { tls /etc/caddy/certs/.domain.com/fullchain.cer /etc/caddy/certs/.domain.com/*.domain.com.key php_fastcgi unix///run/php/php8.1-fpm.sock reverse_proxy :8096 { import jellyheaders } }

[mcarlton00]

There's likely no bug here. It sounds like at least one device on your network is just a potato and can't handle the amount of data flowing through it. Do other clients/other devices work properly?

My first step would be to take caddy out of the equation completely. Just connect directly to ip:port and verify if things work correctly that way. Sometimes introducing SSL can be a significant performance hit if it's already low power enough.

It’s also extremely slow listing the contents of a synced folder

This indicates it's almost surely out of our control. iirc once a library has been synced to Kodi's database, we're no longer involved with displaying contents. That falls back to Kodi's standard library displaying menus which we have no influence over.

[billkenney]

It sounds like at least one device on your network is just a potato and can't handle the amount of data flowing through it. Do other clients/other devices work properly?

I reset Kodi and configured it to use the local IP, and videos start playing in a few seconds now. It also took only 4 minutes to sync 951 movies and 1171 tv show episodes.

My server is an Intel nuc 2.6 GHz quad core i7 running on an m2 ssd, and I have a 1GB fiber connection, so I don’t think my equipment is the problem. Every other device I have uses the Jellyfin app and it works flawlessly—even over cell service. The web app also works flawlessly. I’m sure it’s some sort of network issue, I guess I can try nginx and see if that works any better.

[oddstr13]

I'm seeing the same on my laptop when I'm remote, haven't investigated why, as I have to buffer extensively anyways due to my slow connection. It feels like it is doing multiple roundtrips / connection attempts.

Works fine on LAN, but sometimes still as slow as ~10s.

I think this has been brought up before, but I don't remember in which context.

Listing of synced content, however, is near instant.

[mcarlton00]

If this was a Pi, I would suspect a dying SD card.

In ye olden days, I had an issue where trying to direct play a file stored on a NFS share would have exactly a 12 second delay. The cause was due to some weirdness between .NET and file locking on nfs shares and had a 12 second timeout. But that's not what it sounds like is happening here.

There's also been no end of super random issues stemming from having http2 enabled, but this isn't one of those I've encountered before. But going over ip:port instead of https through caddy seems to indicate this could be another in a long line of wtf-ery involving http2. In another issue from several years ago there's also talk about having gzip enabled in the reverse proxy causes performance issues, so that could be another thing to check.

[billkenney]

I appreciate the suggestions, I will definitely test these out. I magically got the Jellyfin app to connect to my domain @ port 443 yesterday (created a p12 cert/key, opening 8096/8920, changing the serverurl, etc), so it’s not an issue for me right now, but I would like to share with my family. The Jellyfin app is just as fast on my domain as it is over the local ip, which makes me think the issue is with the Kodi plugin. I’ll try Jellycon and see if I notice any difference.

[billkenney]

What do you know. I disabled http2 (you have to do it globally on caddy) and gzip, and video files start playing in a few seconds. I re-enabled gzip and restarted the app and it still works. I also re-enabled http2 and it still works, but it does seem likely that one of those was causing the delay.