Ghost Downloader 3: a Qt downloader that speaks HTTP, BitTorrent, M3U8 and eD2k

What Ghost Downloader 3 replaces, and who ends up using it

Most people running a download manager end up with a stack: one tool for HTTP, a BitTorrent client, something for HLS streams, a separate utility for YouTube, and a browser extension to catch media the page never links directly. Ghost Downloader 3 is an attempt to collapse that stack into a single Qt desktop application. The README frames the pitch plainly, describing it as "One app instead of five", and lists HTTP, Magnet/BT, FTP, M3U8, MPEG-DASH and eD2k as the protocols it handles, with dedicated parsers for YouTube, Bilibili, GitHub and HuggingFace.

The project started, according to its own About section, as a tool to help a Bilibili creator manage resources. That origin explains the shape of the feature set. Bilibili and YouTube parsing with clip selection and quality choice sits at the centre, not bolted on as an afterthought, and the browser extension exists to sniff media on a page rather than to intercept ordinary file links. The realistic audience is someone who downloads a lot of video from streaming sites and also wants a general-purpose downloader for everything else, on a desktop where they can install a Qt application. It is not aimed at server operators or at people who want a command-line-only tool.

How the protocol handlers fit together

The dependency list in pyproject.toml is the clearest view of the architecture, because it shows which parts are written in Python and which are delegated. FTP goes through aioftp. M3U8 parsing uses the m3u8 library, MPEG-DASH uses mpegdash, and the README credits N_m3u8DL-RE as the tool "powering Ghost Downloader's M3U8 support". BitTorrent is handled by libtorrent, a C++ implementation, with a separate libtorrent-windows-dll package on Windows. eD2k runs through goed2k, described in the README as the eD2k download daemon behind the support. FFmpeg is listed as an external dependency, which is expected for remuxing stream segments.

The networking layer is not plain asyncio. The project depends on wreq, and on uvloop for non-Windows platforms with winloop on Windows, so the event loop is swapped per operating system. The README claims "Real-browser TLS fingerprints" for avoiding anti-bot checks, which is consistent with a dependency like wreq rather than a stock HTTP client. The GUI is PySide6 with pyside6-fluent-widgets, so the fluent-design look comes from a widget library rather than custom-drawn chrome. The entry point is a single Ghost-Downloader-3.py at the repository root, with the rest of the code under app/, features/ and tools/.

One design claim is worth pulling out. The README says the downloader does "Smart chunking without file merging", meaning the chunks are written into their final positions rather than concatenated at the end. If that holds, it avoids the double-disk-write that plagues many multi-connection downloaders on large files. The README does not document how partial chunk state is recovered after a crash, so treat crash resilience as unverified.

Installing Ghost Downloader 3 and grabbing your first stream

The README does not contain a build-from-source walkthrough. It points to the documentation site at gd.xychr.com and lists platform requirements in a table: Windows 10 or newer, macOS 13.0 or newer, Linux with glibc 2.35 or newer, and Android 11.0 or newer. Architectures are x86_64 and arm64 for the desktop platforms, and arm64-v8a only for Android. If you are on Arch Linux, the README notes community-maintained AUR packages, ghost-downloader-bin and ghost-downloader-git, maintained by a named contributor.

For a source checkout, the repository is a uv project. pyproject.toml declares requires-python as 3.13 or newer and pins pyside6 to the 6.10 series, so the toolchain is narrow. The uv.lock file at the root is the intended lockfile.

uv sync
uv run Ghost-Downloader-3.py

The first command resolves the dependencies listed in pyproject.toml, including libtorrent, aioftp and pyside6-fluent-widgets, and the second launches the Qt application from the root entry script. Expect the first sync to be slow on Windows because of the libtorrent-windows-dll package.

A first real use is a Bilibili or YouTube video. Paste the page URL into the new-task field. According to the README, the app offers clip selection and quality choice for those two sites, so you should see a quality list rather than a single opaque file. For a stream that is not on a supported site, the workflow described in the README is the browser extension: a download button floats on the video, and a popup lists every medium on the page, with the desktop app taking over either way. The README states that signed-in state is included, which matters for gated content.

There is also an aria2-compatible RPC interface for third-party tools. The README does not publish the default port or a configuration example, so check the documentation site before pointing an existing client at it.

