Repository navigation
**(Feature Request) Please also add N_m3u8DL-RE as a media extractor and backend downloader** #40
Description
First of all, I would like to point out that this is one of the most beautiful download managers I have ever tried. The UI feels intuitive, well-organized, and user-friendly. And the fact that it also uses yt-dlp makes it extremely useful for downloading videos from 1,800+ supported sites.
I think adding N_m3u8DL-RE as a download engine for HLS/DASH videos could immensely increase the usefulness of this app.
What I propose is:
i) Let yt-dlp handle the sites that it officially supports.
ii) For generic sites that are not supported by yt-dlp, N_m3u8DL-RE could handle the HLS/DASH streams. It can even download encrypted HLS/DASH in cases where yt-dlp cannot.
The technical challenge, however, is not just implementing N_m3u8DL-RE. The downloader would also need to obtain the required URL, cookies, headers, and referer. (so its extension needs to have such capabilities)
Alternatively, Cat Catch could be used to fetch these required details, provided that this download manager supports query parameters or an API through which Cat Catch can pass the URL, cookies, headers, and referer to the downloader.
So this is essentially a feature request to further expand the functionality of an already wonderful app. Do you have any plans to add this kind of functionality, whether through N_m3u8DL-RE or your own implementation?
Thanks!
Activity
nimbold commentedon Aug 29, 2026
Thank you for your interest in Firelink and I really appreciate your kind words!
Thanks for the detailed suggestion. I agree that better support for generic HLS/DASH streams would make Firelink considerably more useful. After looking it up, I came up with the plan for the future which I'll explain below:
Short term
I plan to first use yt-dlp’s existing capabilities to their full potential. It can already process direct HLS and DASH manifests, so I want to improve Firelink’s workflow around it by:
.m3u8,.mpd, and.ismmanifest URLs.The main missing piece today is reliable and secure discovery of the manifest and its request context—not necessarily the download engine itself.
Longer term
After maximizing yt-dlp and identifying its remaining limitations, I plan to evaluate N_m3u8DL-RE as a specialized secondary media engine.
It appears particularly useful for:
I would only add it where it provides a measurable advantage over yt-dlp. This would keep Firelink’s package size, maintenance burden, download lifecycle, and cross-platform behavior manageable while still allowing me to expand its capabilities over time.
Regarding Cat Catch or other third-party extensions, I would not accept arbitrary command-line arguments, complete browser cookie headers, or unvalidated authentication data. Any future integration would use a structured, authenticated handoff and would always open Firelink’s Add window for user review before starting or queuing a download.
To clarify, encrypted-stream support would mean downloading content the user is authorized to access using available or user-supplied keys. It would not include obtaining or bypassing DRM licenses.
The overall direction is:
Thank you again for proposing this. It is a useful direction for Firelink, and I’ll keep this issue open to track the work.
ray2me123 commentedon Aug 29, 2026
I totally agree with your overall direction. Indeed, yt-dlp can handle generic HLS/DASH streams even when the site itself is not explicitly supported. We mainly need Firelink Companion to discover the manifest and provide the required request headers/context.
Previously, I used a stream detector to generate yt-dlp-ready commands, and most of the time yt-dlp was able to download the streams successfully. That said, from my experience, N_m3u8DL-RE is noticeably faster on many generic sites and seems to be less prone to getting stuck on individual fragments. But I completely understand your point that we should first make the best possible use of the engine that is already available. I think postponing the addition of another engine until the remaining limitations of yt-dlp are properly identified is a wise decision.
And you are exactly right about the distinction between encrypted streams and DRM. I was referring to encrypted HLS/DASH where the user already has legitimate access and the required keys are available; I would never suggest obtaining or bypassing DRM licenses. Apart from the potential legal issues, I also don't think automated DRM decryption is worth pursuing for a practical day-to-day downloader.
Looking forward to seeing the HLS/DASH improvements with yt-dlp in this app. Thanks again for taking the suggestion seriously!
nimbold commentedon Sep 1, 2026
Hi,
Sorry for the late reply, I didn't get the notification!
Thanks for the thoughtful follow-up, and for sharing your hands-on experience with stream detectors and N_m3u8DL-RE. The points about better performance and fewer fragment stalls are especially useful.
I agree that the next step is to make the yt-dlp path work well for generic streams first: reliable manifest discovery in Companion, validated headers and referrers, and a reviewed handoff through the Add window. Once that is in place, we can identify yt-dlp’s remaining limitations and decide whether N_m3u8DL-RE would be worthwhile as a complementary engine.
And thanks for clarifying the encrypted-stream/DRM distinction.
I’ll keep this issue open and share updates as the HLS/DASH work progresses.
feat(media): add safe manifest handoff and row routing
feat(media): add safe manifest handoff and row routing
fix(media): recover from missing browser cookie databases