docker-plex VS container-images

I've tried with couple of repositories but I'm mainly using this one now: lscr.io/linuxserver/plex I gave up on this sometime ago but would now like to get at least RAM transcode working for Plex. The GPU transcode can wait.

I found this, but don't see anything similar for ghcr.io in the images list in the docker UI.

I'm facing a similar issue. I reported it to the linuxserver team (publisher of that docker image), they think it's a plex issue. https://github.com/linuxserver/docker-plex/issues/357

I've messed with Plex in docker quite a lot though, so if you put your code in GitHub I should be able to point out an option for getting it done. Might not make sense for Plexamp for some reason, I've usually started with this repo https://github.com/linuxserver/docker-plex and forked when I was making my own Plex containers. I was thinking of doing that for Plexamp, but I've not looked at what's needed to map sound devices properly. It has an example of where to run a Plex claim script before starting up Plex to run as a service.

FWIW it's probably not a great idea to use the Plex or Jellyfin (or any really) images from lsio. They do stupid shit like this which is not needed with Kubernetes. You can add a security context with those GIDs as supplemental groups. Also all their containers start as root which is not considered best practice.

These are their historical container versions - https://github.com/linuxserver/docker-plex/releases

The linuxserver plex image can actually check for updates when the container starts. It's a bit of an anti-pattern. Here's the script: https://github.com/linuxserver/docker-plex/blob/master/root/etc/s6-overlay/s6-rc.d/init-plex-update/run

K8s@home https://github.com/k8s-at-home/container-images/tree/main/apps

I think the best way to do this would be to create your base docker image. Then in any app after that you reference your base image and add what is needed for that container. Check out k8s-at-home for an idea here, should get you in a direction you want to go and probably a best practice for docker.

Please check out the k8s at home container images repo. Our containers do not run as root or use s6-overlay. We also tag releases with semver.

I'm a maintainer of k8s-at-home/container-images. While I agree with you I wouldn't want something deployed in my cluster that I cannot audit, you can put together (using github workflows) a very transparent and easy to understand build process for containers. If people are just yeeting things from their desktop to dockerhub and telling other people to use it they are doing it wrong.