• 0 Posts
  • 184 Comments
Joined 3 years ago
cake
Cake day: June 10th, 2023

help-circle


  • Plex server doesn’t need to be “portable”

    Strongly disagree, I’ve switched my media server several times in the past decade for a multitude of reasons, having things in docker has allowed me to do this seamlessly.

    Also you’re ignoring all of the other benefits of running in docker, from isolation to automation.

    and running it in docker definitely doesn’t make it easier.

    Plex is the only self-hosted service that is purposefully trying to block you from being ran in docker. All other things are just much easier to run in docker, that’s part of the appeal, reproducible builds eliminate the “it works on my machine” errors.

    There absolutely are programs that make sense to run in docker, but Plex server isn’t one of them.

    Why do you think it doesn’t make sense? Does Jellyfin make sense to you to run in docker? Why are they different?

    Also, Plex only supports Ubuntu and CentOS, none of which I run on my server, so the only OFFICIAL way to run Plex is Docker.



  • What Plex does is closer to having an embedded tailscale client, you can access Jellyfin remotely with tailscale for free, but OP specifically asked for no VPN.

    That being said, I’m not opposed to Plex charging for that service, even a tailscale like server costs something to maintain. My gripe with Plex is that it purposefully shoots itself in the foot to force you into their paid service, i.e. it actively tries to isolate itself so you can’t access it remotely, which means that it can’t run inside a docker container unless you give it network host access, otherwise it only considers other docker containers locals and doesn’t let you watch your own content from another machine in the same network.





  • Except most people have almost the same structure because of media organizers like radarr/sonarr. At the very least they should hide that behind a setting to not require auth (since the header should be there for most clients) so only people running an old client would be affected. They could also add an extra salt to that hash or something similar.

    I agree, it’s not critical, but it shouldn’t be hand waved either. And like I said, security is relative, I would argue for most people this is fine, but I still think this should be taken more seriously.











  • No, there isn’t a need for a naive controller driver to be part of steam. So much so that in fact it isn’t, the driver on Linux is called hid-steam and it’s open source and was developed with help from Valve, which is why the controller works even outside of Steam.

    What you keep missing is that the default behavior is purposefully that of a mouse+KB because it’s what makes sense. Go ahead and plug the controller on a Linux machine and you will be able to use it as a mouse, click on a game to launch it, then it will become a controller when the game tries to grab it (unfortunately some games try to be smart about this and fail miserably and don’t detect it), but a naive one, similar to the Xbox controller, you’ll miss the back buttons, touchpads and extra sensors because most controllers don’t have them, and without SteamInput to remap those on the fly you’ll be left with whatever the game decides to handle, which is usually just an Xbox controller. That SDL thing you linked gives a way for games to handle those extra inputs, but it’s still relying on the open source driver that’s already there, and it depends on the game to use it.

    You’re not asking for a driver, you have that already, you’re asking for SteamInput to be released separately from Steam, which is a weird ask. SteamInput is a product that Valve develops to bring people to Steam and allows to remap any controller to any input, nothing stops people from making an alternative to it, but expecting Valve to release it separately is weird.