Can't download video, downloading 0B file mp3 or mp4 only

[ghsangi]

bug description

Hello,

Using cobalt api, with self hosting getting issues while download 0b in mp3 / mp4, what will be issue, proxy works file, if proxy has issues output error is 404 or 403

ytdownload.cc

reproduction steps

1. go to 'ytdownload.cc'
2. type of paste yt link press 'go'
3. check the file, downloading only 0b mp3 / mp4 files.

screenshots

No response

links

platform information

Windows 10, Chrome 149.0

additional context

No response

[jzstern]

Root cause data for the 0-byte tunnel, from a self-hosted cobalt 11.7.1 (youtubei.js 17.0.1) on a datacenter IP. Measured inside the running container.

The tunnel returns HTTP 200 with content-length: 0 and no content-type. That comes from handleChunkedStream in api/src/stream/internal.js: the HEAD probe returns 403, so req.status !== 200 and it falls through to cleanup(), which is a bare res.end().

The HEAD 403 is real but it is only the first symptom. Against the exact media URL cobalt resolves (IOS client, so no decipher), for kJQP7kiw5Fk:

HEAD                       -> 403
GET  Range bytes=0-0       -> 206, content-range: bytes 0-0/4557665
GET  Range bytes=0-1048575 -> 206   (1 MB)
GET  Range bytes=0-2097151 -> 403   (2 MB)
GET  Range bytes=0-4194303 -> 403   (4 MB)

So the size is recoverable via a ranged GET, but googlevideo only serves roughly the first 1 MB of the URL. Sequential 1 MB chunks do not get around it:

chunk bytes=0-1048575       -> 206
chunk bytes=1048576-2097151 -> 403
=> 1048576 / 4557665 bytes

Replacing the HEAD probe with a ranged GET therefore is not sufficient on its own — it recovers size and then readChunks 403s on the next request.

The URLs have no pot parameter (has pot? false, has n? false). Appending a gvs PO token from a bgutil-pot provider to the resolved URL afterwards does not lift the limit, which is consistent with the token needing to be bound at extraction time rather than added to an already-issued URL.

Two other notes that may be useful:

• The 403 is deterministic for an affected video, so the transplant retry added in 068ae2f cannot converge — a freshly resolved URL has the same restriction. It just costs three round trips before the empty response.
• Not every video is affected. dQw4w9WgXcQ returns HEAD -> 200 with the full content-length and downloads fine, on the same instance and IP, in the same session. That makes it a poor smoke test for this bug.

retrieve_player is not involved. With cobalt's default IOS client, retrieve_player: false and retrieve_player: true both give playability OK and 22 adaptive formats, and both produce the same HEAD 403. (retrieve_player: false does give UNPLAYABLE/0 formats on the WEB client, but cobalt does not use that client here.)