Checkpoint: From URL to Running Job

OmniGet's first-half workflow can now be judged as one chain rather than as separate resolver, browser, transfer, and queue features. This checkpoint connects those already-established ideas through two contrasting inputs—a browser-assisted private stream and a public direct file—to answer a practical question: who owns each decision, and where would a failure become visible? The result is a diagnostic model for following a URL until it becomes an active, explainable queue item.

The point is not to repeat what each component does in isolation. It is to watch the components hand responsibility to one another. A URL supplies an initial identity; preview adds a media description; the browser may add authorized context; the acquisition route determines how bytes are requested; and the queue makes the running job visible in time. When those layers are kept distinct, “the download failed” becomes a question with several possible answers.

One workflow, two kinds of source

Start with a public direct file. The user pastes a URL that points to a large media resource. OmniGet's resolver recognizes the direct shape and does not need to run a platform extractor merely to discover what the URL already says. It creates a minimal media description, presents the available direct choice, and passes the request toward the queue. At this point, the app knows the source shape and the intended output, but it may still need a referer or other headers if the URL was copied from a page that expects them.

The queue accepts the item as queued work. When a slot is available, it becomes active and the direct downloader probes the resource. If the server supports ranges, the transfer can use a partial file and continue from an existing offset; if not, it uses a single stream. The downloader reports bytes and speed, checks the body and known size, and only then turns the partial result into the final output. The queue can show the item as downloading, stalled, complete, or error, but the transfer path remains responsible for deciding whether the bytes are a usable file.

Now take a private lesson whose player is open in the user's browser. The visible page may be recognized as a course or platform page, but the desktop app cannot assume that the URL alone is enough. The extension sends the page URL and selected metadata, captures the relevant cookies and referer, and may provide HLS playlist text if the player exposed it only inside the page. The local bridge checks the bearer, validates the URL and payload, stores the context, and sends the URL through OmniGet's ordinary queue path.

The item may wait behind the public file. When it becomes active, the chosen acquisition route consumes the stored context. An HLS downloader may use the captured playlist text, request fragments with cookies and referer, and merge the resulting streams. A platform path may invoke yt-dlp with the selected account and options. The queue exposes phases such as fetching information, downloading video or audio, and merging, while the browser is no longer acting as a live proxy for every byte.

The two jobs share a lifecycle but not an evidence chain.