The AVX requirement is the constraint that will bite first

The README carries a warning that Qt 6.6 and newer no longer supports CPUs without the AVX instruction set. That is a hard floor, not a soft recommendation. Older x86_64 machines, and some virtualised or emulated environments that do not expose AVX to the guest, will not run the application at all. This is the kind of requirement that is easy to miss until launch fails, and it rules out a chunk of pre-2011 hardware and a lot of cheap VPS instances.

Android is the second constraint. The platform table lists arm64-v8a only. There is no x86_64 Android build documented, so emulators and Intel-based Android devices are out. The README also does not describe a headless or daemon mode, and there is no server-oriented install path in the documentation. If your goal is a download daemon on a NAS or a seedbox, this is the wrong tool; the aria2-compatible RPC is a compatibility surface for third-party tools, not a statement that the app runs without a GUI.

The Feature Packs plugin system is described as operational, but the roadmap still lists "Make the plugin API public" as unchecked, with the note that the API is stabilising. Writing a plugin against it today means writing against something the maintainers have not committed to. The second roadmap item, binding multiple Sessions to one task, is also open.

Where Ghost Downloader 3 sits against aria2 and yt-dlp

The obvious comparison is aria2, because the project advertises an aria2-compatible RPC. The difference in approach is that aria2 is a headless daemon with a JSON-RPC and XML-RPC control surface, and every frontend is someone else's problem. Ghost Downloader 3 ships its own Qt GUI as the primary interface and treats RPC compatibility as a secondary door for existing tooling. If you already drive downloads from scripts or a web frontend against aria2, Ghost Downloader 3 can slot in behind that interface, but you gain nothing from the GUI in that setup and you inherit a much heavier dependency tree, including Qt and libtorrent.

The second comparison is yt-dlp. For YouTube and Bilibili specifically, yt-dlp covers far more sites and is scriptable, but it is a command-line extractor, not a download manager: no persistent task list, no browser-extension sniffing workflow, no multi-protocol client. Ghost Downloader 3's parsers are narrower by design and its value is that the same task queue holds a YouTube video, a torrent and an FTP file. If your work is almost entirely site extraction and you are comfortable in a terminal, yt-dlp plus a separate BitTorrent client is the more predictable arrangement. If you want one window and a floating download button on the page you are already watching, the integration is the point.

Licence, maintenance and upgrade cost

Ghost Downloader 3 is distributed under GPL v3.0, with the README pointing to the LICENSE file and copyright noted as 2024-2026 XiaoYouChR. For individual desktop use the licence changes nothing. For anyone embedding the code in another product, GPL-3.0 is a copyleft licence with source-disclosure obligations, and the project bundles or links several third-party components with their own terms, including libtorrent, FFmpeg and Qt under PySide6. Whether a given distribution arrangement satisfies all of them is a question for a lawyer, not for this article.

On maintenance, the last push to the default branch was on 2026-08-26, and the most recent releases v4.3.5, v4.3.6 and v4.3.7 all landed on 2026-08-25 and 2026-08-26. The repository is not archived. That is a recent release cadence, and it also means the version string in pyproject.toml (4.3.5) trails the latest tagged release, so do not read the manifest as the current version.

Upgrade cost is dominated by the Python floor. requires-python is 3.13 or newer, and pyside6 is pinned to the 6.10 series. Moving to a new Python or Qt release is a coordinated change across the whole dependency set, including libtorrent bindings, which tend to lag. On Arch, the AUR packages move with the distribution; on other platforms you are tracking the project's own release artefacts. Nothing in the documentation describes a migration path between major versions.

Editorial conclusion

Adopt Ghost Downloader 3 if you want one desktop app covering HTTP, Magnet/BT, FTP, M3U8, MPEG-DASH and eD2k, with YouTube and Bilibili parsing and an aria2-compatible RPC surface, and you are willing to run Python 3.13 with Qt 6.6 or newer and an AVX-capable CPU. Skip it if you need a stable third-party plugin API, a headless Linux server build, or an x86_64 Android package, since the README lists only arm64-v8a. Before committing, verify that your CPU exposes AVX, that your Linux distribution ships glibc 2.35 or newer, and whether the Feature Packs API has left the roadmap unchecked state.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes