Generally speaking, ~19Mbit/s should be enough for a FLAC stream. But as the mathematicians like to joke “assuming, chickens are spherical and live in a vacuum” 😅😂 as others mentioned, there’s likely much more going on than only this upload so the upload / download rates might be an issue.

I would try to eliminate possible issues by isolating them as good as possible and then verifying if they are actually a problem or not.

That could mean:

• try to verify the speed between some outside device and your Netbird instance without any music streaming, buffering, … involved. For instance download the same FLAC file 10 times to your outside device, measure the rates and do this at a time where as few as possible devices / other people are active, if possible, store FLAC file somewhere on the Netbird server, to really be sure it’s not something else
• try to measure the speed between your Netbird and your Jellyfin instance as good as possible, again, ideally without any streaming involved but any kind of simple download would be best and again, best at a time with low traffic
• then possibly measure speeds between external device and Jellyfin with some downloads

If the speeds look alright you’d have to check for protocol issues, STUN problems, Wireguard issues, port forwarding limitations (?) we’d need some more details for better advice here.

And yes, I meant trying the official Netbird servers instead your local one. Same idea, basically, if everything works fine with their server, it might be some weird problem between your external device and your Netbird server for instance 🤷‍♂️

Let us know how it goes and have fun 😁

Maybe a really stupid question these days but…what upload speed do you have? Depending on the encoding of the music (e.g. FLAC) it might just be too much for your internet connection 😅

It would help to know how you setup the Netbird ports to be available on the internet too.

You could - for debugging - use the Netbird SaaS server (I believe there’s a free tier and Netbird being a German startup, I would at least assume, data privacy for the debugging shouldn’t be a big concern 😅 Germans don’t tell their granny their own name if they’re not legally allowed to 😂).

Not crazy at all, actually, I can relate to some extent 😂 although, I am super happy with Talos on my nodes 😇 I feel like I am…staying familiar - love the optimism! - by building container images based on different distros simply because, depending on what you want to package, you’re…encouraged by the individual devs to use this or that package manager anyway 😂 but sounds like you do enjoy pain, so go for it 😂

Regarding different distros: yes, absolutely possible! Considering that swarm development is basically stopped the risk of inconsistencies is lower than back in the days but I’d pin the engine version on all nodes and only explicitly upgrade all at the same time to a newer version.

Regarding swarm itself, even though I understand your desire, I’d recommend to have a look at something else. Have you had a look at Nomad for instance? It’s not compose compatible but I guess these days it’s a simple prompt to convert the compose files, it’s supposed to be simpler than K8s and still offers many perks (like the failover you are looking for).

Also, from what I just read, Proxmox is working on improving the container support to allow “native” containers (inside VMs similar to Kata containers). They’re not there yet but I am wondering if it’s worth the effort from your side right now 😅

Either way, have fun! A fellow homelab buddy 😄