Jellyfin stuttering over VPN despite fast download speed

[TheDreadPirate]

The MKV files.

[StaticUnit97]

Try just remuxing one of your videos.  To make sure there isn't something wrong with the container.

Code:

ffmpeg -fflags +genpts+igndts -i "/path/to/your/file.mkv" -codec copy -max_muxing_queue_size 2048 -max_interleave_delta 0 -avoid_negative_ts auto newFile.mkv

Update: the remuxed file is having the same stuttering as the original. Fixing bitrate to 20 mbps also works as before. Some of the mkv files we've been playing are from MakeMKV, some not.

Interestingly, tonight he is having to sometimes drop to 15 or 10 mbps to get things to play without stuttering, so there must just be a bottleneck somewhere. I had him play something on his phone over a cell connection to at least rule out his local ISP servers, and things were still stuttering.

I'm able to stream things on my cell connection, so it seems like my server + Jellyfin are working well. At least for something "local". Any other ideas on the Jellyfin side?

And thanks for all your help, it's much appreciated.

[TheDreadPirate]

So the remux was just to verify that the file itself isn't bad. Which doesn't appear to be the case.

I think setting up a Librespeed container (self-hosted speed test) is the next step. To have your friend test a plain http based connection speed test instead of whatever custom protocol Speedtest uses.

I've included an example docker compose from my setup.

https://hub.docker.com/r/linuxserver/librespeed

Code:

librespeed:
    image: lscr.io/linuxserver/librespeed:latest
    container_name: librespeed
    hostname: librespeed
    networks:
      blackmoon:
        ipv4_address: 172.16.100.5
    volumes:
      - /docker/containers/librespeed/config:/config
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
      - PASSWORD=InsertYourPassword
    expose:
      - 80
    restart: unless-stopped

[StaticUnit97]

So the remux was just to verify that the file itself isn't bad.  Which doesn't appear to be the case.

I think setting up a Librespeed container (self-hosted speed test) is the next step.  To have your friend test a plain http based connection speed test instead of whatever custom protocol Speedtest uses.

Almost identical speeds between speedtest and librespeed.

UPDATE: at some point the speed just plummeted down to ~1 mbps on both Librespeed and Speedtest, and he's been unable to access the server from the VPN. It then rose to about 40 mbps, and as of yet he's still unable to access. Not sure what's causing that, but I wonder if that's what has been causing trouble in the past.

[TheDreadPirate]

Sounds like it. So the question is now whether their Internet connection, in general, is flakely? Or is there some issue with the path data takes between the two of you?

[StaticUnit97]

Sounds like it.  So the question is now whether their Internet connection, in general, is flakely?  Or is there some issue with the path data takes between the two of you?

My guess is the latter. He had the same issues when connecting to the server via a cell connection. He just checked and he's able to stream again when fixing the bitrate 20 mbps. Last night he could not connect to the server at all.

Is there really anything you can do if there's an issue with the P2P data transfer. I wonder if another VPN solution like tailscale could help?

[TheDreadPirate]

It wouldn't. Tailscale is wireguard with a few bells and whistles. You'd need to use a VPN client that lets you change where your tunnel exits so that data takes a different path. To clarify, THEY would need to use that type of VPN. Not the server side.

[StaticUnit97]

It wouldn't.  Tailscale is wireguard with a few bells and whistles.  You'd need to use a VPN client that lets you change where your tunnel exits so that data takes a different path.  To clarify, THEY would need to use that type of VPN.  Not the server side.

Hmm, gotcha. I'll have to look into how realistic that is.

Thank you again for all the help, it's definitely made the debugging easier!