AzuDl - GC2GD runs aria2 and yt-dlp inside a Colab notebook and files the results in Google Drive

The runtime is a Colab notebook, and Drive replaces the local disk

There is nothing to install. No package name appears anywhere in the project, and the README gives no pip line. What ships is Python source meant to run inside a hosted Google Colab notebook, with aria2 and yt-dlp doing the transfer and Google Drive standing in for the disk a normal downloader would write to.

That choice fixes most of the project's constraints. A Colab VM keeps no permanent local storage, so a download that never reaches Drive is lost when the runtime is reclaimed, and a transfer that has to run for hours must survive being detached. The version string carried in the README is `Version: 1.4.20 GUI Beta`. The repository is MIT licensed, written in Python, and its homepage is https://theazizi.ir. Its last push landed on 2026-10-01, and the project publishes no GitHub releases, so the README text and the file names in the repository are the only record of what is current.

The root is a shelf of dated copies, and no tag says which one leads

The repository root holds four copies that carry a version in square brackets: `Code [BETA 1.4.20 GUI].py`, `Code [BETA 1.4.20 CLI]`, `Code [1.3.0 CLI].py` and `Code [OUTDATED 1.0.0 CLI].py`. Two more use an all caps scheme, `AzuDL_GC2GD_v1.5.0_COMPLETE_COLAB.py` and `AzuDL_GC2GD_COMPLETE_SECURITY_COLAB.py`.

The mismatch is the first thing a new user trips over. The README names 1.4.20 GUI Beta as the current version, yet a file labelled 1.5.0 sits in the same directory and nothing in the repository says which one is ahead. One file carries the word OUTDATED in its name, so the author treats the root as a place where old copies accumulate rather than something cleaned up at release time. With no GitHub releases published, there is no tag to check either.

Security work sits next to the downloader: `azudl_security.py`, `SECURITY_CODE_INTEGRATION.py`, and four documents named `SECURITY.md`, `SECURITY_AUDIT.md`, `SECURITY_GUI_CODE.md` and `README_SECURITY.md`. A `m3u8_downloader.ipynb` notebook, a `CHANGELOG.md`, a `CONTRIBUTING.md` and a Persian `README.fa.md` fill out the directory. Deciding which file to paste into Colab is the opening task, and the project leaves it open.

One download engine behind launch_gui() and main()

AzuDl chooses its front end before the script does any work. From 1.4.20 onwards the widget GUI is the default: calling `launch_gui()` starts it, and `main()` still reaches the original text menu. The interface can also be forced through the environment ahead of the run:

import os
os.environ["AZUDL_INTERFACE"] = "cli"

The variable has to exist before the script starts, which in a notebook means a separate cell above the one that runs AzuDl. Nothing in the README describes what happens if it is set after import.

Both front ends drive the same core: aria2, yt-dlp, Drive storage, download history, ZIP and SHA256 tools, and aria2 session persistence. The GUI is the newer of the two and is called a beta release, and the README says it may still pick up visual improvements, layout changes and usability updates, so its arrangement is not a stable surface to script against.

Fourteen GUI tabs over a seventeen item text menu

The GUI spreads its controls across fourteen tabs:

Dashboard
Auto
Direct
YouTube
Auth
Torrent
Batch
GitHub
Official
Files
Archives
Maintenance
Developer
Guide

Each tab owns a job rather than a stage, which is why the Dashboard sits beside the file tools instead of at the end. The Direct tab takes a custom file name, a folder, request headers and a speed limit. The Auto tab decides whether a pasted link is direct, YouTube, magnet or `.torrent`, then hands it to the matching path.

The text menu it replaces has seventeen numbered entries, ending with Developer, Help, Exit and then `17. Launch Colab GUI`, so a text user can reach the GUI from inside the CLI. The GitHub tab has no equivalent numbered slot. It fetches a public or private repository's releases, assets and source archive, or pulls the README and license file alone, and it accepts a specific release tag rather than only the latest. The Auth tab carries a GitHub token field with a rate-limit status readout. An Official tab fetches the AzuDl repository itself without the user typing the URL.

