search

ressu / kube-plex

Scalable Plex Media Server on Kubernetes -- dispatch transcode jobs as pods on your cluster!
Apache License 2.0
102 stars 24 forks source link

Error while starting original binary: signal: killed #31

Closed craigcabrey closed 2 years ago

craigcabrey commented 2 years ago

Hi,

Thanks for taking up maintenance of kube-plex. I have the helm chart deployed & it works fine. Protip, to get remote streaming to work via ingress (as opposed to something like a node port), just have to set Settings > Network > Custom server access URLs to the ingress URL. Might be worth adding to the README.

Plex itself works fine, but transcoding is CPU. When I look at the pod logs, I see:

Error while starting original binary: signal: killed

And when I download the log bundle, I see:

Jun 21, 2022 15:43:07.124 [0x7f6f2f024b38] INFO - [KubePlex] Bypassing kube-plex and launching original binary

I'm not sure how to interpret this because transcoding itself still works, just via CPU. It doesn't appear to start up any pods from what I can tell. Additionally, it seems there is no way to expose the /dev/dri devices inside of the original container (for when kube-plex transcoding fails & we fall back to the local pod for transcoding work).

Any pointers on how I can dig into this further? Any logs?

craigcabrey commented 2 years ago

I suppose the bypass is due to https://github.com/ressu/kube-plex/blob/main/cmd/kube-plex/main.go#L145

Am I reading it write that certain formats aren't supported? If so, what would it take to support them (I assume it's all ffmpeg under the hood)?

In either case, when falling back to standard transcoding, it would still be good to expose the hardware acceleration device (/dev/dri) to the plex container. I can investigate doing this and put up a PR for the helm chart if you don't have any objections.

brandon099 commented 2 years ago

@ressu and I looked at some of this a while back when I started work in #5 (I still need to get some time to revisit it to see if it's possible!) Long story short, Plex has assumptions about where to save the temp chunks during transcoding for EAE. The transcoder pods do not have access to those files. Even if they did, via a mount, there is no way to communicate the progress to the original EAE process. They remain local to the original server container, and this part of Plex is closed-source. So the bypass for particular codecs is exclusively related to the elastic transcoding pods.

Hardware transcode works for all formats Plex supports when you disable kubePlex in the chart (that is what the PR I linked above attempts to address for EAE encoded media). This requires you to expose the GPU. I do this on my Intel devices with the Intel GPU Plugin for Kubernetes:

resources:
  requests:
    gpu.intel.com/i915: 1
  limits:
    gpu.intel.com/i915: 1
craigcabrey commented 2 years ago

Thanks. I found the resources key in the helm chart shortly after posting it. Just need to make it more obvious in values.yaml.

So for some codecs, it's expected that we bypass (for example TrueHD), but otherwise everything else should trigger a job to be dispatched?

craigcabrey commented 2 years ago

Just found some media that doesn't bypass, looks like it's working! I think I'm in the same boat as you, most of my media will trigger a bypass. Happy to help out with testing & changes.

Might pull down your branch tonight and build an image.

ressu commented 2 years ago

Sorry for being a bit absent.. I see you might have gotten all answers for your issues. Did we have some open issues left here that I can help with?

craigcabrey commented 2 years ago

Yea, thanks. Just need to work on the EAE stuff!

ressu commented 2 years ago

Are you attempting to add support for EAE? If so, could you create an issue for that? I can try and give you a braindump of what I discovered on my last attempt so you have a headstart on that.

My last attempt was a while back, so things have most likely changed quite a bit, but at least you don't need to do down all the rabbitholes I did :laughing: