Problems nohup'ing transcode-video

[chrisridd]

If I background and nohup transcode-video, it runs for a few seconds and then stops:

$ nohup transcode-video --mp4 --output TLJ.mp4 --crop 138:138:0:0 The_Last_Jedi_t00.mkv &
[1] 84588
$ appending output to nohup.out

$ 

[1]+  Stopped                 nohup transcode-video --mp4 --output TLJ.mp4 --crop 138:138:0:0 The_Last_Jedi_t00.mkv

However, if I redirect /dev/null to stdin, this works fine. I'm almost certain I didn't need to redirect stdin a few months ago, so I'm wondering if there's been a regression somewhere. If nothing else, it might be useful to document this oddity.

I can't imagine what sort of user input is ever expected!

I'm using 0.19.0 with HandBrakeCLI 1.1.0. Could it be an issue with HandBrakeCLI?

[lisamelton]

@chrisridd Thanks for opening this issue.

AFAIK, there's been no change to transcode-video itself that would cause this behavior. More than likely this is caused by either a change to HandBrakeCLI (as you suspected) or Ruby.

Can you try this with the previous release of HandBrakeCLI and let me know what happens? Thanks.

[chrisridd]

I used transcode-video's --dry-run option to get the HandBrakeCLI command-line, and it looks like HandBrakeCLI 1.0.0 and later appear to read stdin for some reason. Earlier versions of the CLI failed to run due to incompatible parameters, so I'm not sure when then started happening.

I've raised HandBrake/HandBrake#1316

[lisamelton]

@chrisridd You're seeing incompatible parameters because transcode-video adjusts the command line it sends to HandBrakeCLI based on the version and capabilities it detects at the time of invocation. More than likely the problem you're seeing can be corrected by substituting the newer --auto-anamorphic option with the older --strict-anamorphic option.

BTW, the minimum version that transcode-video requires is HandBrakeCLI 0.10.0 or later.

Thanks for filing that bug! I'll keep an eye on it.