One Queue, Several Ways to Acquire Media

OmniGet's queue accepts a common kind of request—a local file should appear—but the transfer behind that request may be direct streaming, an HLS or DASH playlist, or a platform job executed through yt-dlp. This chapter focuses on those acquisition paths and on the managed engine that supports one of them. Readers should finish able to connect URL shape and session context to transfer mechanics, and to understand why a bundled downloader needs verification, limits, updates, and visible commands.

The previous stage established that a browser can supply cookies, referers, or a captured manifest. Those pieces are not the download itself. They are evidence and request context that a particular transfer path consumes. OmniGet's design becomes clearer when the path is treated as a contract: what object is being fetched, which headers or cookies it needs, who combines its parts, and what counts as a usable result.

Direct files, playlists, and platform jobs

A direct file is the simplest case. If the URL looks like a video, audio, document, image, or other direct resource, OmniGet can construct a media description from the path and hand the request to an HTTP downloader. There is no need to ask a platform extractor to discover a page that the URL has already bypassed. The direct path can still use a referer, user-agent, extra headers, or cookies from the browser bridge, because a direct address may be valid only when requested in the same context as the page that exposed it.

The simplicity is conditional. A URL ending in a familiar extension can still return an HTML login page, an expired-link message, or a server error. Direct handling therefore saves extraction work; it does not eliminate validation. The downloader uses a partial file while it works, checks response and size information when available, and performs a final check before treating the result as a real artifact. These checks belong to the transfer path because a successful request status alone does not establish that the bytes are the intended media.

HLS and DASH are different because the URL often names a manifest rather than a finished file. The manifest describes a sequence of fragments or alternate representations. OmniGet must fetch that description, carry the referer and cookies that make its fragment requests acceptable, download the pieces, and produce a local output in the requested form. The browser extension may provide the manifest text when the page exposed it only through a player or a blob-backed address. In that situation, the app is not downloading a browser object directly; it is consuming a captured description of the stream.

The distinction between a manifest and a finished file affects failure behavior. A direct request can fail because the resource is missing or the server returns the wrong body. A playlist job can fail because the manifest is stale, a fragment URL has expired, one request lacks the required origin context, or the stream contains separate tracks that must be combined. The queue will eventually represent both as jobs, but the acquisition layer must preserve enough information for the later phases to explain what happened.

Platform media is the third path.