Geo-distributed Jellyfin
from xana@lemmy.zip to selfhosted@lemmy.world on 05 Feb 04:54
https://lemmy.zip/post/58475354

Hi TCP users,

Currently, I have a homelab server that runs Jellyfin with direct access to local media content and a reverse proxy point to it. While it works well for people in Europe (where the server is), it is quite slow for some of my friends who are living in Asia. I am having some options in mind:

So I would like to ask do you know any things about this and any idea to improve this situation ?

Thank you very much!

Edit: Thanks for all of your response. Based on my experience, I think the slowness is caused by the fact that there are too many hops to jump through before reaching the final client. So I think I will try to do several things:

Edit: Slow here means both slow page loading and slow buffering.

#selfhosted

threaded - newest

TheHolm@aussie.zone on 05 Feb 05:00 next collapse

IMHO Jellyfin is processing everything it sent to clients. So I do not think it possible to put it behind SDN( may be it possible if server side transcoding is off) Please define slow. Slow on what part? It should be like 250ms RRT to your server which is not much for web-based apps.

non_burglar@lemmy.world on 05 Feb 05:20 next collapse

You unfortunately cannot solve this yourself, this is where 800lb gorillas like akamai outclass self-hosted.

Netflix alone has many thousands of isps participating in Open Connect alone, these providing CDN peering points all over the world and making Netflix only a few hops away for more end users.

Brkdncr@lemmy.world on 05 Feb 05:40 next collapse

Even large streaming services drop their servers close to the users to make the experience good. They just do better at scaling.

You could federated authentication so only one ldap service is maintained. You could also sync media from one device to the other so you don’t need to manually update both.

Appoxo@lemmy.dbzer0.com on 05 Feb 19:04 collapse

Isnt that done to reduce the load on a monolithic servers and to also reduce the network transit bill.

just_another_person@lemmy.world on 05 Feb 05:47 next collapse

You’re describing a CDN. You can’t afford it.

I’d look more into boosting whatever your uplink is versus trying to distribute to localized users.

Atherel@lemmy.dbzer0.com on 05 Feb 07:19 collapse

The uplink isn’t the problem as it works for viewers in Europe.

just_another_person@lemmy.world on 05 Feb 08:18 collapse

Uplink is exactly the problem. Not sure why you think otherwise. The internet doesn’t work by multicast.

Atherel@lemmy.dbzer0.com on 05 Feb 10:05 collapse

Maybe we don’t talk about the same. The uplink at OPs router isn’t the problem, there is enough upload speed so that others in Europe can stream. Users in Asia don’t have enough bandwidth, so there’s a bottleneck somewhere in between.

And yes, a VPN could help by routing the traffic through other hops, but chances are that it doesn’t help or even make it worse, but it’s worth trying.

just_another_person@lemmy.world on 05 Feb 11:51 next collapse

Bandwidth does not degrade over distance. That’s not how that works…

Again, I’m confused on what you’re suggesting the actual issue is here.

ExcessShiv@lemmy.dbzer0.com on 05 Feb 12:47 next collapse

If the uplink bandwidth is more than sufficient for users in Europe, and it doesn’t degrade over distance, then why is the same uplink not enough for the exact same thing in Asia?

Onomatopoeia@lemmy.cafe on 05 Feb 14:18 next collapse

Exactly, bandwidth doesn’t degrade over distance, so why would the uplibk bandwidth be the issue for Asia when its fine for Europe.

Stez827@sh.itjust.works on 05 Feb 18:26 collapse

Ok you’re almost there. It is plenty fast for people in Europe but it is slow for those in Asia. So bandwidth is not the issue

just_another_person@lemmy.world on 05 Feb 19:33 collapse

When talking about media streaming, there’s a number of other things that cause problems Bandwidth, meaning the total amount of information you can send overall, is less likely to be a problem versus jitter, packet loss, and latency spikes.

For this purpose, but OP would tune both the server and the clients to cache ahead more, or send in smaller packets, it could possibly be a good workaround.

Spending an insane amount of money putting what I’m guessing is illegally obtained content on a CDN distribution is crazypants.

frongt@lemmy.zip on 05 Feb 14:06 collapse

It’s probably not bandwidth but latency and packet loss that’s the problem.

Atherel@lemmy.dbzer0.com on 05 Feb 15:29 collapse

Latency shouldn’t be a big problem if it doesn’t have massive spikes. Packet loss could be a problem, seems like Jellyfin doesn’t have an option zu increase the buffer size which may help. Or the problem is in combination with transcoding.

performation@feddit.org on 05 Feb 06:08 next collapse

This may be completely untrue but maybe the remote users could get a vpn with a server near yours? Without having the slightest idea that it does I could imagine it could help.

Ptsf@lemmy.world on 05 Feb 07:37 next collapse

Tailscale, headscale, or something along those lines may help optimize the route but as others have said to resolve this is an actual fashion you’d need a cdn which requires significant geo-redundant hardware which comes at a pretty significant cost. That being said I think your friend has a good shot if you implement the former.

johnnixon@lemmy.world on 05 Feb 12:52 collapse

I was trying to stream my Jellyfin server on vacation…Over Tailnet I couldn’t reliably stream anything. Over VPN it was as good as local. I can’t believe it’s just a routing issue but I wasn’t proxied so it should have been the same. So a VPN for one user might fix the issue. The headaches of segmenting the network on that VPN are another problem even if the hardware/router is capable but doable.

ohshit604@sh.itjust.works on 05 Feb 07:44 next collapse

You don’t necessarily have to host another Jellyfin instance, I would find a server somewhere in-between the middle of your current Europe server and your Asian homies and setup a reverse proxy there and point it to your current Jellyfin instance.

The only hassle with this is you’re going to need a way to expose your Eu Jellyfin to the new server, a VPN would prevent port forwarding 443, perhaps split tunneling?

Not the most elegant solution but at least this way you can make an attempt at optimizing the connection.

Edit - (if you wanted to go the second Jellyfin instance route): Could also copy your current database to the second server, host a second Jellyfin instance and have something like sshfs or sftp sharing the directory to your media library, reverse proxy it as something like asia-jellyfin.your.domain and keep it separated from your Eu server.

Flax_vert@feddit.uk on 05 Feb 09:47 next collapse

I am in basically the same situation as you and my single asian user has no issue with it

glitching@lemmy.ml on 05 Feb 10:19 next collapse

don’t know what “slow” means in your case, but jellyfin clients have a buffer setting and increasing it should improve things for them.

frongt@lemmy.zip on 05 Feb 14:07 next collapse

Define “slow”. Pages hang before loading? Or it often stops to buffer a stream?

deafboy@lemmy.world on 05 Feb 15:03 collapse

So it’s not just me. The peering between europe and asia IS crap!

I’ve been to thailand in november and the connections to europe were hit or miss the whole time. The latency was poor and the reliability varied day by day.

The only thing that made any difference was switching providers on the EU side. It seems that some ISPs have better peering than others.

Also lowering the MTU for the vpn tunnel seemd to help a lot, but that might’ve been a placebo.