no screensharing seems to work, at least none of those i tested, not even jitsi meet. i get the point of “being maintained”. but but what does it actually do better?

Idle windows is so damn heavy on io :(

Didnt find any /s there. That’s one of the reasons why I dislike docker, it supports not understanding stuff. But then that’s just me, who wants to understand stuff. Enabling less tech savvy ppl is also great I guess.

While certainly not all .ml users love russia, all russia lovers are in .ml.

Oft course thats not entirely true, but there are some weird communities there.

watch out, or you might be kicked off your instance :D

I kind of lost interest when they found out that in a distributed system you can’t delete things

Just stumbled upon this: https://jellyfin.org/docs/general/post-install/networking/

Base URL

Running Jellyfin with a path (e.g. https://example.com/jellyfin) is supported.

caution Base URL is known to break HDHomeRun, the DLNA plugin, Sonarr, Radarr, and MrMC.

so: yes, it works. but most likely: no you don’t want this.

Clearly a problem on the VM. Run

dhclient -v ens18; for i in $(seq 60); do ip a s dev ens18; sleep 1; done

Just to see if its broken immediately or if another process probably fks it up later

Use dhclient -v to See the client side, check logs in the DHCP Server. Sniff maybe.

OnlyOffice recently got famous for not understanding FOSS.

deleted by creator

usually port knocking opens the relevant port to the client IP that is knocking. So it makes a lot of sense to have the knocking done by the requesting client. In many situations knocking from your mobile while behind the same NAT as your jellyfin client will do the trick, but if you have different IPv6 on those devices etc, it won’t.

Also: if you assume your DNS lookups are sniffed - so are your port knocks. If you don’t, spare the extra work. But then, if you like port knocking - keep knocking, nothing wrong about it :D

You telling me jellyfin Clients can’t handle client certs but can port knock?

My proposal is for maxing ux on the client side while being properly hidden.

If jellyfin Clients can do URLs, sure

Just posted on the top level, should have been here:

Random subdomain, wildcard cert

If client certificates and basic auth is not supported by jellyfin:

• reverse proxy
• strong random subdomain
• wildcard certificate
• tls1.3 only
• doh/dot only

1-3 make random scanners unable to find your service, 4&5 even hide it from your ISP. Dot/doh service will still know your subdomain, so be your own dot/doh ! :D

Ports are closed by firewalls, and if you need to port forward on your home router this is a non-issue anyway

meh, how can that be :-( I’m still in the process of setting things up with jellyfin, didnt know…

Just put it behind a proxy and require a user cert? Bit of a burdon on the client side, admittedly

How comes you don’t have a baby? Was it eaten by fascists, maybe?