I’ll bet your boot process is a lot shorter too.

The reasonable way to approach this problem would have been to ask a follow up question, rather than bitching at someone for not answer in the exact format you required. You’re the beggar here, you get zero fucking say in how much or how little people choose to help you.

There’s no backend server to do the transcoding in this case. Kodi can access raw NFS/SMB file shares the same as accessing local storage, so it’s just reading the file over the network, the same as if you were playing it in VLC on your PC.

Certain domain names are locally routed only. So if you use internal or local as a tld, you can just assign whatever names you want and your computer won’t go looking out on the internet for them. This means you and I can both have fileserver.local as an address on our respective network without conflicting. It’s the URI equivalent of 192.168.0.0/16.

I’ll see about digging up recommendations if I can, but I’m on my phone right now.

My biggest single piece of advice would be this: Understand that your reader does not share your context.

What this means is that you have to question your assumptions. Ask yourself, is this something everyone knows, or something only I know? Is this something that’s an accepted standard, or is it simply my personal default? If it is an accepted standard, how widely can I assume that accepted standard is known?

A really common example of this in self-hosting is poorly documented Docker instructions. A lot of projects suffer from either a lack of instructions for Docker deployment, because they assume that anyone deploying the project has spent 200 hours learning the specifics of chroot and namespaces and can build their own OCI runtime from scratch, or needlessly precise Docker instructions built around one hyper-specific deployment method that completely break when you try to use them in a slightly different context.

A particularly important element of this is explaining the choices you’re making as you make them. For example a lot of self-hosted projects will include a compose file, but will refuse to in any way discuss what elements are required, and what elements are customisable. Someone who knows enough about Docker, and has lots of other detailed knowledge about the Linux file system, networking, etc, can generally puzzle it out for themselves, but most people aren’t going to be coming in with that kind of knowledge. The problem is that programmers do have that knowledge, and as the Xkcd comic says, even when they try to compensate for it they still vastly overestimate how much everyone else knows.

OK, I said I’d try for examples later, but while writing this one did come to mind. Haugene’s transmission-openvpn container implementation has absolutely incredible documentation. Like, this is top tier, absolutely how to do it; https://haugene.github.io/docker-transmission-openvpn/

Starts off with a section that every doc should include; what this does and how it does it. Then goes into specific steps, with, wonder of wonders, notes on what assumptions they’ve made and what things you might want to change. And then, most importantly, detailed instructions on every single configuration option, what it does, and how to set it correctly, including a written example for every single option. Absolutely beautiful. Making docs like this is more work, for sure, but it makes your project - even something like this that’s just implementing other people’s apps in a container - a thousand times more usable.

(I’ve focused on docker in all my examples here, but all of this applies to non-containerized apps too)

I write technical documentation and training materials as part of my job, and the state of most open source documentation makes me want to stab people with an ice pick.

Xpipe has rapidly become an essential part of my day to day workflow. I wish I could get it to play nice with MobaXTerm as I prefer that to any of the supported terminals, but that’s really my only gripe. In every other regard it’s just an excellent toolkit for managing remote devices.

It’s not so much that Dockge shows more, and more that it does more. Log viewing in Dockge is actually pretty bad; it’s honestly the one thing that really needs more work. But Dockge is a full management plane; it allows you to deploy, modify, bring up and bring down entire compose stacks. Dozzle is only a log viewer, nothing else. Given that log viewing is the one thing Dockge does badly, they’re actually a perfect complement to each other, and I’d strongly recommend running both.

This is dumb. Just buy 100 million worth of gold. Then even if you lose the bet on a technicality, you still have 100 million in gold.

Yes, I know I’m overthinking this joke about Amazon’s ridiculous pricing.

OK, so right now you’re mounting the remote shares as user moose, but then you tried to chown those folders to user $USER. In case you don’t know this, the $ sign indicates a variable; the command is actually subbing in the name of the user who ran the command.

Now the question here is, what user is radarr / sonarr running under? If you’re running them directly on your machine without docker, that’s probably being set by a systemd task that runs the programs in startup.

You need to make sure that that user has the ability to write to those media folders. The simplest way to do this would probably be to edit the systemd units to run the arr programs as moose, since that’s apparently an unprivileged user you created just for mounting the shares.

Yes, you will need a tuner card or USB tuner. The go to apps are mythtv and Kodi. I’d start with Kodi and see if that does the job for you. If you check the Kodi wiki you’ll find resources on what specific tuner cards work best.

Self hosted DVRs are definitely a dying breed, but there’s stuff out there if you’re willing to dig.

For Jellyfin integration, once you have the files you should be able to dump them out to a folder where Jellyfin can scan them.

I bought a “lifetime premium” for something like $30 USD I think

Same

But use Airsonic instead, it’s a fork that’s free in both the beer and speech sense.

There’s also Navidrome, which is a unique backend, but works with existing Subsonic clients. Check out both, see which one you like better.

If someone has the resources to simulate a universe, they probably have the resources to stimulate an arbitrarily large number of universes. This also assumes that any civilisation within the stimulated universe reaches the level of technological advancement required to make a universe level simulation. We’re talking, probably, whole networks of Matrioska Brains, that sort of thing.

Being a terminal purist is wonderful for those of us who live our lives deep in the caverns of Linux, but in actual production use you very often find situations where less technical users have to interact with the systems that we build.

For my work, I need a way for low level tech support and technicians to go in and restart a container from time to time, and these people curl up in a ball and scream if you show them a command prompt. Having a UI removes a lot of friction.

To be fair, Dockge is very, very new. I imagine features like that will turn up soon enough.

Technically true, but if you actually try to interact with those compose files directly then shit gets really fucky.

We can’t get Congress to agree to anything right now, the ruling elite and external hostile governments have crippled them.

For the record, the house is currently controlled by the Republicans. Saying “gridlock in Congress” when its run by the party that most benefits from being obstructionist seems a bit disengenuous. It’s not “gridlock”, it’s Republicans doing what they went there to do.

Absolutely. A lot of the time the biggest difficulty with researching something is not even knowing the right terms to search for. Asking a few questions can give you a starting point to know where and how to look.

And the thing is, I personally hate asking questions on forums and the like. I can probably count on one hand the number of times I’ve done it. I’m very good at digging up answers by myself, and I generally do work better with essays than I do with conversations. But my experience should not be seen as the default, and people shouldn’t be shit on for trying to learn through community rather than through textbooks.

So, when you create a virtual machine in KVM, you have the ability to attach a Spice or VNC display to the VM.

Unlike running VNC inside the virtual machine, what this does it is runs VNC on the host, at a port that you designate (or a randomly assigned port if you don’t designate) and then you can view that by connecting to the host through VNC. For Spice its exactly the same, except you use something like the Remote Viewer application to connect to it.

As others have mentioned, the easiest way of handling all of this is with Virtual Machine Manager, which integrates its own Spice console and makes everything happen automagically. You can also install Cockpit with the Cockpit-Machines plugin on the host, which gives you a web interface for controlling virtual machines, just like vmware esxi. The display manager on cockpit is pretty rough at the moment though.

KVM is a very “build it yourself” virtualization solution. I use it extensively, and I love it, but you’ll need to be prepared for a lot of “Oh, KVM doesn’t do that, that’s handled by this program/library/whatever”. It’s definitely not a user friendly toolkit. If you’re looking for a Workstation Player alternative, you may be better off with something like Virtbox (although do try out Virtual Machine Manager first, it’s really slick and for your use case probably solves all the problems I’ve mentioned). If you’re looking for an esxi alternative, maybe look into Proxmox.