Improve handling of search for YTDL executables

[techanon]

• Improve path search logic to include some standard YTDL (not just yt-dlp) executable names.
• Add menu option for specifying a precise custom executable location under Tools -> AudioLink -> Select - Custom YTDL Location.
• Move _localytdlpPath use to windows only as it's an exe specific path.
• Update LocateExecutable to support intaking a list of possible known ytdl executable names to improve search reliability.
• Update LocateExecutable to support PATH quirks with certain MSeries Macbooks.

[float3]

under what scenarios?

[float3]

https://docs.unity3d.com/Manual/VideoSources-FileCompatibility.html this is the reason we disabled it on linux

[techanon]

So it's an editor specific thing then. Ok.

[float3]

I don't remember what format ytdlp serves when the source is youtube, but maybe there's a way to get it to serve a specific format? if that was the case I would be okay with having it available on linux

[float3]

I'm not sure if we want to support ytdl

[float3]

So it's an editor specific thing then. Ok.

did you test your changes on mac in editor?

[techanon]

did you test your changes on mac in editor?

That specific Mac part is ported from the changes I made to VideoPlayerShim based on the feedback from an M-Series Mac user. The shim uses somewhat different search logic, but the path requirement for m-series is the same.

I'm not sure if we want to support ytdl

Is there a reason why not? Also it's all local side. Isn't it better to support the canonical name of ytdl as well as the ytdlp fork when searching for a users local install? The search logic prioritizes VRChat's official install first anyways, as well as ytdlp being searched for first in the list of possible names.

[pema99]

Looks sane overall. Perhaps there should be a way to clear the custom path you've set previously though?

[techanon]

The current way that the custom path gets cleared is by clicking the menu option to open the file select dialog, and then clicking cancel. This returns an empty string path which is detected as not provided, thus falling back on the auto-detect methods.

[float3]

The current way that the custom path gets cleared is by clicking the menu option to open the file select dialog, and then clicking cancel. This returns an empty string path which is detected as not provided, thus falling back on the auto-detect methods.

yeah this is not an acceptable method of clearing the custom path

[techanon]

We can switch it to a menu toggle style. When active, selecting it again implicitly clears it, then to pick a new path, select the menu again. How's that sound?

[pema99]

Sounds like an improvement to me

[techanon]

Meant to push to a separate branch.

[pema99]

Got some conflicts now, probably with your other PR

[techanon]

@pema99 fixed.