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.

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.

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

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.

Helm sucks. You don’t even need it for what you’re trying to do.

Mint is for desktops. Hands down.

Run something paired down for servers. Fedora Server, or plain Debian are fine. CoreOS or Talos if you’re trying out some k8s stuff.

Yes, it’s mostly just package selection, but you don’t need to sift through the cruft and clean up all the desktop shit running you don’t need.

Docs say you can choose what to sync, and disable syncing entirely where you don’t want it: https://docs.nextcloud.com/server/latest/user_manual/en/desktop/usage.html

Pretty sure you should have the ability to choose what to sync, either from the server, or the client. Seems kind of dumb for it to automatically assume you have the space on the client device to sync EVERYTHING.

Wha??? A Microsoft product!!! Nooooo… c’mon

Well, firstly, it’s not what Tailscale is meant for. I’m getting downvoted by the people using the wrong tool for the wrong job.

You don’t install a VPN on all your local machines just to talk to each other. That’s insane. You especially don’t install one that, while misconfigured, is sending all of its traffic OUTSIDE of your local network, then back in. This is what Tailscale on a number of local machines will do by default.

The way Tailscale works is by installing a Wireguard client on a machine. It then checks in with their DERP servers to figure out it’s network situation (behind NAT, peers in the network, routing tables…etc). So when you have more than one client on the Tailscale network, it automagically assumes some things, the first being that these two machines dont have a more direct route to talk to each other.

So then it will attempt to bridge a path between the DERP server each client is checked into, and pass traffic that way. Which means you then have two machines on the same local network sending traffic OUTSIDE of that network, then back in to complete a VPN network.

This is stupid.

You setup multiple different networks and use exit nodes to bridge two networks together with Tailscale. That’s the entire point. This means setting up routes to let the orchestration layer know that a set of certain machines exist in the same network, and shouldn’t use Tailscale to communicate with each other. Then it will only be using routes for REMOTE networks, where other clients exist, to pass traffic over the Tailscale network.

May I ask what you were planning on doing with Tailscale? I can point you in the right direction.

Move your Nginx pets to something else. Pretty simple.

Oops, yup

I don’t think that’s the point of the comment.

Sorry, are you asking about Moonlight specifically? I believe people use Sunshine for AMD acceleration. I wasn’t even generally recommending it for use as a Remote Desktop solution since it’s kind of overkill, just mentioning that some people use whatever tool will get the job done.

If you’re not comfortable using SSH, each Linux DE comes with its own RDP setup, so refer to the docs of whichever you’re running to set that up if you want things to be super simple.

Past that, there’s tons of stuff, but I would generally avoid VNC these days because it’s pretty much a dead protocol that is insecure and inefficient.

Some people prefer to use RDP compatible tools, some people just use Moonlight. You can use whatever is comfortable for you, really. I would avoid all the suggestions that are telling you to install the giant constructs like Mesh Central though. That’s overkill for just two machines here.

I hate having to continuously point this out, but DO NOT DO THIS unless you have a deeper understanding of networking.

“Just installing Tailscale” without proper configuration of the default routes is going to cause all kinds of routing inefficiencies and loopbacks in your internal network that is absolutely unnecessary, especially for what OP asking for.

This is just bad advice.

If you’re solely talking about Caddy using self-signed, just use the caddy directory created for this. Should be simple.

The global /etc/SSL dir is locked down for a reason, and you shouldn’t relax permissions there just so Caddy can get to subdirs.

So then as a next step, I’d set Wireshark up on one of your regularly hosts, set it to filter for DHCP traffic, confirm you’re seeing regularly advertisements first, then reboot the device that’s responsible for DHCP and make sure it resumes sending those advertisements when it comes back.

If it’s the same device handling DNS, make sure it’s also immediately returning responses after the reboot as well with dig or nslookup.

Frigate isn’t a resource hog unless you enable the inference and classification stuff. If you don’t need that, and are only running 2 cameras, it should be fine.

Shinobi is another option without all the advanced junk you may not need though.

Read the first sentence at least, c’mon.