List of proposed changes to MacYTDL - as at 9/4/23

Question

List of proposed changes to MacYTDL - as at 9/4/23

section83 opened this issue 3 years ago · comments

This is a list of features that might be added in the future. It is not in priority order. If you would like one of these or any other feature added to MacYTDL, please post an issue or discussion, or send an email (address is in the "About" dialog.

Look at whether “--merge-output-format” is a useful option to add.
- Only if merging video and audio files.
Add settings for Adobe Pass credentials, video password and .netrc credentials.
Redesign Help as a Wiki published on GitHub.
Add settings for “--autonumber-start” and “--output-na-placeholder”.
Redesign save/restore settings.
Consider whether/how to initiate parallel downloads when user pastes multiple URLs.
- Currently downloads serially by one YTDL request. Could go parallel – could be a setting.
Enable user to save one or more set of login credentials – could use KeyChain.
Provide UI for config file functionality – could have more than one switchable config.
Provide a macOS "Shortcut" to replace/supplement the current "Send-URL-to_MacYTDL" Service.
Option on installation to add shortcut to Dock.
- Involves killing the Dock process (which usually restarts) so that change to a plist file is implemented.
Organising downloads by uploader/downloader
- Is this of any benefit ?
Facility to get cookies from current browser.
Add option to control downloads according to date ?
Option to schedule downloads for a later time ?
Add "Archives" functionality.
Facility to search log files.
Enable the Monitor dialog to be hidden/minimised and non-modal – very difficult using AppleScript.
Enable user to position the Monitor dialog – tricky as each dialog is a separate process.
- Might be possible to keep separate download processes but one dialog.
Option to turn off notifications when downloads started/finished.
Add option to choose playlist items for download – currently always downloads entire list.
Add option to choose downloads from batch file – currently always downloads entire batch.
Only remove items from batch list which have been successfully downloaded.
Enable download of duplicates – perhaps with an index to differentiate files.
Add option to store YTDL settings with each URL in a batch – would enable different settings for each download.
- Could have one set of settings for each batch list.
Facility to create more than one batch list and choose which to download.
Add facility to recode codecs inside a container.
Provide a file count for playlists, batches and multiple downloads with progress e.g. "2 of 6 files completed".
Option to add shortcut to Dock.
Add an abort on error setting – on/off.
Add support for Homebrew and other installations of FFmpeg and YT-DLP/YTDL.

zx · Answer 1 · Mon Nov 29 2021 12:29:09 GMT+0800 (China Standard Time)

about ''24. Add option to delete URLs from batch file after download.''

as i understand, currently it deletes all of them if all the batch succeeded,
and doesn't remove anything at all, if even 1 of them failed / interrupted due to internet disconnect etc'....
i think the best default behavement is that it removes only the links of the successful downloads, while leaving these that failed / had issues / weren't downloaded.... if its not too troublesome to implement?

zx · Answer 2 · Mon Nov 29 2021 12:35:54 GMT+0800 (China Standard Time)

also about ''27. Add function to reset all settings to default.''
if you add something like that, then please..
make sure if you click this option, it gives a warning window with ''are you sure?'' and that 'cancel' is the default selected option for that window....
as such an option scares me XD especially when i can't export a backup of the settings i guess? lol
actually does backing up and restoring 'MacYTDL.plist' serve as a settings backup?

Vincentius · Answer 3 · Mon Nov 29 2021 13:53:44 GMT+0800 (China Standard Time)

Zxzzz8, many thanks for all that feedback. It really does help.

i think the best default behavement is that it removes only the links of the successful downloads, while leaving these that failed / had issues / weren't downloaded.

Yes, that would be best. It will take a fair amount of code crunching to follow each download. It will be difficult as the output from YT/YT-DLP is different depending on how much FFmpeg is used. The change would work in combination with idea 25 perhaps.

It ties in with idea 3 which I think is a priority.

about ''27. Add function to reset all settings to default.'' if you add something like that, then please..make sure if you click this option, it gives a warning window with ''are you sure?'' and that 'cancel' is the default selected option for that window.

Can do.

does backing up and restoring 'MacYTDL.plist' serve as a settings backup?

Yes, but, "MacYTDL.plist" is the only settings file currently used. So, you can manually rename it and a new plist file will be created on next startup. You can manage the various plists using their names (e.g. "MacYTDL-youtube.plist") and rename the one you want active to "MacYTDL.plist". I could add a function that does that. Just beware that removing or renaming "MacYTDL.plist" while MacYTDL is running will cause a crash (at present).

Cheers.

zx · Answer 4 · Mon Nov 29 2021 17:59:16 GMT+0800 (China Standard Time)

actually i was worried that mby im bothering you too much XD
but i guess i assumed i don't need to feel that way with how you respond? ^^

oh and about ''3. Provide for downloads to be paused and continued – possibly by adding "Keep files" option to the "Stop" function.''

can that also include the ability to not break the file when there is an internet disconnect?
i have quite an unstable internet recently in the past few years, and on top of that, its standard where i live to have dynamic ip, so that also breaks a file when that happens....

Vincentius · Answer 5 · Mon Nov 29 2021 18:29:42 GMT+0800 (China Standard Time)

Not sure what you mean by "break the file". Both youtube-dl and YT-DLP will continue a partial download. I have tested that and it works well. You will possibly see files with ".part" extension. That's a partial download. But the file is possibly not playable until complete.

Cheers.

zx · Answer 6 · Tue Nov 30 2021 05:55:35 GMT+0800 (China Standard Time)

i see, it gave me that impression, sense when i downloaded a batch, after a disconnect, it did not try to continue the partial file it stopped in the middle, but instead leave it like that and move to the next....

then i guess what i ask is that after a disconnect when using the batch tool, it will not move to the next file after a disconnect [or finish the process if its the last file], but instead retry to continue the file it stopped first....

Vincentius · Answer 7 · Tue Nov 30 2021 11:32:49 GMT+0800 (China Standard Time)

I have very little control over how youtube-dl/YT-DLP handle batches. I can't interrupt the Python process and force it to go back and try again. Also, there can be many causes of errors which youtube-dl/YT-DLP don't trap.

Nonetheless, I can monitor a batch download and when finished get MacYTDL to go back, find any errors and try again. However, it's tricky to test as my Internet connection does not disconnect – maybe I can test it by unplugging my Ethernet cable during a batch download !

There is an option to "abort-on-error" which might be what you're after. I'll add that as an option in "Settings". MacYTDL does already report that there were error(s) in a download. Abort-on-error will prevent the youtube-dl/YT-DLP process from continuing when there are problems such as flakey Internet connections.

zx · Answer 8 · Tue Nov 30 2021 12:40:58 GMT+0800 (China Standard Time)

section83--''Nonetheless, I can monitor a batch download and when finished get MacYTDL to go back, find any errors and try again....''

if you can do that^, then that might be the best solution for me, if it can check the broken files and finish downloading them, after finishing the main batch....

btw if you do that solution, do you think there is a chance that it will lose a few seconds part of the video where it brute-stopped due to internet loss?

Vincentius · Answer 9 · Tue Nov 30 2021 12:48:51 GMT+0800 (China Standard Time)

btw if you do that solution, do you think there is a chance that it will lose a few seconds part of the video where it brute-stopped due to internet loss?

youtube-dl/YT-DLP continue downloading from the point in the file at which it stopped. It doesn't matter how long the time is between downloading being stopped and being continued as long as the "part" file is available.

zx · Answer 10 · Tue Nov 30 2021 16:50:49 GMT+0800 (China Standard Time)

so the brute-stop won't corrupt some data if i understand correctly?

Vincentius · Answer 11 · Tue Nov 30 2021 17:56:40 GMT+0800 (China Standard Time)

Correct - including if the download process is killed, such as by the “Stop” function in MacYTDL.

…

On 30 Nov 2021, at 7:51 pm, zx ***@***.***> wrote: so the brute-stop won't corrupt some data if i understand correctly? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

nottooloud · Answer 12 · Fri Dec 03 2021 04:57:05 GMT+0800 (China Standard Time)

re 17 Enable finer choices on codecs ?

Is there way to output YT's webm as something that works with quicklook?

Vincentius · Answer 13 · Fri Dec 03 2021 07:23:12 GMT+0800 (China Standard Time)

As a first step, MacYTDL can remux from webm to mp4, mkv, ogg, avi and flv. But, I guess you found that while the video is playable in Quick Look, the audio is not. That's because the remux only copies the codecs across to a new container. YouTube webm files usually have audio using the Opus codec which Quick Look can't decode. Idea 17 would provide a way to re-encode video and/or audio into chosen codecs (which would be compatible with Quick Look).

Note that re-encoding takes a lot longer – on my (very slow) iMac re-encoding the video takes maybe 50 times the time. One video I tested took well over an hour.

Anyway, it's a useful option so, I'll push 17 up the priority list.

Thanks.

nottooloud · Answer 14 · Fri Dec 03 2021 07:28:12 GMT+0800 (China Standard Time)

M1 Mac Mini running 11.6.1, the MP4s are playable in iina or whatever, and the audio is fine, but they don’t play at all in quicklook or quicktime player. I really appreciate the work you’ve done on this. Can’t rely on any video remaining on the net, so it’s really good to be able to archive stuff locally.

Vincentius · Answer 15 · Fri Dec 03 2021 07:36:42 GMT+0800 (China Standard Time)

Yes, the remuxed files are playable in many players (e.g. VLC). But, for some reason, Apple has not included decoders for some codecs in their macOS frameworks/libraries.

I really appreciate the work you’ve done on this. Can’t rely on any video remaining on the net, so it’s really good to be able to archive stuff locally.

My pleasure – it has been a rewarding retirement occupation. Using a downloader can make watching videos much easier. I've had a lot of trouble trying to watch catch-up TV shows in a web browser. It's often flakey and controlling is painful with a keyboard or even a universal remote.

Gustavo Saez · Answer 16 · Mon Jan 17 2022 11:42:25 GMT+0800 (China Standard Time)

Any plans to compile as native Apple Silicon (M1)?

Vincentius · Answer 17 · Mon Jan 17 2022 17:48:29 GMT+0800 (China Standard Time)

Any plans to compile as native Apple Silicon (M1)?

On an M1 Mac, MacYTDL currently runs under Rosetta2. I have been able to borrow an iMac running macOS Monterey and Script Debugger 8. So, v1.21 of MacYTDL will be in universal format.

Eventually, I will acquire an M1 Mac and will be able to compile an M1 specific version as well. I doubt there will be a significant speed difference.

Cheers.

Gustavo Saez · Answer 18 · Mon Jan 17 2022 22:27:38 GMT+0800 (China Standard Time)

Any plans to compile as native Apple Silicon (M1)?

On an M1 Mac, MacYTDL currently runs under Rosetta2. I have been able to borrow an iMac running macOS Monterey and Script Debugger 8. So, v1.21 of MacYTDL will be in universal format.

Eventually, I will acquire an M1 Mac and will be able to compile an M1 specific version as well. I doubt there will be a significant speed difference.

Cheers.

Nice!! From my experience, I can affirm the performance is significant (and resources consumption also). Talking exclusively about AdGuard. For a long was running under Rosetta2... take some time to load and open and was consuming ~150MB RAM. After update to a native one, the app open almost instantly and consuming is around 70-80MB RAM. It's a good combination RAM and Speed. I can bet ~70% faster without Rosetta2.

I don't know how to do it, if so, I could fork the project and create a new release for Apple Silicon and give you to release to the project.

Vincentius · Answer 19 · Tue Jan 18 2022 06:58:16 GMT+0800 (China Standard Time)

I've created an arm64 version of MacYTDL. It is available here:

https://github.com/section83/MacYTDL/blob/master/Components/MacYTDL-arm64-test.zip

I have code signed and notarised that copy. Please beware, I took a pre-release copy of MacYTDL v1.21. So, it might have bugs and look ugly in places.

As far I understand, the only difference between x86_64 and arm64 versions is a small MacOS executable which is the AppleScript runner. So, the arm64 version should not be much faster than the Universal version – macOS will run the arm64 code inside a Universal arch executable.

I've converted that executable to arm64. I don't have an M1 Mac so, please post here how the results of your testing.

If the version I created works, you can create your own arm64 version any time using the same procedure as I used:

download the unsigned copy of MacYTDL;
open Terminal;

run this command:

lipo [path to]/MacYTDL.app/Contents/MacOS/applet -thin arm64 -output [path to]/MacYTDL.app/Contents/MacOS/applet2

where "[path to]" is where your downloaded copy is saved.

right-click MacYTDL;
navigate to the "MacOS" folder;
delete "applet";
rename "applet2" to "applet";
if you are a member of the Apple Developer Program you can code sign and notarise the applet.

Gustavo Saez · Answer 20 · Wed Jan 19 2022 11:13:29 GMT+0800 (China Standard Time)

I've created an arm64 version of MacYTDL. It is available here:

https://github.com/section83/MacYTDL/blob/master/Components/MacYTDL-arm64-test.zip

I have code signed and notarised that copy. Please beware, I took a pre-release copy of MacYTDL v1.21. So, it might have bugs and look ugly in places.

As far I understand, the only difference between x86_64 and arm64 versions is a small MacOS executable which is the AppleScript runner. So, the arm64 version should not be much faster than the Universal version – macOS will run the arm64 code inside a Universal arch executable.

I've converted that executable to arm64. I don't have an M1 Mac so, please post here how the results of your testing.

If the version I created works, you can create your own arm64 version any time using the same procedure as I used:
download the unsigned copy of MacYTDL;

open Terminal;
run this command:
lipo [path to]/MacYTDL.app/Contents/MacOS/applet -thin arm64 -output [path to]/MacYTDL.app/Contents/MacOS/applet2
where "[path to]" is where your downloaded copy is saved.

right-click MacYTDL;

navigate to the "MacOS" folder;

delete "applet";

rename "applet2" to "applet";

if you are a member of the Apple Developer Program you can code sign and notarise the applet.

Nice to know you found the difference. About the performance (Universal X arm64) I think won't be significant but what I see it's Universal takes more storage than a dedicated app, maybe because the app stores more code to support Intel and arm?

Gustavo Saez · Answer 21 · Wed Jan 19 2022 11:17:53 GMT+0800 (China Standard Time)

I've created an arm64 version of MacYTDL. It is available here:
https://github.com/section83/MacYTDL/blob/master/Components/MacYTDL-arm64-test.zip
I have code signed and notarised that copy. Please beware, I took a pre-release copy of MacYTDL v1.21. So, it might have bugs and look ugly in places.
As far I understand, the only difference between x86_64 and arm64 versions is a small MacOS executable which is the AppleScript runner. So, the arm64 version should not be much faster than the Universal version – macOS will run the arm64 code inside a Universal arch executable.
I've converted that executable to arm64. I don't have an M1 Mac so, please post here how the results of your testing.
If the version I created works, you can create your own arm64 version any time using the same procedure as I used:
download the unsigned copy of MacYTDL;

open Terminal;
run this command:
lipo [path to]/MacYTDL.app/Contents/MacOS/applet -thin arm64 -output [path to]/MacYTDL.app/Contents/MacOS/applet2
where "[path to]" is where your downloaded copy is saved.

right-click MacYTDL;

navigate to the "MacOS" folder;

delete "applet";

rename "applet2" to "applet";

if you are a member of the Apple Developer Program you can code sign and notarise the applet.
Nice to know you found the difference. About the performance (Universal X arm64) I think won't be significant but what I see it's Universal takes more storage than a dedicated app, maybe because the app stores more code to support Intel and arm?

About the test of the Apple Silicon version, it seems works fine, no bug noticed but the performance really wasn't improved. From click to show the window took around 15 seconds against 20 seconds from non-apple silicon.

About RAM Consumption

Vincentius · Answer 22 · Wed Jan 19 2022 16:47:42 GMT+0800 (China Standard Time)

maybe because the app stores more code to support Intel and arm?

Yes, the applet executable is larger because it has both x86_64 and arm64 code.

the performance really wasn't improved

That makes sense. The Universal build includes arm64 code which is what an M1 Mac will run.

It makes sense also that the memory footprint is greater as there is probably some overhead required to separate out and run the arm64 code. The number of threads might be relevant too.

Cheers.

Gustavo Saez · Answer 23 · Wed Jan 19 2022 22:47:12 GMT+0800 (China Standard Time)

I know you didn't asked but if you like you can use it. I just create a simple new logo (macOS BigSur Style) for MacYTDL. If you liked or need some improvements or more versions in lower resolutions just call me on telegram @gustavosaez .

Christo Kotze · Answer 24 · Sun Feb 12 2023 20:30:59 GMT+0800 (China Standard Time)

Have you considered that a user may have ffmpeg, ffprobe, youtube-dl and/or yt-dlp already installed on their system? If they are using homebrew, on Intel it will be in /usr/local/bin (no issue there), but on ARM it is now in /opt/homebrew/bin (a new change in homebrew). This would make it easier to see if it already installed, and also may prevent users from having version conflicts (depending on path variable).

You could also detect if homebrew is installed and give users the option to install through there as they are more likely to keep those versions up to date.

Vincentius · Answer 25 · Mon Feb 13 2023 06:45:47 GMT+0800 (China Standard Time)

Have you considered that a user may have ffmpeg, ffprobe, youtube-dl and/or yt-dlp already installed on their system?

Good question. I have looked at it but not in depth. In one case, a user had installed the Linux version of YT-DLP which caused errors. Other users have installed various Python versions in various ways which also caused some grief.

I didn't know Homebrew now puts executables in /opt/homebrew/bin on ARM Macs. Why did they change from /usr/local/bin ? Does that mean you have to add the path to /opt/homebrew/bin for YT-DLP to find FFmpeg ?

Does Homebrew install the correct version of YT-DLP ? i.e. "yt-dlp_macos" ?

You could also detect if homebrew is installed and give users the option to install through there as they are more likely to keep those versions up to date.

Yes, probably can do that. Do different versions of Homebrew live in different places ? Given that it's possible to install all the tools manually, i.e. without Homebrew, it might be useful to check other locations.

Currently the version number of the installed YTDL/YT-DLP is stored in MacYTDL.plist. I put it there as getting the current version by running YT-DLP was taking a long time every time the user started MacYTDL or opened Utilities (YT-DLP has to expand its Python runtime). It was a pain. Downside is that MacYTD currently doesn't know about copies of YTDL/YT-DLP installed elsewhere, installed/updated by another user on the same Mac or manually updated. Fixing that is on my todo list.

Thanks.

Christo Kotze · Answer 26 · Tue Feb 14 2023 00:52:30 GMT+0800 (China Standard Time)

Dear Vincentius, I didn't know Homebrew now puts executables in /opt/homebrew/bin on ARM Macs. Why did they change from /usr/local/bin ? You can find out more about the change on this webpage<https://earthly.dev/blog/homebrew-on-m1/>. I ported my old macbook pro to my new M1 one, which was still in /usr/local/bin. I had to uninstall and reinstall it to get it in the correct new location. The new location is better for several reasons stated on the webpage. Does that mean you have to add the path to /opt/homebrew/bin for YT-DLP to find FFmpeg ? You will need to add /opt/homebrew/bin to the path to find the installed programs, however, I think that the versions that you install will use the versions in /usr/local/bin if that is first in the path, so it would depend on how the path is configured. On my machine, I put the new location before the old location to know which version is running. You can get the version installed by looking in /opt/homebrew/Cellar/<package>/<version>, e.g. ❯ ls /opt/homebrew/Cellar/yt-dlp/ 2023.1.6 ❯ ls /opt/homebrew/Cellar/ffmpeg/ 5.1.2_4 ❯ ls /opt/homebrew/Cellar/youtube-dl/ 2021.12.17 The versions installed on the system in brew should also be the ARM versions, so should work faster, as the Intel versions have to go through Rosetta 2 translation. Does Homebrew install the correct version of YT-DLP ? i.e. "yt-dlp_macos" ? It only installs Mac versions of software. Do different versions of Homebrew live in different places ? On Intel it only lives in /usr/local/bin at the moment. On ARM it can be in either /usr/local/bin (if you port from an old Mac to a new one) or /opt/homebrew/bin if you do a clean install. I hope that this clears up most of your questions. Feel free to let me know if you need more info. Regards, Chris From: Vincentius ***@***.***> Date: Monday, 13 February 2023 at 02:45 To: section83/MacYTDL ***@***.***> Cc: Christo Kotze ***@***.***>, Comment ***@***.***> Subject: Re: [section83/MacYTDL] List of proposed changes to MacYTDL - as at 22/1/23 (#36) Have you considered that a user may have ffmpeg, ffprobe, youtube-dl and/or yt-dlp already installed on their system? Good question. I have looked at it but not in depth. In one case, a user had installed the Linux version of YT-DLP which caused errors. Other users have installed various Python versions in various ways which also caused some grief. I didn't know Homebrew now puts executables in /opt/homebrew/bin on ARM Macs. Why did they change from /usr/local/bin ? Does that mean you have to add the path to /opt/homebrew/bin for YT-DLP to find FFmpeg ? Does Homebrew install the correct version of YT-DLP ? i.e. "yt-dlp_macos" ? You could also detect if homebrew is installed and give users the option to install through there as they are more likely to keep those versions up to date. Yes, probably can do that. Do different versions of Homebrew live in different places ? Given that it's possible to install all the tools manually, i.e. without Homebrew, it might be useful to check other locations. Currently the version number of the installed YTDL/YT-DLP is stored in MacYTDL.plist. I put it there as getting the current version by running YT-DLP was taking a long time every time the user started MacYTDL or opened Utilities (YT-DLP has to expand its Python runtime). It was a pain. Downside is that MacYTD currently doesn't know about copies of YTDL/YT-DLP installed elsewhere, installed/updated by another user on the same Mac or manually updated. Fixing that is on my todo list. Thanks. — Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAFL7FXQKVVMZB3ZDS6J54TWXFR2LANCNFSM462TMHFA>. You are receiving this because you commented.Message ID: ***@***.***>

Christo Kotze · Answer 27 · Tue Feb 14 2023 00:54:07 GMT+0800 (China Standard Time)

The the main motivation for the change was to allow the transition from Intel to Apple Silicon.

In #9117, we switched to a new prefix of /opt/homebrew for installations on Apple Silicon. This was written and shipped with heroic speed to help prevent strange issues with bleeding edge users on the first consumer Apple Silicon Macs.
—Misty De Méo - Homebrew Maintainer

It could be possible to move everything back to /usr/local/bin in the future, but there are other reasons for sticking with /opt/homebrew even after the Intel Macs are long gone.

Homebrew is not the only tool that installs things in /usr/local/bin and so the potential for conflicts has always been an issue.
There are security concerns with using /usr/local/bin.
Other package managers have been using /opt/<manager_name> for a while now.
So in the long run this is a positive change, but not without a few growing pains along the way.

Vincentius · Answer 28 · Tue Feb 14 2023 06:23:12 GMT+0800 (China Standard Time)

Many thanks for all this. It's a great help. I've added Homebrew and other self-installs to my list for changes in v1.24.

In #9117, we switched to a new prefix of /opt/homebrew for installations on Apple Silicon. This was written and shipped with heroic speed to help prevent strange issues with bleeding edge users on the first consumer Apple Silicon Macs.

As a Mac user, I'm grateful for such efforts. I hope that someone bought them a coffee, at least.

onaforeignshore – thank you for raising this. It's also alerted me to an improvement in YT-DLP that I missed. There is now a version of YT-DLP, yt-dlp_macos_legacy, which runs on macOS 10.9 to 10.15. I missed the clue provided in release notes for yt-dlp 2022.06.29. Ah well, better late than never.

Vincentius · Answer 29 · Wed Mar 08 2023 06:53:37 GMT+0800 (China Standard Time)

onaforeignshore

I've added /opt/homebrew/bin to the temporary $PATH MacYTDL uses to run YT-DLP/youtube-dl. Are there other locations which should be added ?

UPDATE: It looks like Homebrew installs on Intel Macs is a bit of a pain. For example, after installing on a Mac Mini running OSX 10.13, I found YT-DLP was in "/usr/local/Cellar/yt-dlp/2023.3.4/libexec/bin/yt-dlp". So, the location changes every time YT-DLP is updated. There is an alias in /usr/local/Cellar/yt-dlp/2023.3.4/bin which is no better. I can't find any aliases in a friendly location. Also, the version is a different format to that used by the YT-DLP developers.

Moving to /opt/homebrew/bin was a very good idea.

UPDATE 2: Have decided to only use Homebrew install of YT-DLP if there is no MacYTDL install. Also, MacYTDL will not check/update a Homebrew install.

adenosslept · Answer 30 · Fri Nov 24 2023 22:12:24 GMT+0800 (China Standard Time)

Hi, just wondering if there's a quality control? I'm trying to download HD from 7Plus. It downloads fine but always downloads the lesser quality one instead. I know it's a little trivial but maybe something to look into?

Vincentius · Answer 31 · Sat Nov 25 2023 06:46:15 GMT+0800 (China Standard Time)

MacYTDL uses the Python script "YT-DLP" to download videos. YT-DLP defaults to download the best resolution available. That's not easy given the variety of video-only, audio-only and audio+video downloads in different formats that can be available. The YT-DLP developers explain:

The default format selector is bv*+ba/b. This means that if a combined video + audio format that is better than the best video-only format is found, the former will be preferred.

In MacYTDL, the default file format uses the YT-DLP default.

7Plus is like SBS and the ABC – although free-to-air HD is 1080p, they often only provide 720p for streaming or even worse. For example, the resolution 7Plus provide for RFDS streaming is 720p – but, YT-DLP can see those files only if you use the cookies options e.g. --cookies-from-browser. You can supply the cookies options to MacYTDL using "Custom settings".

Cheers.

Christo Kotze · Answer 32 · Sun Nov 26 2023 11:11:15 GMT+0800 (China Standard Time)

UPDATE: It looks like Homebrew installs on Intel Macs is a bit of a pain. For example, after installing on a Mac Mini running OSX 10.13, I found YT-DLP was in "/usr/local/Cellar/yt-dlp/2023.3.4/libexec/bin/yt-dlp". So, the location changes every time YT-DLP is updated. There is an alias in /usr/local/Cellar/yt-dlp/2023.3.4/bin which is no better. I can't find any aliases in a friendly location. Also, the version is a different format to that used by the YT-DLP developers.

It seems there was an issue with the link on Intel Mac, but it has been resolved - see this

UPDATE 2: Have decided to only use Homebrew install of YT-DLP if there is no MacYTDL install. Also, MacYTDL will not check/update a Homebrew install.