InfoHash checks and session persistence guard the torrent path against a reclaimed runtime

The torrent branch is where the project shows the most care, and the reason is visible in its own feature list: a Colab runtime can disappear mid transfer, and a naive retry fetches the same data twice.

Four mechanisms push against that. Duplicate torrent InfoHash detection refuses a magnet it has already seen. When a matching task already exists, aria2 resumes it instead of adding a second copy. Torrents that error out are removed automatically, so a failed duplicate does not sit in the list indefinitely. And aria2 session persistence saves the downloader's task state so a new runtime can pick the work back up.

1. Torrent magnet
2. Torrent file
3. Private torrent
4. aria2 status
5. Remove aria2 GID
6. Clear stopped aria2 results
7. Save aria2 session
8. Back

The last four entries are the maintenance surface, and they reappear in the GUI's Maintenance tab next to force Drive sync, diagnostics and a storage check. Seeding is optional and instrumented: live download progress, live seeding status, upload speed, uploaded size, ratio, and seeder and connection counts are all surfaced rather than left inside aria2's own output. Private trackers are reachable through the Private torrent option, which the README does not explain further.

Video only YouTube formats get the best available audio track attached

The YouTube branch exposes the format layer instead of hiding it. Quality selection is a dropdown, audio only extraction produces MP3, and playlist mode downloads a whole playlist. There is also custom format ID support for the case where the chosen quality does not exist for a particular video, plus an automatic repair that attaches the best available audio when the selected format turns out to be video only. That fix matters only because the format list differs per video, which is the usual reason a quality choice silently yields a file with no sound.

Metadata and thumbnails come down alongside the media. The Guide tab offers three references: general help, cookie help, and PO Token help. The README does not say what a PO Token is or which failures it addresses, so a user who hits that wall has to read the help inside the notebook or read the script to find out.

SHA256 and ZIP work on the Drive folder, whose layout the documentation leaves unfinished

After a transfer, the file tools operate against the Drive folder rather than a working directory. The Files tab lists downloads, opens the most recent one, and computes a SHA256 hash for either the latest file or a chosen selection. The Archives tab zips a selected folder or the folder holding the latest download. Download history and a storage report sit beside them, and a force Drive sync tool in Maintenance covers the case where a copy has been written but is not yet visible.

The gap is the folder layout. The README opens a Storage Structure section and breaks off after the single word Azu, so the Drive paths this tool creates and zips are not written down anywhere in the documentation. Anyone who wants to point a later script at AzuDl's output is reading the Python to find the names.

What running aria2 and yt-dlp on a machine you keep changes

The alternative is to run the same two tools yourself. On a host you control, aria2 and yt-dlp write to a disk that persists between runs, can be started by cron or a systemd timer, and are configured from files you edit rather than from notebook widgets.

AzuDl puts the identical engine inside someone else's hosted notebook and pays for the free runtime by giving up the disk, the schedule and the fixed paths. That trade suits a person moving a handful of files by hand. It does not suit a seed held open for days or a batch that has to restart on its own. A storage report gives a figure for what landed in Drive, and the README does not document the quota that figure is measured against.

Editorial conclusion

Adopt AzuDl - GC2GD for a one-off download you want sitting in Google Drive, and only if you are comfortable pasting a file into a notebook and clicking through a beta GUI. Do not adopt it for unattended transfers: a seeding ratio held open for days, a scheduled batch, or anything that needs its output at a known path, since the Drive layout is not written down. Two checks come before that decision. Open the root directory and find out whether AzuDL_GC2GD_v1.5.0_COMPLETE_COLAB.py sits ahead of the Code [BETA 1.4.20 GUI].py the README points at, and run one small transfer, then save the aria2 session and confirm a fresh runtime reloads it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. TheGreatAzizi/AzuDL-GC2GD on GitHub