Change recommendations to prefer Bash on Windows

[samhutchins]

I've spent a lot more time playing around with Bash on Windows recently, it's cool stuff. Having thought more about the pros/cons of enabling developer mode and stuff I'm happy to recommend using Bash on Windows for this, as PATH modification is no better

The only (very minor) downside to Bash on Windows is that the console output lags during transcoding. This doesn't affect the actual performance of the transcode in any way, it just looks a bit weird. It's possible to SSH into Bash on Windows using something like Putty if it really bothers you ;-). I'm also confident that this will be fixed in the next big update to Windows

I think we should restructure the readme into 1 document with 2 sections:

• Windows 10 users If you have Windows 10 you probably also have the Creators Update, so installing video transcoding is as straightforward as it can be
• Older versions of Windows The only way to install these tools on older versions is to trawl the internet for binaries, so we should keep that method around for 'legacy' users

@JMoVS, @donmelton do either of you have any thoughts on this?

[lisamelton]

@samhutchins I like this idea!

As you know from other issues folks have filed, getting properly escaped paths in the output from detect-crop when using Windows built-in shells (i.e. cmd.exe and PowerShell) is close to impossible. So I would love to point more people toward using Bash and other Unix-workalikes.

But I didn't realize that Bash console output was lagging at the moment. So that's a problem with Windows itself and not the particular Bash binary you're using?

[samhutchins]

@donmelton The Bash I'm using is the whole "Bash on Ubuntu on Windows" thing Microsoft have made for Windows 10 otherwise known as the Windows Subsystem for Linux. It's a really neat feature, turns my PC into the best of Linux and the best of Windows combined. When people use this feature they're basically using Linux. Hell, you can install an X server in Windows then do something insane like run Gnome or KDE on Windows

I'd say the lagging console output is an issue in Windows, somewhere in this subsystem. Like I said, its not a big deal. I'll try to get a video showing exactly what I mean, but it just feels like the terminal buffer can't keep up with HandBrake's output

[samhutchins]

@donmelton, having said that... I just tried using --dry-run to get the HandbrakeCLI command then copy-pasted that to run it and I don't see the lagging behaviour... Weird

[JMoVS]

Yeah, but it doesnt affect transcode speed anyway. And yes, I am totally on board with the restructuring and the associated ramifications.

One thing that is worth noting is that there seemingly isn't a way to access network shares from within LXSS. Or did you, @samhutchins find a way to do that?

[samhutchins]

@JMoVS I don't have a network share to test with, and I suspect trying to transcode over a network is a horrible, horrible idea

I'd guess that if you mounted it as a network drive it'd work though... Surely it'd be at /mnt/[drive]/. But I can totally believe that those \\network-share\folder paths don't work in bash. They don't even work in cmd.exe

[JMoVS]

@samhutchins Nah, I did many network share based transcodings - if you have good wifi and a medium/slow Mac, it's not limiting and if time isn't a factor, my dad (who has the movies on the NAS) doesn't want to copy them around. ;-) But anyway, I'll research it when I have time, might be a while though ;-)

I will try the mount option though!

[lisamelton]

@JMoVS @samhutchins Yeah, I almost always transcode from SMB network shares since all my Blu-ray and DVD rips are on one of my NAS devices. Of course, the output goes to a local SSD drive since writing to the network, even at Gigabit Ethernet speeds, can affect performance compared to that.

[samhutchins]

@donmelton @JMoVS Dang, I wouldn't even consider transcoding over the network. But then again I have a tower PC with 5TB of internal storage, so I've very little need to

FWIW, I've done this to work around the laggy bash output

alias my-transcode-video='f() { tvc=$(transcode-video --mp4 --aac-encoder fdk_aac --dry-run "$@"); eval $tvc; }; f'

I'll put together a new document recommending using Bash on Ubuntu on Windows and submit it for review in the next few days

[JMoVS]

do we want to include this workaround? And how does this workaround work?

[samhutchins]

@JMoVS to be honest I'm not sure it's needed, I did a fresh install of Bash on Ubuntu on Windows and I have no more lagging output.

FWIW it works by calling transcode-video with the --dry-run command, which will print the HandBrake command that transcode-video uses to transcode. Bash has a builtin called eval that lets you call a string as a command. So the alias creates and calls a function that stores the output of --dry-run in tvc, then calls eval on tvc to run that Handbrake command directly.

For whatever reason, having the logging from HandBrake go through Ruby made things lag a bit, but it seems to be fixed now anyway

[JMoVS]

👍