List of proposed changes to MacYTDL - as at 31/7/24 #36
Comments
|
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, |
|
also about ''27. Add function to reset all settings to default.'' |
|
Zxzzz8, many thanks for all that feedback. It really does help.
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.
Can do.
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. |
|
actually i was worried that mby im bothering you too much XD 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? |
|
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. |
|
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.... |
|
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. |
|
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? |
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. |
|
so the brute-stop won't corrupt some data if i understand correctly? |
|
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.
|
|
re 17 Enable finer choices on codecs ? Is there way to output YT's webm as something that works with quicklook? |
|
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. |
|
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.
|
|
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.
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. |
section83
changed the title
section83
changed the title
|
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. |
|
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:
where "[path to]" is where your downloaded copy is saved.
|
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 |
Yes, the applet executable is larger because it has both x86_64 and arm64 code.
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. |
|
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 .
|
section83
changed the title
section83
changed the title
|
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. |
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" ?
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. |
|
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: ***@***.***>
|
|
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. 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. |
|
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.
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. |
|
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. |
section83
changed the title
|
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? |
|
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:
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. |
It seems there was an issue with the link on Intel Mac, but it has been resolved - see this
|
section83
changed the title
section83
changed the title
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.
The text was updated successfully, but these errors were encountered: