Finished rffmpeg 32852 with return code 127 #10
Comments
|
It should work fine with Emby. I don't think the problem is the parentheses; they are escaped in the real call via the double-quotes, and I have those too without issues. I suspect the BASH error is a red herring. Exit code 127 is actually a file not found, and I suspect the issue there is the |
|
Again, many thanks for this script and the time you spent answering me. If you need any help with anything to debug the problem, don't hesitate to ask me. For information the script works well by calling the local ffmpeg of the machine: |
|
Interesting, OK - the BASH syntax error is definitely a red herring - it seems the Python |
|
Indeed it works when I run the command manually with the But when I launch via rffmpeg I get the same error: |
joshuaboniface
added a commit
that referenced
this issue
Apr 27, 2021
1. Split the command string into an "rffmpeg_ssh_command" and "rffmpeg_ffmpeg_command". The first contains the SSH arguments, the second contains anything run on the remote system. For consistency, also rename the local command string to "rffmpeg_ffmpeg_command". Join these commands commands together as rffmpeg_command before executing on the remote host. 2. The split is done so that the output log can properly quote the SSH remote portion with single-quotes, thus avoiding BASH syntax errors on parenthesis characters which do not seem to cause a problem for subprocess itself, when manually running the printed command. Helps address confusion in #10. 3. Reorganize the functions to better reflect their order. 4. Improve logging by removing some superfluous messages and making others clearer.
|
Just one thought: are you running rffmpeg with the same user as would run the process within Emby? I assume so but want to be sure. Same thing with the manual run of the SSH command? |
|
Concerning rffmpeg it is launched via Emby automatically, therefore with the user "emby". I had forgotten to launch manually the command with the user "emby", but I just did it and I had no problem. I can see the transcoding being done. For your information, I made a change in the code to test the addition of I saw that you updated the script, do you want me, to test it ? |
|
I just updated the script and let Emby run it, unfortunately it didn't work: |
|
OK yea none of the changes I've made should have affected this. I did add those quotes to the output print, but this does not affect the actual command that gets passed to That 127 exit code must be coming from something wrong with What is the output of the manual |
|
For comparison, here's one of my runs (manual via CLI) of a media item with the parenthesis, so it can't be that: |
|
Here is an example of launching via CLI with the complete command: |
|
It is indeed very strange that when I launch manually via CLI I have no problem, then when I pass via rffmpeg it returns an error code... I continue to search at the same time but I don't really see what's going on. We agree that the subprocess is also used locally to execute the command. The only difference with the remote command is that it doesn't go through SSH? |
|
That's correct, the Do the Emby logs indicate the exact parameters that and I believe Emby had something similar. I'm wondering if it fails if you run that iteration of the command. It might shed more light on the issue, perhaps some Python traceback or something. |
|
Ok I just found the log and I also see an error after: It seems that there is an access problem on the file I also noticed that when testing another media, it launched well. However I have the impression that it is launched locally and not on my remote node. I say this because I don't see any CPU usage but how can I check be sure? I show you the different logs: |
|
I don't know why but after several tests it doesn't work anymore on the media that were working. I tried to disable some options such as hardware transcoding and on-the-fly subtitle extraction. Here is also an example of a transcoding log: |
|
OK it definitely looks like this is the underlying error: So the SSH command itself is what is not working.
https://github.com/joshuaboniface/rffmpeg/blob/master/rffmpeg.py#L211 So this indicates to me that, somehow, you both (a) have another SSH on the Try this, both as your user (where the direct I fully expect (1) is the issue, there's some random stray, incompatible, |
joshuaboniface
pushed a commit
that referenced
this issue
Apr 29, 2021
For cases where the SSH command on the $PATH might not be ideal, allow the user to override this with a full path in the config. Addresses #10
joshuaboniface
pushed a commit
that referenced
this issue
Apr 29, 2021
Avoids erroring out with existing configs. Addresses #10
|
Indeed this error seems to come from an ssh problem. I didn't understand which user you were talking about first, because all my ssh tests were done with the Emby user (except at the beginning when I forgot): I added the 2 executions in doubt, one with the root user, and the second with the emby user: I took the liberty to modify your code because the |
|
I just tested your latest changes by modifying the configuration of: by This does not change anything I still have the same error. |
|
OK that's not what I was hoping to see, so I'm honestly not sure - I've never seen this sort of error. I'm also running that exact version of SSH, so something doesn't add up. I was able to find openssl/openssl#11227 which seems to point towards this being caused by having a custom OpenSSL implementation, but we're getting far beyond |
|
Sorry for the long response time, but to answer you I did not make any changes to OpenSSL, it was installed via packages. I will look and test the solutions described in the issue you gave me. Another user has the same problem under Emby: |
|
Chiming in here now 😃 I had the same issue as Floflobel. I was able to get around the Here's the setup: First, download or check this repository out onto your emby server: https://github.com/openssh/openssh-portable If you're on ubuntu, you may need to also run: (that can be run in your normal bash env, doesn't need to be in the emby env) Now, create a file called So for example your script could look like: Then just run it like Ok now if all goes well, you can run Modify the Now you should be able to at least run Sorry if this seems ramble-y, I just wanted to dump all this info before starting my day job lol. |
|
Success! I've gotten this working, and can transcode remotely. You'll almost certainly need to install a portable What was stopping me before was permissions errors. I had to: Then: Watching the logs, it probes the remote transcoder just fine. Now I do think I will need to alter the I'll have to continue monitoring performance and actually attempt to watch a movie on this setup, but so far things look good. |
|
Fantastic! I will try as soon as I have some time to set up OpenSSH portable. Are you using the official version of ffmpeg? Install via repo? |
Yep, on the remote transcode server I am using the official ffmpeg version. So far it doesn't appear to cause any issues. I also copied the original Otherwise I was ending up in an infinite loop if rffmpeg chose the local transcoder. My file setup is still a bit confusing lol. I'll try to illustrate it. Everything is in Basically, emby needs to run the "original" ffmpeg binaries when transcoding locally. It needs to run rffmpeg as the initial entrypoint though. And emby doesn't always use So, when emby begins transcoding, it hits |
|
@nwilging Thank you very much for all the details you have provided. My rffmpeg server is finally operational. Thanks a lot to @joshuaboniface for his help and the changes made on this script. |
|
Thanks everyone for this, hopefully all is well. I'll close this issue out now but if anything else comes up I'm happy to reopen it! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I am trying to get your script to work on Emby. I know well that it is not suitable for Emby but for Jellyfin but I am waiting for a long time for the mobile application to support chromecast. Unfortunately this is what is blocking me from making the switch.
I read and reread the script and I think I found the problem. It seems to be a character escape problem in my media path.
Here is a history of my logs when I run ffmpeg remotely:
In this example you can see the error on the "(" character. Here is an example when I run the command manually:
To get around the problem manually I escaped completely the path of my media (space, parenthesis, ect...):
So I edited this path:
To:
I tried to edit the python script but I'm not an expert in this. I think the problem is the same under Jellyfin if I understood everything correctly.
If you have an idea to unblock me, it would be really cool.
The text was updated successfully, but these errors were encountered: