Traffic for a local Jellyfin server should definitely not be going over the internet. Also any reasonably modern client should be able to direct play most media without transcoding.
As for my own Jellyfin setup, one TV has an Nvidia shield plugged in and is using the standard Android TV client. The other is a Samsung smart TV onto which I have side-loaded the Jellyfin Tizen app.
Speedtest.net, Steam, well populated torrents, and the Star Citizen patcher are the only things I've experienced my full downstream of 1.5Gbps with.
In the moment at the table, arguably RoC, but that's still not necessarily going to convey well to anyone who wasn't there.
Also, assuming OP's previous submission is the "player shenanigans" which prompted this then it's my opinion that it wasn't cool at the table, either.
A pretty large proportion of "player shenanigans" stories amount to "we ignored the rules and allowed something ridiculous to happen". This is fine if that's what your group wants to do, but can't really be expected to be relatable to the community at large.
It's similar to the stories about level 5 groups who miraculously defeat an ancient red dragon or whatever. It invariably only happens because of some utterly absurd homebrew/ruling, or the GM just played the dragon as an idiot.
Detective Troi and The Haunting of The Port Nacelle
Might be able to cushion it with some automotive exterior foam tape. Definitely an inexpensive solution.
You have it backwards. Gold is extremely malleable and you can easily leave marks in pure gold by biting it.
The dealership frame ended up causing an annoying rattle on mine whenever the car hit a bump. Having it on there meant the license plate was less secure and it would shake in response to the slightest disturbance. Even closing a door would cause an audible rattle from the rear.
Needless to say I've also removed the frame from mine.
Season 7 TNG really is incredible in many ways.
There is analogous functionality for most of it, though it's generally not quite as good across the board.
FSR is AMD's answer to DLSS, but the quality isn't quite as good. However the implementation is hardware agnostic so everyone can use it, which is pretty nice. Even Nvidia's users with older GPUs like a 1080 who are locked out of using DLSS can still use FSR in supported games. If you have an AMD card then you also get the option in the driver settings of enabling it globally for every game, whether it has support built in or not.
Ray tracing is present and works just fine, though their performance is about a generation behind. It's perfectly usable if you keep your expectations in line with that though. Especially in well optimized games like DOOM Eternal or light ray tracing like in Guardians of the Galaxy. Fully path traced lighting like in Cyberpunk 2077 is completely off the table though.
Obviously AMD has hardware video encoders. People like to point out that the visual quality of then is lower than Nvidia's but I always found them perfectly serviceable. AMD's background recording stuff is also built directly into their driver suite, no need to install anything extra.
While they do have their own GPU-powered microphone noise removal, a la RTX Voice, AMD does lack the full set of tools found in Nvidia Broadcast, e.g. video background removal and whatnot. There is also no equivalent to RTX HDR.
Finally, if you've an interest in locally running any LLM or diffusion models they're more of a pain to get working well on AMD as the majority of implementations are CUDA based.
Would it? What does "stationary" mean when discussing relative velocities? The mirror being stationary and the person firing the photon moving at a constant velocity is literally an indistinguishable scenario from a stationary person firing the photon at a moving mirror.
If I am moving relative to a mirror when I fire the photon, then the mirror is moving relative to me, and will be in a different relative position by the time the "event" of my firing that photon reaches it.
Also, the photon isn't moving infinitely fast in my (the firer's) reference frame. It's moving infinitely fast in it's own reference frame.
There are a few options there.
As someone else mentioned if you're using IPv6 then it doesn't matter, you're already routing internally even if you're using the public DNS name, no extra work required.
All the rest are for IPv4.
If you're not behind CGNAT some routers/gateways are also smart enough with their routing to recognise when they need to route back to their own external IP and will loop back locally instead of making any hops out to the internet. Again, if this is the case for you then no additional work is required other than perhaps running a traceroute to confirm.
Another option is to add a local DNS entry for the name you're using to resolve to a local IP address instead of your public address. The complexity (or even possibility) of this is going to vary considerably with your setup. If you're running your own local DNS e.g. pihole or similar then it's trivial. This is how mine is set up.
If all your clients are going to be on PCs (or devices you have more than the typical manufacturer allowed modicum of control over) then you can do something kind of like the previous, just with all your local
hostsfiles.If none of the above are options, then you'll unfortunately have to fall back on using a local name/address, which means a slightly different client setup for devices you use exclusively in your home versus ones you might use elsewhere.